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

我们曾说 Claude Code 子代理需要 436k token，但更精确的测量显示只需 54k —— 我们是如何被误导的

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. 两周前，我们发布了一个数据：一个 Claude Code 子代理在读取任何文件之前，成本约为 436,000 个 token。我们围绕这个数字制定了路由规则，编写了盈亏平衡公式，并在两篇文章中反复引用。今天，我们用一种更简洁的方法重新测量，结果是 54,154 个 token。旧数据偏差了约 8 倍，而它出错的方式比数字本身更有价值。本文旨在进行更正，解释误导我们的方法，并重新计算盈亏平衡点。

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: 测量生成成本最简洁的方法非常直接：生成一个什么都不做的代理。我们给一个最小化的子代理发送了这样一条提示词：“这是一个测量探针。不要读取任何内容，不要调用任何工具。返回两个字符 ‘ok’。”然后我们读取了该代理的记录文件——Claude Code 为每个子代理写入一个 JSONL 文件，其中每个 API 调用都包含一个使用情况块。该探针仅发起了一次请求：

{ “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. 这就是全部事实。生成过程为子代理的上下文窗口填充了 54,154 个 token——包括系统提示词、工具架构、CLAUDE.md 链和技能列表——这些内容被一次性写入了提示词缓存中。没有隐藏的二次付费。

How we got 436k the first time

我们第一次是如何得出 436k 的

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. 最初的方法是：用三个代理（总计 2,150,310 个 token）和一个代理（809,070 个 token）分别运行相同的审查任务，并将差额归因于每个代理的开销。这看起来很严谨——相同的任务、受控的比较、真实的负载。但缺陷在于：一个正在工作的代理会发起多次请求，而每次请求都会重新发送其全部上下文。如果通过汇总运行的总输入 token 来计算，那么相同的 54k 上下文在每次请求中都会被按面值计算一次。按照这种算法，一个迭代八次的代理“成本”约为 8 × 54k ≈ 430k——尽管这八次发送中有七次是按十分之一费率计费的缓存读取，且内容实际上只存储了一次。

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. 因此，436k 并不是生成的成本。它是生成成本乘以我们特定的审查员思考的次数，且使用的是没人会真正支付的面值价格。数字是真的，但附加在它上面的名词（“固定开销”）是错的。我们围绕一个带有响亮名字的方法论产物，规划了一周的委派决策。

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. 委派的有效成本：一次生成上下文的缓存写入（54k × 1.25 写入溢价 ≈ 68k），加上代理自身以 0.1 倍费率重新读取的迭代成本（假设每内部步骤 5.4k——一个 5 步的读取器增加约 27k）。对于一个工作的读取器代理，排除任务内容，有效成本约为 100k。

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. 内联读取的有效成本：读入父进程的 N 个 token 不会只支付一次。它们会留在对话中，并在随后的每次请求中被重新发送。在剩余约 30 次请求的会话中，以 0.1 倍的缓存读取费率计算，内联读取的有效重发量成本约为 3 × N。

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. 交叉点：3N ≈ 100k → N ≈ 33k token。我们取整为 40–50k，以避免随意生成子代理。旧的阈值（基于 436k 的产物计算）是 200k。实际后果很严重：在旧阈值下，100k token 的日志读取会留在父进程中，并悄悄地对剩余的每次请求征税。而在修正后的阈值下，它会被委派出去。错误的常数并非保守——它在我们担心的相反方向上造成了昂贵的代价。

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. 值得一提，因为这部分也适用于你的设置：在简单的会计计算中，上下文大小会乘以迭代次数。如果你通过消耗的总 token 来衡量代理，你衡量的主要是它们思考了多少次，而不是创建它们的成本。缓存定价颠覆了直觉。54k 的生成写入在单位 token 成本上比 30 次相同内容的重读要贵——但重读在原始 token 计数中占主导地位。按面值求和恰恰过度加权了便宜的部分。

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. 你的数字依然是你自己的。54k 是我们的仓库：我们的 CLAUDE.md（减肥后 34KB）、我们的工具界面、我们的技能列表。在减肥之前，仅我们的指令文件就有 548KB——当时运行同样的探针会测出一个完全不同的常数。在你的设置上运行一下这个探针吧；只需要一个提示词和一次记录读取。

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. 我们两次发布了 436k，且两次都诚实地描述了方法——任何人本都可以发现这种混淆，包括我们自己。直到一位队友问了一个五个字的问题：“那个数字是真的吗？”才有人发现。修正过程只花了 11 分钟，其中大部分时间是在等待探针生成。

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. 带有响亮名字的常数会获得其推导过程从未赋予的权威性。如果一个数字指导着日常决策，那么测量过程就应该包含一个“什么都不做”的对照组——就像一个用来“证明不存在”的 grep 命令需要一个正向对照一样。我们现在保留了这个探针代理，每当指令文件发生重大变化时就会重新运行它。这是我们拥有的最便宜的回归测试。