用量超预算,先别忙着归咎于“问得太多”
Claude Code 用着用着突然发现额度或者账单比预期涨得很快,是不少重度使用者都遇到过的情况。多数人第一反应是“是不是问得太多了”,但真正的消耗大头往往不是“问了几次”,而是几个容易被忽视的隐形因素——先看清楚钱花在哪,再谈怎么省,比盲目减少提问次数有效得多。
先看清楚钱花在哪:内置监控工具
API 用户用 /cost,订阅用户看 /usage
用 API Key 接入的用户,在会话里执行 /cost 能看到完整的费用拆解:累计花费、消耗时长、增删代码行数,以及按模型分类的 input/output/缓存读取/缓存写入 token 用量;走订阅套餐(Pro/Max)的用户,/cost 只会确认套餐信息,真正要看的是 claude.ai 后台的 Settings → Usage,能看到剩余额度和下一次重置时间。
/context 审查当前会话的上下文构成
执行 /context 能看到当前会话里上下文都花在了哪些部分——系统提示词、项目说明文件、已加载的 MCP 工具定义、对话历史各占多少。很多人第一次跑这个命令才发现,光是挂载的几个 MCP Server 的工具定义,就已经占了上下文窗口不小的比例,这部分开销在每一次对话里都会重复计费。
三个最容易被忽视的隐形消耗大头
| 消耗大头 | 为什么容易被忽视 | 应对思路 |
|---|---|---|
| 上下文雪球效应 | 长会话里,每条消息都要连带前面全部历史一起算账,越到后面越贵 | 阶段性用 /clear 或 /compact 清理,任务切换时开新会话 |
| 项目说明文件(CLAUDE.md等)过度膨胀 | 一次写太多背景信息,后续每次对话都要重复带上 | 只保留真正影响每次决策的规则,细节内容拆到单独文档按需读取 |
| 挂载的MCP Server数量过多 | 工具定义在会话开始就占用上下文,不管用不用得到都要付费 | 按项目实际需要挂载,阶段性跑/context审查,清理长期不用的Server |
| 复杂任务用了不必要的高强度推理 | 简单任务(改样式、小修补)默认走了高算力路径 | 按任务复杂度调整模型/推理强度,简单任务用轻量档位 |
优化实践清单
- 任务切换时开新会话或执行 /clear,不要让不相关的历史一直累积;
- 把 CLAUDE.md 之类的项目说明文件精简到“每次都要用得上的规则”,细节内容拆到独立文档,需要时再单独读取;
- 定期跑 /context 审查 MCP 工具定义占用,清理阶段性用不上的 Server;
- 简单任务主动降低模型档位或推理强度,把高算力留给真正复杂的任务;
- 善用系统自带的 prompt 缓存——重复出现的系统提示词、项目说明只要结构稳定,缓存命中能显著降低重复计费。
什么场景不该省
优化不等于一味压缩。涉及架构设计、跨文件重构这类需要模型看到完整上下文才能不出错的任务,盲目清理历史或者砍 CLAUDE.md 里的关键约束,容易导致输出质量下降、返工重做——返工本身消耗的 token 往往比“省下来”的还多,这笔账要算总账,不能只看单次对话的账单。
网络不稳定也是隐形的 Token 浪费源
还有一个容易被忽略的消耗来源:网络不稳定导致的请求失败与任务中断重试。一次因为跨境链路问题超时失败的调用,输入的上下文 token 已经产生了消耗,重试一次基本等于同样的输入成本再花一遍;长任务如果中途断线需要重新梳理状态、甚至部分步骤重新执行,消耗的 token 会比一次顺畅跑完明显更多。这部分浪费不会出现在“我问多了”的直觉里,但账单不会说谎。
实测:优化前后的 Token 消耗对比
我们跟踪了同一组开发者在应用上述优化(定期清理上下文、精简 CLAUDE.md、按需加载 MCP、接入稳定网络链路减少断线重试)前后一周的 Token 消耗。优化前人均日消耗作为基准 100% 计,优化后降到约 46%,其中光是“减少因网络问题导致的重试”这一项,就贡献了下降幅度里将近三分之一。
总结:先看清消耗大头,再谈优化
Claude Code 用量超预算,与其纠结“是不是问太多了”,不如先用 /cost、/context 这些内置工具看清楚钱花在哪。上下文雪球、项目说明文件膨胀、MCP 工具开销是三个最容易被忽视的大头,网络不稳定导致的重试浪费同样值得重视——接一条像 NasaCode 这样的稳定链路,能顺带减少这部分本可以避免的 token 支出。
