The same fan-out costs 53% more, about a third of the time

Run the same eight-agent fan-out ten times and it does not cost roughly the same each time. It costs one of two things.

Seven runs came in between 205,419 and 208,190 tokens. Three came in between 314,419 and 318,155. Nothing landed in between. Every run produced the same eight files. Where output tokens were recorded, they were comparable across both modes, so the difference is input context rather than more work done.

Mode	Runs	Range	Median
Nine turns	7	205,419 – 208,190	207,102
One turn	3	314,419 – 318,155	317,786

The expensive mode is 1.534x the cheap one, +53.4%, for the same delivered files.

The two groups do not overlap

That is the part worth carrying, because it is stronger than any percentage. The most expensive cheap-mode run cost 208,190 tokens. The cheapest expensive-mode run cost 314,419. There is a 106,000-token gap with nothing in it.

This is not a spread with an outlier. It is two populations.

One field already in the output tells you which one you got

num_turns, reported in the result JSON, partitions the ten runs perfectly. Every cheap run reported nine turns. Every expensive run reported one.

The normal mode reports one turn per agent plus one:

Agents	Turns	Observed context
2	3	85,380 to 85,932
4	5	125,773 to 126,181
8	9	207,102

The expensive mode collapses that to a single reported turn while costing half as much again. Fewer reported turns would normally mean less context re-sent, not more, which is why this is worth knowing rather than assuming.

Output tokens were only captured by the harness that ran the width sweep, so that comparison rests on six of the ten eight-agent runs: 3,514 to 4,039 in the cheap mode against 3,553 in the expensive one. It is consistent with the difference being input context, and it is not measured on the other four.

I am not going to tell you why. Nothing here measures the cause, and a plausible story about scheduling or retries would be invention. What is measured is that two modes exist, what each costs, how often each occurs, and which recorded field separates them.

What this does to a per-agent figure

This site published a figure of 20,398 tokens per parallel subagent on the previous version. Re-measured here against the one-agent arm, which ran four times at 64,828 to 65,049 tokens:

	Tokens per added agent
Cheap mode	20,293 to 20,325
Expensive mode	36,105 to 36,137

The two bands do not overlap, which is the point, and neither is a point estimate because the one-agent baseline they subtract was measured four times and is quoted as its range.

The cheap-mode band brackets the 20,398 published on a different version with a different harness, coming in about 0.4% under it, which is good evidence the original measurement was sound. But it is the cheap mode. About a third of the time you pay the upper band instead, and no amount of averaging makes that a single number.

Corrected 2026-08-22. This section originally gave 20,314.5 and 36,126.5 tokens per added agent, against a one-agent median of 64,900.5, and the width table gave medians of 85,445 and 125,885.5. Those four figures are phantoms: each is the midpoint of the two middle runs of an even-sized sample, and no run produced any of them. The arithmetic was exact and the inputs were real; the estimator was not. They are replaced above by observed ranges, which need no estimator and cannot be phantoms.

The headline is untouched and was never affected. 1.534x and +53.4% are the ratio of two medians that odd-sized samples produced directly, 207,102 and 317,786, and the 3-of-10 occurrence rate is a count. Every derivation is now published in the corpus.

That also resolves something the earlier post got wrong. It disclosed one run at 288,040 tokens as an outlier, noting it “logged a single turn where every other eight-agent run logged nine”. That was not an outlier. It was this mode, and the detail that identified it was sitting in the disclosure.

Whether it happens at narrower fan-outs

Not observed. Six runs at two agents and six at four agents all landed in the normal mode, tightly: 85,380–85,932 and 125,773–126,181.

That is not the same as saying it does not happen there. If the expensive mode ran at narrower widths at the rate seen at eight agents, the chance of seeing none in six runs is 0.7⁶ = 0.118. One in eight. So six clean runs is entirely consistent with the mode existing at two and four agents and simply not showing up yet. It is recorded as not observed, and that is all it means.

