Claude Code省Token实测：同样修复，少用63%token

同样的Bug，为何token消耗差了近3倍？

一个很反直觉的现象：修复同一个bug、用同样的代码、得到同样的结果，一套配置消耗了9.1万token，另一套只用了3.4万token。差距超过2.6倍。这不是偶然，而是Claude Code的token计费机制在起作用。

Rocket Launcher团队用一个固定的实践项目做了严谨测试——每次运行前重置环境，每个测试跑三次取中位数，基于Claude Code 2.1.293版本。他们还给出了一个诚实的前提：所展示的成本是API官方标价，无法反映你所在订阅计划对token的实际加权方式。但token计数本身是真实可复现的。

理解token去向的关键在于：每次你发消息，Claude Code都会把整段对话重新发送一遍——包括可用工具列表、系统指令、你的 CLAUDE.md 文件、技能（skills）以及此前的全部对话。哪怕你只回一个"OK"，从脚本运行时也会发送约1.65万token。

让缓存保持温热：同样请求便宜近8倍

为了控制成本，Claude会把对话开头缓存起来，已读过的文本以极低价格重新读取。测试一验证了这一点：同一个1.65万token的请求发送两次，第一次需要写入缓存，成本2.6美分；第二次直接读缓存，只要三分之一美分——同样的token便宜了近8倍。

关键陷阱在于：只要你改动请求最开头的一行，Claude就会重建整个缓存，相当于冷启动。在该测试环境下，温缓存可维持约1小时。实用建议是——工作时保持一套固定配置，不要在会话中途修改。

Claude的提示缓存（Prompt Caching）是Anthropic在API层面提供的一项优化机制。其原理是：当一段文本在多次请求中保持不变且位于对话开头时，服务端会将这部分内容的KV缓存（Key-Value Cache，即Transformer注意力层的中间计算结果）保留在内存中。后续请求读取缓存内容时，按"缓存读取token"计费，价格约为普通输入token的十分之一。写入缓存时则按略高于普通输入的价格计费一次。

缓存命中的前提条件非常严格：前缀必须完全一致，且必须超过一定长度阈值（通常为1024 token）。这解释了为何改动请求第一行就会导致整个缓存失效——缓存匹配是从头部逐字节比对的，任何前缀变化都会导致缓存完全未命中。Claude Code的系统提示、工具列表、CLAUDE.md等内容天然位于对话前部，因此保持它们稳定是维持缓存命中率的核心策略。

只加载你真正要用的东西

测试二对比了两种项目配置。精简版（Lean）只有简短的 CLAUDE.md，发送1.65万token；臃肿版（Fat）有356行的 CLAUDE.md、20个技能和3个MCP服务器，每条消息发送2.15万token，多出5000。

想看清token花在哪里，可以用 /context 命令，它会列出系统提示、工具、记忆文件、技能和对话各自占多少。

更激进的做法是手动选择加载哪些工具。作者只保留了五个核心工具——Read、Edit、Search、Find 和运行命令——并关闭所有技能，结果单条消息降到7200 token，不到精简版的一半、臃肿版的三分之一。

在真实修bug任务中（九次运行、两种修复方案），Fat用了9.1万token，Lean用了7万，而精简工具配置只用3.4万——比Lean少52%，比Fat少63%。代价是真实存在的：五工具模式下Claude无法浏览网页或调用其他工具，只适合专注型任务，不适合所有场景。

想找出从未使用的技能，打开 /plugin 进入stats标签页，它会显示每个技能的体积、运行频率和最后使用时间。作者的项目里有120个技能，使用次数为零。

选对模型：简单任务跑小模型

测试三用同一个失败的测试做对比：Sonnet修复花2.6美分，Opus花4美分，而Haiku只需约六分之一美分。Haiku三次运行全部修复成功，比Sonnet便宜17倍，而且6秒完成（Sonnet需要10秒）。

但作者给出了克制的结论：这只是小项目里的一行bug，说明简单任务可以跑小模型，不代表难任务也能。建议用 /model 命令，对定义清晰的任务先试Haiku，遇到真正困难的任务再为更大的模型付费。

让它搜索，别把文件塞给它

测试四针对大文件。项目里有一个4800行的留言簿文件，问题是"来自日本且获得超过30个赞的条目有几个"，正确答案是15。

三种问法差异巨大：直接提问，Claude自己选择用命令搜索文件，消耗5万token，每次答案都对；要求Claude读整个文件，消耗13.4万token（2.6倍），成本是12倍；用 @ 符号附上文件，介于两者之间，7.9万token。

