Each parallel subagent costs 20,398 tokens, or 92,304 with your config loaded

“Running ten agents in parallel uses quota ten times faster” is the line every cost guide repeats. It is true of ten separate sessions, and it is the wrong model for subagents inside one session.

The widest fan-out measured here is eight, not ten. On Claude Code 2.1.227, each parallel subagent adds a flat 20,398 tokens, and because the session’s own overhead is paid once, eight subagents cost 3.20x one subagent rather than 8x. Run those same eight agents as eight separate one-agent sessions and they cost 519,528 tokens against the 207,729 one eight-wide session actually cost: 2.50x, purely from how the work was packaged.

That is the smaller half of the finding. The larger half is that every subagent re-pays for your configuration, and then some. On a machine carrying 37,808 tokens of user-level CLAUDE.md, skills and tool definitions, the cost per parallel subagent rises from 20,398 to 92,304, a rise of roughly twice the configuration itself.

The ladder

Every run asked for exactly N parallel subagents, each of which writes one file containing the word DONE. The inline arm produces the identical files without subagents. Medians of three rounds, both arms measured in the same round.

Subagents	Inline	Fanned out	Fan-out penalty
1	44,738	64,941	1.45x
2	45,065	85,138	1.89x
4	45,654	125,856	2.76x
8	46,832	207,729	4.44x

The per-agent cost is remarkably flat. Fitting a line through only the endpoints gives 44,543 fixed plus 20,398 per agent, and that line then predicts the two interior points it never saw to within 0.24%: 85,339 against a measured 85,138, and 126,136 against 125,856.

So the shape of the circulating claim is right and its intercept is wrong. Cost is linear in agent count. The line does not pass through the origin.

The intercept is real, and it was measured separately

A fitted intercept is an artefact until something independent lands on it. The zero-subagent arm does: doing the work inline with no subagents at all costs 44,738 tokens, against the 44,543 the fan-out ladder predicts without ever seeing that arm. 0.4% apart.

That number is the session itself, the part you cannot avoid by fanning out less.

What the fan-out is actually buying

The inline arm is the control that makes the penalty meaningful, because it produces the same artifacts. On the same endpoint fit, each additional file costs about 299 tokens inline and about 20,398 via its own subagent.

That is 68x for identical output, and it is the honest floor rather than a realistic workload: these subagents do nothing but write four bytes. A subagent that reads a large file or searches a codebase absorbs context the parent would otherwise carry, which is the case for delegating, and this site has already measured that at 1.72x. The 20,398 is what you pay before any of that starts.

The finding that changes what to do: config is paid per subagent

The figures above were measured with --setting-sources project, which excludes user-level configuration. That is the right way to measure the mechanism and the wrong way to plan with it, because almost nobody runs an empty config.

So a cut-down version of the ladder was run again with the configuration loaded: two agent counts, one subagent and four, two runs each. Four runs against the isolated ladder’s thirty-six, with no paired inline arm. On the identical zero-subagent task, this machine’s user-level configuration measures 37,808 tokens, measured on a single turn.

This post originally reported 75,466 for that quantity, from 120,160 loaded against 44,694 isolated, and noted that a second round gave 75,465 so the two agreed to a single token. They did, and both were twice the real figure. See the correction below.

The prediction was declared before running. If configuration is a session-level cost paid once, the per-agent slope stays near 20,398. If each subagent re-pays it, the slope goes to roughly 95,900.

	Per parallel subagent	Runs behind it
Minimal config	20,398	36
Configured machine	92,304	4

92,304. The slope rose by 71,906 tokens. Against the correctly measured configuration of 37,733 on that machine, that is 1.91x, so each parallel subagent costs about twice your configuration rather than most of it. A re-measurement on 2.1.229 puts the same ratio at 2.46x. Either way the practical direction is the same, and stronger than this post first claimed.

That slope is drawn through two points, so unlike the isolated ladder it has no interior count held back to test linearity against. One independent check is available and it holds: the two-point fit implies a fixed cost of 119,795 tokens, which lands 0.30% from the separately measured loaded zero-subagent figure of 120,159. Read 92,304 as a two-point estimate corroborated at its intercept, not as a slope validated across four counts the way 20,398 is.

The practical consequence survives that caveat comfortably, because it turns on the direction and rough size rather than the fifth digit. A 30,000-token CLAUDE.md costs 30,000 tokens once in a normal session. Fan out four ways, which is the width actually measured loaded, and it costs roughly eight times that, on top of the 20,398 each agent already costs, because the per-agent penalty measures about twice the configuration rather than one times it. That multiplier is the part this post originally halved. Every argument this site has made for moving reference material out of CLAUDE.md multiplies by the width of your fan-out.

When fanning out is still right

None of this says do not use subagents. It says the overhead is per-agent and does not amortise, so the work each agent does has to be worth roughly 20,000 tokens on a lean config, or roughly 90,000 on a fat one. Reading three files is not. Independently searching a large codebase might be.

