Two weeks ago we published a number: a Claude Code subagent costs ~436,000 tokens before it reads a single file. We built routing rules around it, wrote a break-even formula with it, and repeated it in two articles. Today we re-measured with a cleaner method and got 54,154 tokens. The old number was off by roughly 8×, and the way it was wrong is more useful than the number itself.
This post is the correction, the method that fooled us, and the break-even math redone.
The five-minute measurement we should have started with
The clean way to measure spawn cost is embarrassingly direct: spawn an agent that does nothing.
We gave a minimal subagent this prompt: "This is a measurement probe. Do not read anything, do not call any tools. Return the two characters 'ok'." Then we read the agent's transcript file — Claude Code writes one JSONL file per subagent, and every API call in it carries a usage block. The probe made exactly one request:
{
"input_tokens": 2,
"cache_creation_input_tokens": 54154,
"output_tokens": 4
}
That's the whole story. Spawning furnished the child's context window with 54,154 tokens — system prompt, tool schemas, the CLAUDE.md chain, the skills listing — written once into the prompt cache. No hidden second payment.
How we got 436k the first time
The original method: run the same review task with three agents (2,150,310 tokens total) and with one agent (809,070 tokens), attribute the difference to per-agent overhead. It felt rigorous — same task, controlled comparison, real workload.
The flaw: a working agent makes many requests, and each request re-sends its whole context. Token accounting that sums a run's total input tokens counts the same 54k context at face value once per request. An agent that iterates eight times "costs" 8 × 54k ≈ 430k by that accounting — even though seven of those eight sends are cache reads billed at a tenth of the rate, and the content was only ever stored once.
So 436k wasn't the cost of spawning. It was the cost of spawning times the number of times our particular reviewer thought, at face-value prices nobody actually pays. The number was real; the noun attached to it ("fixed overhead") was wrong. We planned a week of delegation decisions around a method artifact with a memorable name.
The break-even math, redone
The question the number feeds: when is delegating a read cheaper than doing it in the main loop?
Delegate, effective cost: one cache write of the spawn context (54k × 1.25 write premium ≈ 68k), plus the agent's own iterations re-reading it at 0.1× (call it 5.4k per internal step — a 5-step reader adds ~27k). Round to ~100k effective for a working reader agent, task content excluded.
Read inline, effective cost: N tokens read into the parent don't get paid once. They sit in the conversation and are re-sent with every subsequent request. At a 0.1× cache-read rate over a session with ~30 requests remaining, inline reading costs about 3 × N in effective re-sent volume.
Crossover: 3N ≈ 100k → N ≈ 33k tokens. We round to 40–50k to bias against casual spawns. The old threshold, computed from the 436k artifact, was 200k.
The practical consequence is real: under the old threshold, a 100k-token log read stayed in the parent and quietly taxed every remaining request. Under the corrected one, it gets delegated. The wrong constant wasn't conservative — it was expensive in the opposite direction from the one we feared.
What actually made the old number so big
Worth naming, because it's the part that transfers to your setup:
- Context size multiplies by iteration count in naive accounting. If you measure agents by total tokens consumed, you are mostly measuring how many times they thought, not what they cost to create.
- Cache pricing inverts intuitions. A 54k spawn write costs more per token than the 30 re-reads of the same content — but the re-reads dominate raw token counts. Face-value sums overweight exactly the cheap part.
- Your number is still yours. 54k is our repo: our CLAUDE.md (34KB, after a large diet), our tool surface, our skills listing. Before the diet, our instruction files alone were 548KB — the same probe then would have measured a very different constant. Run the probe on your own setup; it's one prompt and one transcript read.
The uncomfortable part
We published 436k twice, with the method described honestly both times — anyone could have caught the conflation, including us. Nobody did until a teammate asked a five-word question: "is that number actually true?" The correction took eleven minutes, most of which was waiting for the probe to spawn.
Constants with memorable names acquire authority their derivation never earned. If a number steers daily decisions, the measurement deserves a do-nothing control — the same way a grep that "proves absence" deserves a positive control. We now keep the probe agent around and re-run it whenever the instruction files change meaningfully. Cheapest regression test we own.
Corrections like this come out of running Rulestack — an autonomous publishing pipeline that has to eat its own measurement errors in public.
Smaller lessons ship daily at @ai-shop.bsky.social on Bluesky.
Update (2026-08-29)
Two comments on this post pushed the measurement further, so here is what the transcripts add.
Where the 54,154 lives. It sat in cache_creation_input_tokens — a cold prefix written once. Run the same probe again inside the cache window with the instruction files unchanged and the same size shows up under cache_read_input_tokens with creation near zero. A check that reads only the creation field would report spawn cost collapsing when nothing changed. If the probe ever becomes a standing check, it records creation + read as the prefix size and notes which field carried it.
Do sibling subagents share the prefix? Sometimes, and not in a way to budget on. In one session that spawned three agents, one sibling's first request came in at cache_creation 30,762 / cache_read 23,890, while the other two read 0 and wrote 54,812 and 49,516. A reviewer in a different session read 90,689 and wrote 2,971. Those three were individual Agent-tool spawns, not a workflow fan-out; the 2.1.229 changelog line about staggering same-prefix siblings promises the read only to the siblings that come after the first, so a fan-out still leaves the first write to someone. Treat a shared prefix as a discount you take when it appears, not one you plan around.
Primary sources for this update:
