前几天翻 ~/.claude/projects/，一个会话一个 JSONL。本来只想看看哪个项目最费，翻到一半发现看错地方了——账单最大的那笔，不在"它想了多久"，在"同一坨东西它又读了一遍"。
AI Dive 那位上个月把自己一个月 455 个会话、六万多次请求的日志翻出来数了一遍。第一个坑就够说明问题：同一个请求在日志里差不多出现两次，直接按行求和是 186 亿 token，按 message id 去重之后是 93 亿。账面先虚了一倍。他后面给的所有数字都是去重值。
真正扎眼的是 subagent。2,631 次运行，吃掉 48% 的 token，输出占 64% 的输出 token。
也就是说，"subagent 是我的分身，把活甩出去"这个模型是错的。它不是分身，它是新人入职——每入职一次，员工手册从头念一遍。
第一次请求的中位数，47,117 token。四万七！
这里面是系统提示、工具列表、skill 列表，重新发一遍。注意这个数字跟你任务写得多不多关系不大，跟你那份家当有多厚关系最大。同一批人里另有在工具集很小的机器上测的，同样的启动只花 16,000 到 21,000。
有人当场就试了：把 subagent 的工具白名单砍到它真正会用的那三个命令，初始载荷直接腰斩以上。还有人说，光把工具集限制一下，启动从四万七掉到五千。
⚡ 这一下比任何"优化 prompt"的技巧都值。
我现在的写法是每个 subagent 的 frontmatter 里钉两样东西，模型和工具：
---
name: test-runner
model: haiku
tools: [Bash, Read, Grep]
---
模型那条，日志里的证据很直接。默认情况下 subagent 继承主会话的模型，而在那一个月的记录里，最小那个模型只处理了不到 1% 的 subagent 请求。也就是说我们都在拿主力模型跑测试、跑 lint。
他有句话我很认：能主会话干的活就别开新 subagent。开之前先问一句，这活是不是就是在等一条命令跑完——是的话，主会话里跑就行。
第二个改动，是那种"我不用它的时候它也在烧钱"的东西。
订阅用户的主会话 prompt cache 是一小时，subagent 是五分钟。日志跟这个对得上，一分不差：所有 subagent 的缓存写入都落在五分钟档，所有主会话的写入都落在一小时档。
五分钟对于一个挂在那等构建的 subagent 意味着什么，不用我展开。
有个 Reddit 上的老哥，subagent 挂着等长构建，改完之后缓存写入从 1,200 万 token 掉到 300 万。
设置就一行：
"subagentPromptCacheTtl": "1h"
但这里我得踩一脚刹车。一小时档的缓存写入本身更贵——五分钟档是基础输入价的 1.25 倍，一小时档是 2 倍。所以这个设置不是默认该开的：
- subagent 会挂着等东西（构建、下载、别人 review）→ 开
- subagent 是短促爆发，几十秒跑完就退 → 别开，开了反而多花
老哥那个例子是第一种情况。你要是第二种，跳过这一段。
第三个改动针对"我离开一会儿回来"这个动作，这个我自己体感最深。
日志按两次请求之间的间隔分组，缓存写入的中位数是这么走的：
- 间隔 5 分钟内：1,176 token
- 间隔 5 到 60 分钟：1,327
- 间隔超过一小时：130,332
从一千二到十三万，中间隔的是一次午休。
冷回来那一刻，会话里压着大约 17.5 万 token 的上下文，大部分都重写了一遍。把缓存写入按一小时档的 2 倍折一下，一次冷返回约等于 26 万普通输入 token。这就不是"我没在用它"了，这是我人不在，账在走。
所以"任务做完、趁缓存还热的时候把会话清掉"这条建议，我现在照做了。清掉不丢东西，要回去的时候接受它用 summary 恢复就行。⚡
至于那个按间隔分组的冷返回样本只有 79 个，而且里面混着压缩而不是纯闲置的情况——他文章里自己标了。我也标一下，不装作这条是铁律。
说到这我岔一句。有人拿同样的 29 个任务把 effort 各档跑了一遍，平均成本从 low 的 2.50 美元到 max 的 8.84 美元，结果 medium 过了 28/29，比所有更高的档都多。我不拿这个当依据——那是别人跑的、用的旧模型、单位是美元——只说方向：日常用 medium，错了很贵的时候才上 high，max 基本不用。这是另一码事，跟这篇的主线没关系，就是顺手一提。你要拿它当结论用，出了事别找我。
最后说说那些到处被安利的"省额度"招数，我要泼一盆冷水。
砍 MCP 服务器、关 prompt suggestion、过滤 shell 输出，这三样有个共同点：省下的量跟着上下文大小走，而且小得不成比例。有人在同一个帖子里量到关 prompt suggestion 是 3-4%，有人量过滤 shell 输出是千分之一左右。工具定义现在默认是延迟加载的，你砍掉一堆服务器，省下的可能就是几百 token 的量级。
别指望这三样给你换回一周。它们不是没用，是被安利得太重了。
还有一个细节我不想漏。subagent 吐回来的内容会记进主会话，之后主会话每转一轮都要再读它一遍。所以你 fan-out 出去的真实成本，比 subagent 那几行数字显示的还高——大概是返回内容的 token 数乘以后面的轮数。这条没法直接量化，但它是你"多开几个并行"之前该想一秒的东西。
回本账这么算：改的是 subagent 的 frontmatter 两行、settings 里一行、外加一个改掉的习惯，十分钟以内能弄完。这周下来省出的额度够我从容跑好几天。不是第一次在这安利小玩意了，但这次动的是支出侧，跟绑个键位那种省几秒的性质不太一样，那个是顺手，这个是省钱。
老实说这招有前提：你得真的在用 subagent。如果你主会话一条路打到底，前两条跟你没关系，第三条（趁热清会话）才是你的。
你们要是有更省额度的写法，教教我。