Speed is the usual reason to fan out, and on this task it did not deliver either. Fanning out was slower than inline at every count, and it did not flatten with width: median wall clock was 15.6 seconds for eight files inline against 29.5 seconds for eight subagents, and going from four subagents to eight added about seven seconds rather than none. That is expected for work this small, where spawning dominates, and it is the reason to read these numbers as the floor rather than as a verdict on parallelism. A real fan-out over slow, genuinely independent work is where the wall-clock case lives, and this task cannot speak to it. Update, 2026-08-13: that gap has now been measured. Given eight independent 40KB files, one agent each, fanning out was still about 1.7x slower, so the crossover sits above a heavy file search rather than just above four bytes.

Re-verified 2026-08-13 on Claude Code 2.1.231, and the calculator was found still quoting the withdrawn figure.

Re-measured with the same method, four rounds: this machine’s configuration is 37,808 tokens on a single turn, identical to the 2.1.229 figure. The per-agent slope is 20,690 isolated against 103,397 loaded, a difference of 2.19x the configuration. Three independent measurements now put that multiple at 1.91, 2.46 and 2.19, so about twice is the transferable claim and the second decimal is not.

The reason for re-running it was worse than a version bump. The cost calculator was still computing from configShare: 0.953, which is 71,906 divided by the withdrawn 75,466. Correcting this post did not correct the tool, because a derived constant does not contain the retracted number and so survives a search for it. On a 37,808-token configuration the old constants modelled 56,429 tokens per agent against 103,397 measured: the calculator understated this site’s own finding by 45%. It now carries the re-measured constants, and the deploy gate ties them to fanout-slope-2-1-231.json so they cannot drift from their evidence again.

One arrival-control failure is worth recording: 39 of 40 runs passed, and the one that did not sits in the inline control arm rather than the fan-out arm the slope is drawn from.

Correction, 2026-08-13: the configuration figure was the same quantity counted twice, and the derived claim understated the effect by half.

This post reported that “this machine’s user-level configuration measures 75,466 tokens”, from 120,160 loaded against 44,694 isolated. Both of those were run totals from a task that took two turns, and modelUsage sums across API calls, so the difference counts the configuration once per turn. This site’s own measurement rules say a run total is never a context size, and this post did not follow them.

Measured on a single turn instead, four rounds, identical to the token every time: 60,214 loaded against 22,406 isolated, so the configuration is 37,808. Twice that is 75,616, which reproduces the published 75,466 to 0.20%, and each half reproduces separately to within 0.26%. The doubling is not a hypothesis about what went wrong; it is arithmetic that lands on the published numbers.

What that changes. The sentence “the slope rose by 71,906 tokens, which is 95% of the 75,466-token configuration” divided by a denominator that was twice too large. Against the real configuration the same published rise is 1.91x, and a fresh ladder on 2.1.229 gives 2.46x. So the finding was not merely mis-stated, it was understated: a parallel subagent costs about twice your configuration, not most of it.

What is unaffected. Every figure measured inside a single configuration state stands. The isolated per-agent slope re-measured at 20,749 against the published 20,398, 1.7% apart. The 3.20x and 4.44x ratios are untouched. The inline control was re-run and re-confirms the mechanism: writing more files inline costs 310 tokens each isolated and 304 loaded, a difference of -6, so configuration is not re-paid per unit of inline work, only per subagent.

The lesson worth keeping, because it nearly hid the error. The original noted that a second round gave 75,465, “so the two agree to a single token”. They did. Both were twice the truth. Two measurements agreeing perfectly with each other says only that the method is repeatable, and a repeatable method with a units error is repeatably wrong. Agreement between rounds is not a check on what is being counted.

The re-measurement is published in configured-fanout-2-1-229.json.

Controls and limits

Arrival control, 44 of 44, and what it does not prove. Every run had to leave exactly N files on disk, and any run that did not would have been recorded unscored. None failed. That is an output check, not a delegation check: it confirms the work arrived, not that N separate subagents did it, and nothing in the published data records how many agents actually spawned. What does establish delegation is the cost separation itself. A fan-out run whose parent quietly wrote the files itself would land on the inline curve near 46,832; the eight-agent runs land at 207,729. You cannot pay 4.44x for delegation you did not do.

Tokens come from modelUsage, not .usage. On this site’s earlier delegation measurement, .usage missed 93,447 tokens because it does not count subagent usage at all. Any fan-out figure derived from .usage is an undercount by construction.

Reproduced across two separate sessions. The isolated fan-out ladder was run on two different days: medians of 64,809 / 85,192 / 126,031 / 206,288 and 64,941 / 85,138 / 125,856 / 207,729, agreeing within 0.7%, giving 3.18x and 3.20x for eight agents against one. The configured arm was not replicated this way, which is the second reason to treat it as the weaker number.

