Claude Code 省 token 三条原则

token 在 Claude Code 里是怎么烧掉的

Claude Code 是那种会自己动手的编程代理:读你的文件、跑命令、改代码,你在一旁看着,偶尔纠偏。这种自主性的代价是,它的上下文窗口(一次会话能记住的信息容量)里装的是整场对话——你发过的每条消息、它读过的每个文件、跑过的每条命令输出,全都占地方。官方文档给过一个直观参照:一次调试会话或代码库探索,就可能烧掉几万 token。

上下文窗口也是 Claude Code 里最金贵的资源。窗口越满,表现越差:模型开始"忘事",忘记你早先的指令,出错变多;出错又要你补充、它返工,又烧一批 token,恶性循环。所以在 Claude Code 里省钱,逻辑和普通聊天不一样:不是少问两句,而是管住这个总盘子。官方文档讲的省钱思路就是以下三条。

入口:先把上下文占用"看见"

省钱的起点是让消耗可见。官方 best practices 给了一个明确入口:用自定义状态栏(custom status line)持续跟踪上下文占用,在你界面里加一行常驻显示,随时看到当前上下文用到什么程度。这是官方点名推荐的做法,并顺势把更细的省钱策略指向 Reduce token usage 一节。

启用状态栏的具体配置写法,要去 Anthropic 官网的 Claude Code 文档里找;搜 custom status line 和 reduce token usage 这两个关键词,照着文档配好,入口就到手了。先能看见数字,才知道哪一步最烧;看不到消耗,省钱无从谈起。

原则一:给 Claude 一个能自己跑完的验证

Claude 的默认停点是"看起来做完了"。没有验证手段时,它做完就停,错误留给你发现,你再让它改——每一轮返工都在烧 token。官方开出的药方是给它一个能跑、能出 pass/fail 的检查:测试套件、构建退出码、linter(自动检查代码风格和问题的工具)、把输出和预期对比的脚本、浏览器截图和设计稿的对比,都算。

同一个需求,写法不同,烧的 token 差很多。让它"写一个校验邮箱地址的函数",不如把预期给全:"写一个 validateEmail,user@example.com 返回 true,[email protected] 返回 false,写完跑一遍测试。"让它"把仪表盘做得更好看",不如贴一张设计截图:"照着实现,做完截图对比原图,列出差异并修掉。"给验证不是额外加码,是让 Claude 自己迭代到通过为止,把你从人工验收回路里解放出来——省掉的是后面几轮返工。

原则二:权限模式选对,别把安全也省了

Claude Code 默认每条命令、每次改文件都要你批准。官方观察到,这类请求用户最终批准了 93%——既然九成都会批,那每一步都停下来问,就更像一种打断。打断本身烧不了多少 token,但它让你更难全程盯住,容易攒下一堆没检查的改动,事后返工才真烧。

想少打断,官方给了三条路:内置沙箱(把工具隔离,安全但每个新能力都要配置,维护成本高)、启动时加参数：--dangerously-skip-permissions(跳过所有确认,零维护但基本没有防护,大多数场景不安全)、以及 auto mode(让模型侧的机制替你审批,危险动作拦下,安全的直接放行)。官方内部还记着一份"代理失控"事故日志:误删远程分支、把工程师的 GitHub 令牌传到内网、对着生产数据库跑迁移——都是模型过度积极闯的祸。少点几下没问题,风险上限得自己拿捏。

关于"缓存省钱"的一句实话

网上常说的 prompt caching(提示词缓存)确实能大幅降成本,但它是 API 接口层的机制:开发者在请求里加 cache_control 字段才能启用,官方提供 5 分钟和 1 小时两种缓存时长。不碰 API 的普通用户,这条先放一边。Claude Code 官方文档谈省 token,谈的就是上面三件事:盯住上下文、给验证闭环、管好权限模式。