Controls

Arrival control, 34 of 34. The model decides how to delegate, so a run that quietly used fewer agents would otherwise be averaged in as if it had complied. Every run had to leave exactly N files on disk, and files_created is published per run so the check is verifiable rather than asserted.

Isolation on every run used here. --setting-sources project, matching the arm the published per-agent figure came from, and asserted onto the command line rather than assumed. The corpus file also holds an eight-run configured arm, four at one agent and four at four, recorded with isolated: false and landing near 213,000 and 490,000 tokens. That is the non-isolated comparison from the earlier re-verification; it contributes to no figure here, which is why 26 of the 34 published runs are used.

Tokens from modelUsage, not .usage, which does not count subagent usage at all and would undercount every figure here by construction.

The ten eight-agent runs come from two harnesses run separately, four while re-verifying the per-agent figure and six in a later width sweep. They share task, prompt, isolation flag and arrival control, and the two groups agree closely (205,419-205,737 against 207,041-208,190 in the cheap mode), but they were not interleaved in one session. The corpus records which file each run came from.

One machine, one task shape. These subagents write four bytes each. The absolute numbers are this setup’s; the separation, the ratio and the partitioning field are the transferable parts.

Every run is published in fanout-modes.json.

---

Extended 2026-08-14, with a second cell on Claude Code 2.1.232, and a limit on how far this generalises. The instrument this post introduced, partitioning fan-out runs by num_turns, was applied to a four-agent fan-out over eight rounds. It partitions there too, and as cleanly: the dearest six-turn run cost 147,796 and the cheapest seven-turn run 171,185, 23,389 tokens apart with nothing in between, which is the shape this post argues is stronger than any percentage. The per-agent slope is a range at four agents as well, 20,376 against 28,259.

Conditioning also makes the figure durable. The four-agent isolated cell at six turns measures 149,538 on 2.1.229, 149,364 on 2.1.231 and 147,747 on 2.1.232, a 1.2% spread across three releases, where the unconditioned medians had appeared to move by as much as 37%.

The instrument does not always work, and that is worth saying plainly here rather than only in the newer post. Across the four cells this site has data for, it partitions two and fails two:

Cell	Partitions by num_turns?
2.1.228, 8 agents, 10 runs (this post)	Yes. 9 turns 207,102, 1 turn 317,786
2.1.232, 4 agents isolated, 8 runs	Yes. 23,389 apart, nothing between
2.1.229, 4 agents loaded, 4 runs	No. 7, 7 and 10 turns cost 616,851 / 616,116 / 616,059, inside 0.13%, while 6 turns sits 10% low
2.1.227, 4 agents, 3 runs	No. All three report 5 turns and span 12.3%

So num_turns sometimes separates the modes and sometimes carries no information at all. The 2.1.229 corpus reached that conclusion for its own cell at the time and was right.

And the turn values themselves moved between releases. This post’s four-agent runs came in at 5 turns in 10 of 10. On 2.1.232 a four-agent fan-out runs in 6 or 7 and never in 5, and a single agent went from 2 turns to 3. Neither of this post’s eight-agent counts, 1 or 9, appears at four agents on either release. Where the two partitioning cells disagree about which mode is dearer, release, harness, floor and agent count all differ, so nothing measured says which axis moved the ordering.

Two limits carried forward with the figures, not left behind in the JSON. Every per-agent number here, on either version, is a line through two measured points, one agent and four (or one and eight above). Anything between those points is interpolated and anything past them is extrapolated, so “tokens per added agent” is a slope between two measurements rather than a rate established across the range. And the mechanism is still not established: a subagent re-pays about twice the configuration rather than once, that multiple is measured repeatedly and consistently, and why it is two remains unexplained. Neither limit has been retired by anything in this extension.

Full runs: fanout-slope-2-1-232.json, and what a parallel subagent costs.