Your Agent Swarm Is a Token Fire. Two Agents Is the Ceiling.

A team set out to clean up a codebase and pointed 1,393 agents at the job. The main run lasted about nineteen active hours. At peak, 218 agents were running at once. The token bill came to roughly $20,000. The code got cleaner. It did not get 1,393 times cleaner, and it did not get cleaner than a single competent model could have managed on its own.

Eric Provencher, a Codex developer at OpenAI, went public with the autopsy. Past two parallel sub-agents, he said, the setup almost always costs more than it returns. The reason is not compute limits and it is not context windows. The reason is trust. Agents do not trust each other, so they spend the run double-checking everyone else's homework. He gave that failure mode a name: the coordination tax.

Here is the vocabulary you need before the rest of this makes sense. Fan-out is splitting one task across multiple parallel agents and merging the results. The coordination tax is the verification overhead your agents impose on each other, and it grows with every lane you add. Put the two definitions side by side and the argument writes itself. Fan-out is a spend with an overhead curve attached, not a dial you turn up for free throughput.

PhantomByte already showed you that your agent queue is a 3.5x speedup you already own (Note #189). That note was about scheduling one queue to cut latency. This note is the invoice for the other half of that decision. Parallelism has a hard cost ceiling, and the number that matters is not how many lanes you can start. It is how many you can merge.

WHAT $20,000 FOR ONE FILE ACTUALLY BOUGHT

Understand the mechanism and you will never frame fan-out as free again. When you run N agents in parallel, each agent's output is untrusted input to every other agent. Nobody has authority, so nothing is accepted without review. Verification work then scales with lanes times lanes, not lanes. Double the agents and you do not double the checking. You quadruple it.

That is the whole trap. The system spends its budget proving agents wrong about each other instead of doing the task. Throughput added lanes, and the coordination layer ate all of it plus margin. Provencher's read on the $20,000 run was blunt: a single Astra agent could have done the job for a fraction of the cost. The swarm did not fail. It succeeded expensively, which is a worse outcome than failing, because the invoice arrives after the celebration.

Look at what the successful version of that run actually required. The orchestrator measured the codebase and cut it into non-overlapping groups. Workers checked out separate git worktrees so they would not overwrite each other. Every worker brief named the code to simplify, the interfaces to preserve, and the checks required before committing. A tool's JSON schema had to stay identical, and a CLI's help output had to match byte for byte. Then, after two rounds of community review, regressions still slipped through and had to be fixed before merge. That is a well-built coordination layer doing its real job. It is also a second system, with its own cost, sitting on top of the work you thought you were paying for. The refactor was worth doing. It was not worth doing at any lane count, and the difference between those two statements is an engineering decision.

THE TWO-LANE RULE

The decision rule you can actually carry into a meeting is the Two-Lane Rule. Two parallel sub-agents is the observed ceiling before the coordination tax exceeds the return. Under two lanes, verification is cheap and the merge is trivial. Over two, every additional lane adds verification load on every lane that already exists.

The rule has a boundary, and it matters. It targets tasks that require merge or cross-verification, the kind where lanes touch the same artifact and their outputs have to be reconciled, which is exactly what a codebase refactor is. Embarrassingly parallel batch work with zero state-sharing is a different animal. Generate thumbnails for a hundred product images and no lane ever needs to see another lane's output. There is nothing to cross-check and nothing to merge, so the coordination tax stays near zero and that work scales past two lanes without penalty. The Two-Lane Rule governs the tasks where lanes collide. It does not govern the tasks where they never meet.

The rule is not a law of nature. It is a stopping point, and you should test it against your own stack before you argue about mine. Take one real task from your backlog. Run it at one, two, four, and eight lanes. Measure tokens per unit of accepted output, which is the only number that matters. Most teams have never measured this, and the first graph usually ends the debate in a single meeting. If your four-lane run costs more per accepted unit than your two-lane run, you just found your ceiling without reading a single paper.

WHY THE TOOLING IS CONVERGING ON THE AGENT COORDINATION TAX, NOT FAN-OUT

On the same day Provencher made his argument, Anthropic relaunched Projects in Claude Code, and the architecture tells you more than the announcement did. One coordinator sits on top. Each thread is a full Claude Code cloud session working on its own branch and its own copy of the repository. When two threads touch the same code, the overlap is resolved as a merge conflict, exactly like any pull request. Each thread can split its work further with subagents, loops, and workflows.

Read what that design admits. Parallel agents are treated as untrusted contributors whose collisions need a merge protocol, which is the same discipline a human engineering team already applies to branches. The industry's orchestration tooling is building the coordination layer first, not the fan-out layer. That is the tell. Whoever ships the better merge protocol wins the orchestration market, because raw lane count was never the hard part.

Recent benchmark data reinforces the same conclusion from the research side. A paper on workflow portfolios (arXiv 2609.18126) formalizes the exact tradeoff you are living: extra executions can uncover a right answer the best single workflow misses, but they cost compute and they introduce plausible distractors that complicate the final pick. Its conclusion is the one to remember. More runs only pay off if your selector can still pick the right answer out of the noise the extra runs created. A second study, RideWay (arXiv 2609.17985), benchmarks efficiency for tool-using agents and finds that the fitted penalty for excess conversational turns is about twice the penalty for excess tool calls. Users feel friction, not raw count. The portfolio result carries more weight here, because it speaks directly to how extra runs interact with the selection step.

BUDGETING FAN-OUT LIKE AN ENGINEER

Stop treating fan-out as a throughput dial and start treating it as a spend with a coordination overhead curve. Then the question changes from "how many agents can I run" to "where does the next lane stop paying for itself."

A second lane is justified when three things are true. The subtasks are genuinely independent, meaning neither one needs the other's output to start. Verification is cheap, meaning you can check a result without re-deriving it. And the merge is deterministic, meaning two correct outputs combine into one correct output by rule rather than by judgment. If all three hold, add the lane.

A second lane is not justified when the steps are dependent and must run in order anyway. It is not justified when cross-checking costs as much as doing the work twice. And it is not justified when the final pick needs human-quality judgment, because that selection step is where distractor problems live. This is the authority thesis in miniature. Orchestration economics is engineering, and you cannot do anything serious in AI without solid engineering, including the discipline to not run the third agent.

WHAT TO DO TODAY

1. Find your most expensive agent run from the last month. Count the parallel lanes it used. Ask what the extra lanes returned.
2. Impose the Two-Lane Rule as a default. No more than two parallel sub-agents without a measured justification on paper.
3. Measure tokens per accepted output at one, two, four, and eight lanes on one real task. Graph it and keep the graph.
4. Check whether your orchestration layer has a merge protocol for agent collisions. If it does not, your lanes are not parallel. They are queued, and you are paying a coordination tax for nothing.
5. Put a token budget on fan-out the way you put one on model choice. Same review, same spreadsheet, same sign-off.

THE UNCOMFORTABLE QUESTION

You can name your model and your context window to the digit. Can you name the point where one more agent stops adding output and starts adding verification of the verification? If that number does not exist in your head or in your budget, the 1,393-agent team thought the same thing, right up to the invoice.

The ceiling is not how many agents you can start. It is how many you can merge.