Every guide to Claude Code subagents tells you the same two things: they isolate context, and they parallelize work. Both true. What none of them told us was the number that actually decides whether a subagent is worth spawning. We measured that number on our own project earlier this month; this follow-up is about what we do with it — the break-even math and the routing rules that now gate every spawn.
In our setup, a single subagent costs roughly 436,000 tokens before it reads one line of the file you sent it to read.
That number is not universal — it is the point. Yours will be different, and until you know yours, every delegation decision you make is a guess. Here is where the cost comes from, how to measure it on your own repo in five minutes, and the break-even math we now use before spawning anything.
Where 436k tokens go
A subagent is not a cheap thread. It is a full agent loop with its own context window, and that window gets furnished from scratch on spawn:
- The system prompt and tool schemas. Every tool definition the subagent might use is serialized into its context. With MCP servers attached, this alone can be six figures of tokens.
- Your CLAUDE.md — all of it. Project instructions load into the subagent the same way they load into the parent. If your CLAUDE.md pulls in other files, those come too. We wrote earlier about cutting ours from 548KB to 34KB; before that cut, spawning a subagent was catastrophically expensive and we didn't know it.
- Skills and agent definitions. Anything that auto-loads for the parent generally auto-loads for the child doing the same kind of work.
- The task prompt you wrote, which is usually the only part people think about, and reliably the smallest.
We got the 436k figure by running the same review task two ways — the same product text sent to three agents (2,150,310 tokens total) and to one agent (809,070) — and attributing the per-turn difference to spawn-time context and the final cache write. Crude, reproducible, good enough for budgeting; the full method is in the earlier post linked above.
The break-even question nobody asks
The question is not "is 436k a lot?" It is: what does the alternative cost?
If the parent reads 200k tokens of logs itself, those 200k tokens don't get paid once. They sit in the conversation and get re-sent with every subsequent request in the session. With prompt caching, re-sent input is billed at a heavy discount — but it is not free, and a long session can easily make thirty more requests after the read.
So the comparison is:
delegate: 436k (once, in the subagent's window)
read inline: 200k × (discounted re-send rate) × (remaining requests in session)
With a cache-read discount around an order of magnitude and ~30 remaining requests, inline reading of N tokens costs on the order of N × 3 in effective re-sent volume. The arithmetic puts our crossover near N ≈ 145k tokens (436k ÷ 3); in day-to-day budgeting we round that up to 200k to bias against casual spawns. Below the line, just read the thing in the main loop; above it, delegation wins even at 436k fixed cost.
Two things move that threshold dramatically:
- Session length. Early in a long session, delegation pays sooner (more future requests will re-send whatever you read inline). In the last few turns before you're done, almost nothing justifies a spawn.
- Model routing. If your harness lets an agent definition pin a smaller model, the fixed cost gets cheaper in dollars even when it's similar in tokens. We route bulk reading and collection to a mid-tier model and keep judgment tasks on the large one; that alone moved our practical break-even from "hundreds of thousands of tokens" down to "tens of thousands" for read-heavy work.
The three-line audit for your own repo
- Run a trivial task with no subagent and note the session token delta.
- Run the same task but force it through one subagent (
"use a subagent to do X"). - Subtract. That difference is your spawn tax. Do it three times and take the middle value.
If the number surprises you, the first place to look is whatever auto-loads into every agent: project instructions, imported files, MCP tool schemas. Cutting those pays twice — once in the parent, once in every child.
Rules of thumb we actually follow now
- Never spawn for a single-file fact. Reading one file inline is always cheaper than 436k.
- Bundle overlapping perspectives. Two reviewers with 80% overlapping concerns are one reviewer. The second spawn buys you a second fixed cost, not a second brain.
- Spawn early or not at all. The value of keeping the main context clean compounds over the remaining session.
- Route by task shape. Mechanical reading → small model, adversarial judgment → big model, orchestration → whatever the session runs on.
- Disclose the spend. Our agent reports every spawn with a cost estimate. When the number is visible, the habit self-corrects.
The subagent feature is genuinely good. It is also the single easiest place in an agentic setup to burn a million tokens without noticing, because the cost is invisible unless you go measure it. Measure it.
Written while building Rulestack — configuration packs for Cursor, Claude Code, and Codex, including the agent-definition patterns described above.
Shorter daily notes on agent economics: @ai-shop.bsky.social on Bluesky.
Correction (2026-08-24)
The headline figure is wrong, and the error is in the method this article used. Summing token counts at face value across a run's requests counts the same cached prefix every time it is re-sent, which inflates a spawn's cost several-fold. Measured properly — a do-nothing probe subagent, first request, cache_creation_input_tokens — the fixed cost in this repository is 54,154 tokens, not ~436k.
The break-even math changes accordingly: same-model delegation starts paying at roughly 30–50k tokens of reading (not ~200k), and routing the subagent to a cheaper model pays from roughly 10k. The qualitative conclusions — the fixed cost is real, batch small questions, don't spawn reflexively — survive; the magnitude does not.
Primary sources for this correction:
