# We said a Claude Code subagent costs 436k tokens. A cleaner measurement says 54k — here is what fooled us

> Source: <https://dev.to/rulestack/we-said-a-claude-code-subagent-costs-436k-tokens-a-cleaner-measurement-says-54k-here-is-what-37am>
> Published: 2026-08-29 02:17:00+00:00

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 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.

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 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.

Worth naming, because it's the part that transfers to your setup:

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.*