Claude Code 用久以后，很多人都会遇到同一个问题：明明没写多少代码，使用额度却掉得很快。
最容易想到的办法，是频繁执行 /clear，或者每完成一个小步骤就重新开会话。另一种做法则完全相反，一个会话从早用到晚，觉得前面读过的文件都在上下文里，继续聊肯定更省。
这两种习惯都不太理想。
Claude Code 的 Token 消耗不只取决于你刚输入了多少字，还和当前上下文有多大、是否命中 Prompt Cache、用了什么模型、调用了多少工具以及产生了多少 Thinking Token有关。
本文根据 2026 年 8 月 Claude Code 与 Claude Platform 官方公开文档整理。Claude Code、模型版本、上下文策略和套餐限制更新较快，具体行为以当前版本为准。
Claude Code 为什么聊得越久，Token 消耗越明显？
Claude Code 并不是只把你最新输入的一句话发给模型。
一个已经工作很久的会话，通常还包含系统指令、CLAUDE.md、之前的对话、工具调用结果、读过的代码以及其他仍保留在上下文里的信息。
Claude Code 每次请求都需要处理当前会话中仍然有效的上下文，工具调用也可能继续产生新的模型请求。因此，一个已经积累大量上下文的会话，即使最后只问一句很短的问题，背后处理的内容也可能不少。
不过，这并不意味着 10 万 Token 的历史内容每轮都会按照普通输入价格重新完整计算。
Claude 使用了 Prompt Caching，也就是提示缓存。
这也是为什么看到上下文变长以后立刻 /clear，并不一定更省。
Prompt Cache 是怎么帮你省 Token 的？
可以把 Prompt Cache 理解成模型对重复输入建立了一份可复用的计算结果。
Claude 的缓存结构会围绕工具定义、系统内容和消息历史形成可复用前缀。
如果下一次请求前面的大段内容与之前一致，系统可以命中已有缓存，只处理后面新增或发生变化的部分。
按照 Claude API 当前的公开计费规则，缓存读取价格明显低于普通输入 Token。5 分钟缓存和 1 小时缓存的首次写入会有额外成本，但后续只要持续命中，就能减少大量重复计算。
需要注意，这套价格主要用于理解 Claude API 的成本结构。Pro、Max 等订阅用户使用 Claude Code 时，并不是每一条消息都直接按照 API 价格表单独付款，但 Prompt Cache 仍然会影响使用额度和整体计算量。
缓存真正重要的地方，在于它避免了反复处理一大段完全相同的上下文。
例如一个会话前面已经包含项目规则、几十轮讨论和相关代码，你继续在这个会话尾部追加消息，大量已有前缀仍有机会复用缓存。
如果前面的内容发生变化，情况就不同了。
Prompt Cache 按前缀匹配。工具定义、系统内容或者其他靠前位置发生变化，都可能让后面的部分无法继续复用之前的缓存。
所以 Claude Code 省 Token 的第一个原则不是：
永远不要开新会话。
也不是：
做完一步马上
/clear。
而是：
相关任务尽量保持上下文连续，无关任务不要拖着旧上下文继续跑。
什么时候继续当前会话，什么时候 /clear？
这是最值得养成习惯的一件事。
适合继续当前会话
如果你还在处理：
- 同一个 Bug；
- 同一个功能；
- 同一批文件；
- 同一次重构；
- 前面的讨论仍然直接影响后面的实现；
通常没必要为了“省 Token”强行新建会话。
尤其是在短时间连续工作时，Prompt Cache 可以复用大量已有上下文。
按照 Claude Code 当前公开说明，订阅计划中的 Prompt Cache 生命周期通常可以达到 1 小时；如果使用按量计费 Usage Credits、API Key 或部分云平台服务，则常见默认缓存生命周期更短。
只要当前任务仍然相关，保持会话连续通常比不断重新加载项目规则、工具和代码背景更合理。
适合 /clear 或新建会话
如果刚修完登录功能，下一件事准备研究完全无关的支付模块，就没必要继续背着前面的调试记录。
Claude Code 官方当前也建议，在切换到无关任务时使用 /clear。
原因很简单：旧上下文即使能够命中缓存，也不是完全免费，而且还会占据上下文空间。
同样，如果一个会话里已经尝试了大量错误方向、读取了许多无关文件、堆积了很长的测试结果和日志，也可以考虑重新开始。
可以简单这样判断：
| 当前情况更合适的操作 | |
|---|---|
| 同一个任务连续开发 | 继续当前会话 |
| 前面的代码和讨论仍然有用 | 继续 |
| 切换到完全不同的功能 | /clear 或新会话 |
| 会话已经积累大量无关内容 | 新会话或 /compact |
| 大型会话闲置很久后重新回来 | 视上下文价值决定是否重开 |
| 只是上下文变长，但内容仍高度相关 | 不必急着清理 |
Claude Code 现在还提供 /usage 来帮助分析近期使用情况。
如果 long context、cache misses 或其他因素占用了比较明显的使用量，可以先看 /usage，而不是凭感觉判断是不是会话太长。
1M 上下文能用，但没必要每个任务都塞满
Claude Code 的上下文能力已经比早期版本大很多。
截至 2026 年 8 月，Claude 新一代模型已经支持非常大的上下文窗口，Claude Code 在满足模型、套餐和服务商条件时也可以使用 1M Context。
这里有一个常见误解：
1M 上下文并不意味着超过 200K 以后就会突然按照两倍价格收费。
现在更值得关注的问题，是会话到底有没有必要变得那么大。
窗口能装 1M，不代表普通编码任务应该把它装到 1M。
Claude Code 官方的成本说明已经把 long context 和 cache misses 列为高使用量的常见原因。
一个会话积累得越大，遇到缓存未命中时，需要重新处理的上下文就越多。哪怕缓存一直命中，持续读取一个非常大的上下文本身也不是零成本。
所以 1M 更适合：
- 大型代码库分析；
- 跨很多文件的复杂重构；
- 长时间持续进行、上下文高度相关的任务；
- 确实需要保存大量前置调查结果的工作。
普通的 Bug 修复、改一个组件、补测试、调整一个接口，通常没有必要为了避免压缩而无限扩大上下文。
可以提前设置自动压缩
Claude Code 已经提供 /autocompact 配置。
例如希望按照大约 200K Token 的窗口进行自动压缩，可以使用：
/autocompact 200k也可以通过环境变量配置：
{
"env": {
"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "200000"
}
}自动压缩的意义不是单纯“砍掉历史记录”。
Claude Code 会尝试把较早的上下文整理成摘要，把真正影响当前任务的信息留下，同时释放一部分窗口空间。
如果完全不想使用 1M 上下文，也可以使用相应环境变量关闭：
{
"env": {
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
}
}与其简单理解成“1M 很贵，所以一定要关掉”，更合理的做法是：
保留大窗口能力，同时给日常任务设置合适的自动压缩范围。
模型和 Effort 选错，可能比上下文更费
省 Token 不能只盯着 /clear。
模型选择同样重要。
Claude Code 当前仍然可以根据任务复杂度选择不同模型。日常编码没有必要所有任务都使用最高等级模型。
实际可以大致这样分：
- 改小 Bug、补类型、简单测试：优先较高性价比模型；
- 普通功能开发：使用主力编码模型；
- 大范围架构分析：再考虑更强模型；
- 很简单而且独立的子任务：可以交给轻量模型或子智能体。
具体模型价格会随着 Claude 产品更新而变化，所以没必要在文章里长期记死某一个价格倍率。
更重要的是理解：
更强的模型通常意味着更高的计算成本，不是所有任务都需要最高配置。
还有一个经常被忽略的地方是 Effort。
Claude Code 支持调整推理强度。范围清楚的小任务，可以降低 Effort；架构设计、复杂调试和需要多步推理的问题，再提高推理预算。
例如修改 CSS 间距、重命名变量、调整一处配置，没必要和分析大型系统架构使用完全相同的推理等级。
长会话中不要为了便宜频繁换模型
这也是一个比较反直觉的地方。
Claude Code 不同模型之间的 Prompt Cache 并不能简单共享。
假设已经用某个模型工作了很长时间，这时候为了处理一句简单问题临时切换另一个模型，新模型可能需要重新读取大量历史上下文。
结果就是：单价虽然下降了，但为了重新建立上下文缓存，实际消耗未必更低。
因此，长会话中不要单纯为了某一条消息便宜一点就频繁切换主模型。
需要不同模型处理独立任务时，可以考虑子智能体，或者使用 Claude Code 提供的模型组合工作方式。
CLAUDE.md、Skills、MCP 都可能悄悄占上下文
很多 Token 并不是聊天过程中产生的，而是在任务开始时就已经进入上下文。
CLAUDE.md 不要写成项目百科
CLAUDE.md 会参与 Claude Code 的项目上下文。
Claude 官方建议保持它简短，把真正需要长期遵守的内容放进去。
适合长期保留的是：
- 项目结构；
- 构建和测试命令；
- 长期编码规范；
- 必须遵守的项目约束。
不适合一直塞进去的是：
- 某一次数据库迁移的完整教程；
- 一次性的发布流程；
- 很少使用的 API 文档；
- 大段参考资料；
- 只影响一个特定任务的说明。
这些内容更适合放到 Skills 或独立项目文档中，需要时再让 Claude 加载。
这样做还有另一个好处：
CLAUDE.md 越短，真正重要的规则越不容易被大量说明淹没。
MCP 不要装完以后全部常驻
MCP 很方便，但同样会带来上下文成本。
Claude Code 已经在持续优化 MCP 工具定义的加载方式，并不会简单地把所有工具的全部信息永久塞进上下文，但 MCP Server、工具说明以及调用结果仍然会带来额外开销。
如果一个操作本身可以通过成熟 CLI 很轻松地完成，就没有必要为了它长期挂一个 MCP。
例如：
- GitHub 可以使用
gh； - AWS 可以使用
aws； - Git 操作直接使用
git； - 文件搜索使用
rg、find等工具。
长期不用的 MCP 服务，可以关闭。
一句话：
MCP 应该解决 CLI 不好解决的问题，而不是替代所有命令行工具。
真正有效的省 Token 方法，是减少无用上下文
与其花很多时间研究怎么让 Claude 少回答几句话，不如先减少它根本不需要看到的内容。
比如，不要直接把一万行日志完整复制进聊天框。
更合理的指令是：
错误日志在 logs/app.log，只检查最近一次启动以后与数据库连接有关的 ERROR。Claude 可以先通过 grep、rg、tail 或其他命令过滤，再读取真正相关的几十行。
原本可能需要塞进上下文的几万 Token，就可能只剩几百 Token。
同样，提问范围越清楚，Claude 越不容易为了“先了解一下项目”到处读取文件。
比起：
帮我优化这个项目。
更有效的是：
检查
src/auth/login.ts的登录校验，只处理参数验证和错误返回，不修改数据库结构。
后者已经给出了：
- 目标文件；
- 修改目标；
- 工作边界；
- 不允许修改的部分。
模型需要探索的范围自然会小很多。
最便宜的 Token，始终是没有进入上下文的 Token。
可以限制不应该读取的目录
如果项目里有很多 Claude 根本不需要分析的文件，可以使用 permissions.deny：
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"Read(./node_modules/**)",
"Read(./build/**)",
"Read(./dist/**)"
]
}
}这样可以减少 Claude Code 的文件工具读取这些目录，也能降低无关文件进入搜索范围的概率。
不过安全限制和 Token 优化需要分开理解。
permissions.deny 可以限制 Claude Code 的部分读取工具，但如果真正目的是防止模型或命令访问敏感文件，还应该结合 Sandbox 等更严格的系统级访问控制。
不要把一条文件读取规则当成完整的安全隔离方案。
子智能体能省主上下文，但多智能体不一定省 Token
子智能体真正有价值的地方，不是“再开一个 Claude 会更便宜”，而是：
把大量过程信息隔离在主会话之外。
例如这些工作很适合交给 Subagent：
- 跑完整测试；
- 阅读大量日志；
- 查文档；
- 做代码审查；
- 调查某个独立 Bug；
- 搜索大型代码库里的调用关系。
子智能体可以自己处理大量文件和输出，最后只把结果摘要交给主会话。
这样，一段几千行的测试日志不会在接下来的几十轮里一直占着主会话上下文。
但 Agent Teams 是另一回事。
多智能体并行意味着多个模型实例同时工作，每个成员都有自己的上下文，也都会产生 Token 消耗。
它解决的是：
并发和任务拆分。
而不是：
怎样用最少 Token 完成任务。
所以没有必要为了“省额度”把一个本来单智能体就能完成的问题拆成五个 Agent。
Subagent 更适合做上下文隔离，Agent Teams 更适合确实能够并行拆开的复杂任务。
Claude Code 省 Token，记住这 8 条就够了
不需要每天计算缓存命中率，也不用看到上下文变长就紧张。
实际开发中，把下面几条养成习惯，已经能解决大部分 Token 浪费：
- 同一个任务没做完，不要为了省 Token 频繁
/clear。 - 换成完全无关的任务，就开新会话，不要长期背着旧上下文。
- 1M Context 是容量，不是目标，不需要故意把它填满。
- 给日常会话设置合理的
/autocompact阈值。 - 根据任务复杂度选择模型，不要所有事情都使用最高配置。
- 简单任务降低 Effort，复杂任务再增加推理预算。
- 精简
CLAUDE.md，关闭不用的 MCP，把专项资料放到 Skills。 - 少粘贴大文件和长日志，让 Claude 先搜索、过滤，再读取需要的内容。
最后可以把 Claude Code 的 Token 管理归结成两个目标：
让有价值的上下文尽可能复用，让没价值的上下文尽量不要进入会话。
频繁开新会话会损失上下文连续性和缓存优势，一个会话从早堆到晚又会让每次请求越来越重。
比较合理的工作习惯是：
同一件事连续做，任务明显切换就清；大内容先筛选，真正复杂的任务才给更多上下文和推理预算。
如果最近发现 Claude Code 的额度突然下降得很快，可以先运行 /usage，看看 long context、cache misses、Skills、Subagents、MCP 或其他工具到底占用了多少资源。
很多时候，真正的问题并不是“Claude Code 突然变贵了”，而是某些本来不起眼的上下文和工具，在每一轮请求里不断重复消耗额度。
参考资料
本文主要参考 Anthropic 官方公开资料，具体功能和规则可能随 Claude Code 版本更新而调整：
- 来源：Anthropic Claude Code 官方文档，code.claude.com
- 来源：Anthropic Claude Platform 官方文档，platform.claude.com
Claude Code 更新频率较高，模型名称、套餐额度、上下文窗口、Prompt Cache、自动压缩以及命令配置都可能发生变化。实际使用时建议优先查看 Anthropic 当前版本官方文档。