Correction, 2026-08-12: the 288,040 run was not an anomaly. Re-measuring on 2.1.228 across ten eight-agent runs found that this fan-out has two execution modes, separated exactly by the num_turns field quoted below: nine turns costs about 207,000 tokens and one turn costs about 318,000, with no overlap between the groups, and the expensive mode occurred in 3 of 10 runs. So 288,040 was the second mode, and the detail that identifies it, a single logged turn, is sitting in the very sentence that dismissed it. The 20,398 figure above is the cheap mode; it reproduces to within 0.41% on 2.1.228, but about a third of the time a subagent costs 36,105 to 36,137 instead (corrected 2026-08-22 from a point figure of 36,126.5, which was computed against a phantom baseline no run produced). Full measurement in the same fan-out costs 53% more, about a third of the time.

Two anomalous runs, both disclosed. One of session 2’s three eight-agent runs came in at 288,040 against 206,913 and 207,729, and it logged a single turn where every other eight-agent run logged nine. One of session 1’s three four-agent runs came in at 141,513 against 125,767 and 126,031, 12.3% high, with no such structural break to explain it. Those are the only two runs in the dataset deviating from their own cell median by more than 1.2%; every other run is within 1.1%. Both are the highest value in their cell of three, so neither is a median and no figure here rests on either.

Absolute numbers are this setup’s. The isolated figures rest on a minimal configuration and the loaded figures on one particular machine. The ratios and the per-agent slope are the transferable parts; substitute your own configuration size rather than reusing 92,304.

This is not a rate claim. “Ten agents use quota ten times faster” describes burn per unit time, and across ten concurrent sessions nothing here contradicts it. What is measured here is the total cost of one session that fans out, which is the number you act on when choosing how wide to go.

Every run is published in parallel-subagent-cost.json.

---

Re-measured 2026-08-14 against Claude Code 2.1.232, and the word “flat” does not survive. Eight rounds instead of four. On this cell, four agents isolated, the runs fall into two non-overlapping groups with num_turns constant inside each: the dearest six-turn run cost 147,796 and the cheapest seven-turn run 171,185, 23,389 tokens apart with nothing in between, and within a group the spread is 0.2 to 0.3%. The loaded arm splits the same way, 11.3% apart against the isolated arm’s 16.0%.

So the per-agent cost is a range on this version, not a number: 20,376 tokens at six parent turns and 28,259 at seven, and the caller does not choose which. A median across a mixed turn mix measures the mix, which is what produced this post’s earlier figures and why 2.1.232 first appeared 37% dearer. At the six-turn condition the two releases agree to 1.5% (20,687 against 20,376); at the modal seven-turn condition to 3.4% (29,260 against 28,259), and the 2.1.231 side of that rests on one run.

Conditioning turns a figure that kept moving into one that does not. The four-agent isolated cell at six parent 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 appeared to move by as much as 37%. Those are absolute contexts from three sessions with three floors, so they carry whatever each floor was doing.

But num_turns is not a general instrument, and I over-claimed that for a day. A first version of this note said the parent’s context tracks how many turns it takes, and then that the dispersion in the older corpora “partitions cleanly” by the field. Both are wrong. It partitions on two cells this site has run and fails on two others:

Cell	Does num_turns partition the cost?
2.1.232, 4 agents isolated, 8 runs	Yes. Two groups, 23,389 apart, nothing between
2.1.228, 8 agents, 10 runs	Yes. 9 turns 207,102, 1 turn 317,786
2.1.229, 4 agents loaded, 4 runs	No. 7, 7 and 10 turns cost 616,851 / 616,116 / 616,059, inside 0.13% of each other, while 6 turns sits 10% low
2.1.227, 4 agents, 3 runs	No. All three report 5 turns and span 125,767 to 141,513, 12.3% apart

The 2.1.227 spread this post still discloses as unexplained is therefore still unexplained: those runs share a turn count. And where the two orderings that do partition disagree, at eight agents on 2.1.228 nine turns is cheap while at four agents on 2.1.232 six turns is cheap, release, harness, floor and width all differ, so nothing identifies which axis moved it.

A correction to the correction, and it is about this site rather than Claude Code. That first version also accused the 2.1.229 corpus of leaving the dispersion unflagged. It did not. It flagged the cell, listed the turn counts, and concluded that “turns is not a usable cost proxy for fan-out here” — which was right for that cell, as the table above shows. The real failure is narrower and duller: the 2.1.231 corpus carried the spread forward as an unexplained limit and dropped the turn conditioning that 2.1.229 had already done.

Why a subagent re-pays about twice the configuration rather than once is still not established: the multiple is measured, the mechanism is not. It survives conditioning in both states: 1.91x at six turns and 2.24x at seven, against 1.91, 2.46 and 2.19 on the three earlier versions. About twice your configuration remains the transferable claim. The inline control is 186 tokens per file, so the fan-out slope is still attributable to the subagents rather than to the work. Every run, conditioned on turn count: fanout-slope-2-1-232.json.

Re-measured on 2.1.238. Ten rounds, 100 runs, put the isolated per-agent cost at 20,581 tokens at six parent turns and 28,504 at seven. Six is the modal condition on that release, reached in seven of the ten rounds. Those are the figures the guidance pages on this site quote, and every run is in fanout-slope-2-1-238.json.