Three Sessions, One Company: What Parallel AI Sessions Actually Cost

One person. One borrowed eight-GPU node. A company's worth of work sitting on top of it, and not all of it is modelling.

There is an encoder to train. There is a research engine that runs experiments while everyone sleeps. There is a clinical-facing app for the people who will actually use this. And there is everything a company needs that touches no GPU at all: the partner conversations, the deadlines, the machine itself, the documents that outsiders read.

The obvious move is to stop doing this in one window. Split the work across parallel Claude Code sessions, give each one a slice, and let them run. So we did. Four lanes:

• ops is the integrator. It owns the outside world: partner and team comms, deadlines, the shared document area outsiders read, the life of the borrowed node itself, and the single status picture. It is the only lane that reads all the others.
• model owns the encoder. Training runs, the eval suite, the corpus. It also defines which experiments are worth running.
• aria owns the research engine. The supervisor, the serving layer, the dashboard, and the loop by which the engine improves itself. It runs the experiments model defines.
• apps owns the reader and grader application, the thing a clinician actually touches, and the loop that feeds confirmed human gradings back into research.

The seams are not org-chart decoration. One lane decides what to test and another one tests it. Two lanes feed the app. One lane owns every conversation that leaves the building.

And it works. That belongs up front, because what follows is not a cautionary tale about parallelism being a mistake. We ship more this way, and I would do it again this afternoon. This post is about what the speed costs, and about the fact that the bill always arrives somewhere nobody was looking.

One file, four writers

The first failure was the dumbest one available, and everybody hits it.

Every session wrote to a single shared handoff file: the place a session reads to find out where things stand. It grew to about fifty kilobytes before we froze it.

The failure was three sessions rewriting the same "start here" block. Whoever saved last won. The other two sessions' updates were simply gone. No error. No warning. No conflict to resolve. The charter we later wrote says it plainly: the old single continuity file failed because three sessions rewrote one start-here block.

A lost update is silent. Nothing tells you the file changed underneath you. This is not an AI problem. It is a concurrency problem, and it arrived the moment there was more than one writer.

The fix, which is not new

Three parts.

An ownership map, resting on one rule: you write your own lane's file and nobody else's. Per-lane cursors, one state file per session instead of one for all of them. And an append-only mailbox for handoffs between lanes, grouped by who they are addressed to.

The honest reading of that list is that none of it is novel. Ownership, locks, message passing. We reinvented, badly and under time pressure, the primitives that every distributed system and every functioning human organization already has.

Most people building this do not think of themselves as having done that. They think they have opened a second terminal.

Where the cost actually went

Here is the part I did not expect, and it is why this post exists. Every failure below happened after the ownership map was written. The map is dated 25 June. All of these are July.

Drag the sessions slider and switch each fix on in the order we shipped them. Watch what closing one boundary does to the next.

The boundary that was not in the picture

The ownership map covered the files in the project. It said nothing about a config file on the shared machine, because that file was not in the project.

Two sessions edited that config at roughly the same time. The other session's version was written after mine, and mine vanished. The service restarted cleanly and reported itself healthy. The model I had added simply was not there.side quest

What made it expensive was the disguise. It looked exactly like the service rejected my config, which sends you off to debug the config's syntax for an hour. The work I had carefully checked was no longer on disk, and nothing anywhere said so.

An ownership map only protects what it names, and the boundary that hurts is the one outside the frame.

The mailbox grew a bill of its own

This is the one that changed how I think about the whole exercise.

The mailbox worked. Lanes posted handoffs to each other, grouped by recipient, and the protocol was explicit: one tight line per item.

Then I measured it. A hundred and two open handoffs. Individual entries running to two and a half thousand characters, on a board whose own protocol says one tight line.

Reading a handoff properly is not free. You have to take it apart, check its claims against things only you can see, and act. That discipline costs real work per item. It is affordable at five items. At a hundred, it does not get done. It gets skimmed. Which is exactly the failure the board exists to prevent.

The fix was not a better protocol. It was a cap: fifteen live items. Make the discipline cheap enough that somebody actually does it.

And because this series does not get to have nice things: I checked the board again while writing this paragraph. It is holding fifty open items, and its longest single entry now runs to 3,674 characters. The cap is three weeks old. It is already not being held, and the entries are longer than the ones that made me impose it.

The lanes had amnesia, and nothing told them

The worst one, and I would have bet against it.

A long session eventually runs out of room and compacts itself, summarizing what came before. What gets restored afterwards is a small, fixed budget of text. About eighty lines.

That is all. Everything else a session read at startup is gone. The lane charter. The rules about what it may do on its own. Its own cursor. Its inbox. All of it was part of a conversation that is now a one-sentence summary.side quest

And the lane keeps working. It still runs on its schedule, still posts handoffs, still sounds as confident as it did at hour one. Three hours in, a lane is operating with the mission and without the method.

That is where a lane was one edit away from publishing a conclusion the owning lane had already reversed comes from. The lanes were not careless. They had amnesia, and nothing in the system told them.

The lesson travels beyond this stack. Those eighty lines are the only text guaranteed to survive. Whatever is in them is your real always-on layer, whether you chose it or not. Ours were being spent on prose nobody had picked for the job. They now carry a recovery card, on purpose.

A handoff carries two things, and only one is the sender's to give

A message from another lane usually contains a finding, which sits in the sender's domain and is backed by their evidence. It also contains claims about the state of your world: this already shipped, nothing has gone out yet, they already have it.

One handoff carried a perfectly correct finding wrapped in two such claims. Both were wrong, in opposite directions. One said something had been delivered that had not been. The other said nothing had gone out when it already had.

Believe either and you take the wrong action. And because they point opposite ways, no blanket policy saves you. "Trust the handoff" fails. "Distrust the handoff" fails. Only checking works.side quest

It is nobody's fault, which is why it keeps happening. The sender can see the thing they inspected. They cannot see your sent folder, your message log, your machine. Their claim about your world is a guess from a document that has moved on.

The cost that never moved

The deepest one took longest to see.

Every lane checks itself. The research engine judges its own findings. Each lane red-teams its own experiments. But nothing red-teamed a lane.

There was exactly one cross-lane auditor of a system producing more conclusions per day than any one person can read, and it was me.

Here is the uncomfortable arithmetic. Every improvement to the lanes put more weight on the human, not less. Faster lanes produce more claims per day. The checking never parallelized alongside the work. It serialized onto one person.

That is coordination cost that did not move at all. It concentrated.

The answer, on 13 July, was a fifth session that does no work. It builds nothing. It launches nothing. It holds no GPU. It reads the other four, writes one file, and posts what it finds like anyone else.

We call it the manager.

It produces nothing, it consumes a lane, and it exists purely to read the other four sessions' output and tell them what is wrong with it. I did not set out to build a middle-management layer for my language models, and yet here we are. The lanes find it about as welcome as you would expect.

It is also the best thing we have added since the ownership map, and the principle behind it is the only thing in this post I would defend anywhere:

Every claim should meet an instrument that is not the one that produced it.

Every lane already had a judge. Every one of those judges was the same system that produced the thing being judged. The manager is the first instrument in the building that has no stake in the answer.

What I actually know

The review lane is one day old. I do not know whether it works.

I could end by telling you that the ownership map fixed the collisions, the cap fixed the mailbox, the recovery card fixed the amnesia and the fifth session fixed the checking. It would read well, and the dates say it would be a lie: the map was written on 25 June, and every failure in this post happened after it. Each fix bought a real improvement, and then revealed the next boundary nobody owned.

Which is the finding, and the only thing I would ask you to carry away.

Coordination cost is conserved. Parallelism buys throughput and charges you a boundary for every seam it creates. The bill arrives wherever nobody was assigned: the config outside the project, the claim buried inside the message, the mailbox that grew past reading, and the person who became the only global instrument in the building.

Go and find yours. The prompt at the top of this post will start you off, and I would bet on the file outside your project directory.