结论很清晰——提出问题，让Claude自己去搜索，不要主动把文件丢给它。

把大段阅读交给更便宜的子代理

测试五引入了sub-agent（子代理）概念：第二个Claude在自己的窗口工作，只把答案传回。让Sonnet坐镇、把阅读交给Haiku子代理处理同一个大文件，答案同样是15，三次全对。Sonnet自己读全文花14美分，交给Haiku读只花2美分，便宜7倍——总token数更高，但都是廉价的Haiku token。

但这不总是划算。在小任务上（从20个小文件里取列表），成本反而从1.5美分涨到2.4美分，因为子代理有自身的启动开销。原则是：阅读量大就委派，量小就自己做。/usage 界面也会提示哪些简单子代理可以换用更便宜的模型。

子代理（Sub-agent）在Claude Code中是指由主会话动态启动的独立Claude进程，它拥有自己的上下文窗口，完成任务后只将结果文本返回给主代理。这一机制的经济逻辑在于：子代理消耗的token完全按其自身所选模型计费，不会污染主会话的上下文。当一项任务主要由大量文本读取构成（例如扫描数千行日志或大型文件），将其委派给Haiku处理，主会话（Sonnet或Opus）只需接收一条简短的结论性回复，从而将大批量的输入token从高价模型转移到低价模型上。

子代理本身有固定的启动开销——它需要初始化自己的系统提示和工具列表，这部分成本在任务体量很小时会抵消价格差带来的收益。因此，子代理策略适合"读取量远大于推理量"的场景，而不适合只需读取少量文本就能完成的简单查询。

最流行的技巧却让成本涨了近7倍

测试六检验了那条广为流传的建议：会话变长时运行 /compact 来节省token。作者构建了一个带4.2万token历史的会话，然后用三种方式追加一个问题。

结果令人意外：留在原会话只花0.9美分；开新会话花1.8美分（Claude要重读代码）；而先compact再问竟花了6美分——比什么都不做贵了近7倍。原因是Claude要先写一份摘要，再围绕摘要重建缓存。

不过compact确实能让后续消息变小（约减少2.4万token），大约再发11条消息后才能回本。所以只在会话真的很长且你要继续工作时才用，别在每个问题前都compact。

另一个有用设置是effort（努力程度）：同样的代码审查，低档写470 token，高档写1200 token，低档便宜65%、快5秒，六次运行都找到了同一个主要bug。而给子代理设置effort则没有带来收益，成本翻倍，不推荐用它来省token。

/compact命令的工作原理是：Claude读取当前会话的全部历史，生成一段压缩摘要，用该摘要替换原始对话记录，从而缩短后续请求的上下文长度。成本上涨的原因有两层：第一，生成摘要本身需要将全部历史作为输入一次性读取，这是一笔立即发生的高额支出；第二，摘要作为新的"前缀"与原有缓存完全不同，系统必须重新为其建立缓存，相当于一次完整的冷启动。原本已经缓存的大量内容全部失效，后续若干条消息都要按非缓存价格计费，直到新缓存逐渐预热。

因此，/compact的收益是递延的——它让每条后续消息变小，但前期一次性成本较高。只有当你确定会在同一会话中继续发送大量消息时，这笔"投资"才能回本。对于即将结束的会话或临时性的单次查询，compact会造成纯粹的成本浪费。

自建实时Token计量器

作者最想分享的是一个实时token计量工具。Claude Code有一个status line功能——底部可以运行任意脚本并以JSON格式接收会话数据。他们用25行Python就实现了：实时累加会话中每个请求，显示模型、上下文大小、本次prompt的token数及缓存比例、会话总量、成本以及缓存是否温热。

效果是：问一个小问题，可以看到发送了多少token、86%命中缓存；再问一个，整个会话累计10.7万token，几乎全部缓存命中，花费不到半美分。你能在工作时实时看到消耗，而不是撞到额度上限后才知道。只需在设置里加一行即可开启。

实测结论排序

按测得效果排序，六条有效建议是：1）保持缓存温热；2）只加载你真正用的东西；3）选择匹配任务的模型；4）提问而非附文件；5）把大段阅读交给Haiku；6）适时保存。应当跳过的两条是：过早compact、给子代理设effort。

作者坦诚地给出了局限：仅基于一个小项目、每项三次运行，你的数字会随代码和版本更新而变化；成本是官方标价，实际计划计费可能不同；交互式会话起始体量也更大（约2.7万token）。但他强调，这些变更的优劣顺序每次测试都成立，且所有测试都可复现。建议用 /context 画出你自己的token地图，用usage报告做前后对比。