如何降低 Claude Code 的 token 消耗
Claude Code 在开口回答之前就花掉了大部分预算。这篇讲清楚 token 去了哪里,以及什么才真正让这个数字降下来。
编码代理发送的不是你的问题。它发送的是你的问题,加上它自己判断你想表达的一切:它打开的文件、它遍历的目录清单、它执行的每条命令的输出,以及到此为止的整段对话,每一轮都再发一遍。问题本身是零头,围着它的上下文才是账单。
所以那条常见建议,把提示词写短一点,几乎不起作用。你把消息缩短一半,总量只动一个百分点。下面七条按实际价值排序。
1. 直接说出是哪个文件
一次代理会话里最大的可避免开销是探索:代理一路读过去,最后找到你早就打开着的那个文件。每次读取、每次搜索、每次目录列举都会落进上下文,并在这次会话的余下时间里一直待着。
点名文件把一次搜索变成一次直接访问。这比任何选项、任何设置、任何写提示词的技巧都更值钱。
capsul ask '为什么重试循环提前放弃了' --open src/lib/retry.ts文件整份送进去,不必先去找。
2. 话题一变就开新会话
对话历史每一轮都会被完整重发。一个已经进行了四十条消息的会话,在第四十一条时要为这四十条全部付费,不管其中还有多少与当前相关。
所以最费钱的习惯恰恰是最自然的那个:一整天开着同一个长会话。两件互不相干的任务放在同一条线里,就是第二件替第一件买单。话题变了,就关掉重开。
3. 给上下文设一个上限
预算是对允许通过的上下文量的硬性上限,以 token 计。它不是代理觉得信息不够时可以突破的建议值。
capsul ask '给登录路由加上限流' --budget 3000没有任何东西越过上限。被留在外面的部分会被告知。
数字本身没有“存在一个上限”这件事重要。没有上限的代理会把给它的窗口填满,因为它从来没有理由停下。
4. 让模型与任务相称
重命名一个变量和设计一次迁移不是同一种工作,不该跑在同一个模型上。大多数会话之所以全程使用可用的最大模型,是因为那是默认值,而不是因为有人做过选择。
capsul ask '把 auth 模块里的 userId 全部改名为 accountId' --model haiku5. 别让工具输出留在对话里
一次打印两千行的测试运行,就是两千行上下文,并且在这次会话之后的每一轮里继续花掉这些。啰嗦的构建、完整的 git log、没过滤的 find,都一样。
在代理看到之前,先把吵闹的东西过一遍能缩短它的工具。head、grep、--quiet、带过滤的 --json,都比让模型去无视噪声便宜。
6. 前后都要测,而不只是事后测
任何没有在同一任务、同一模型上对照测量过的“节省 token”说法,都是猜测。把你真正在做的事跑两遍,然后比较。
capsul context '把你真实的任务写在这里' --json构建上下文并报告它的开销,不消耗一次请求。
7. 看趋势,别看单轮
单次请求说明不了任何事。token 消耗天然是阵发式的:一轮偏探索的对话可能是一轮偏编辑的十倍,两者都正常。你要看的是一周的曲线。
capsul stats哪些做法没用
- 让模型简短一些。输出 token 只占账单的一小部分,钱花在输入上。
- 把工具关掉。那样代理会请你把文件贴上来,而你贴进去的往往比它需要的还多。
- 换更大的上下文窗口。窗口大一倍,是同一个答案的账单大一倍,不是省钱。
- 太晚才压缩对话。等压缩触发时,通往那一步的每一轮你都已经付过钱了。
常见问题
上下文窗口更大会更便宜吗?
不会,只会更贵。每次请求都按输入 token 计费,窗口大一倍等于邀请你为同一个答案发送两倍的内容。窗口是上限,不是额度。
Claude Code 一轮到底用掉多少 token?
这几乎完全取决于代理探索了多少,而不是你的消息有多长。一轮读四个文件再跑一次测试,可能耗掉数万输入 token;同一个问题若点名了文件,只需其中一小部分。
输出 token 重要吗?
远不如输入重要。一段长回答不过几千 token,产生它的上下文常常是这个数的十到一百倍,而且下一轮还会重发,回答却不会。
发得更少会让回答变差吗?
发得更少不等于发得更糟。capsul 的基准测试把答案校验和 token 计数并排记录,正是为了让“用错误答案换来的节省”显出原形。有的行多得到一个锚点,有的行少一个,两者都公布。
$ npm i -g @penra/capsul