Anthropic 官方指南：教你如何在和Claude Code 对话的时候节省 Token
一个小修复为什么会拖成长会话？这份指南教你看懂额度花在哪里，并在 clear、compact、rewind 与 Subagent 之间做出正确选择。
- 文件、日志和工具结果进入会话后会跟随后续请求；无关内容进入越早、存活轮数越多，额度负担和判断干扰越大。
- 处理时先看跨任务长会话，再看无关上下文，然后检查模型与 Effort 是否过高、提示缓存是否失效。
只改了几行代码，为什么额度已经掉了一截
你让 Claude Code 修一个失败测试。最后的改动可能只有三行；在找到这三行之前，它已经搜索了仓库、打开一批候选文件、跑出几百行测试日志，又在错误方向上试了几轮。
这些过程不会在 Claude 找到答案后自动消失。你每让它继续一次，模型都要再次处理此前积累的系统提示、项目规则、文件、命令结果和对话历史。
这套成本逻辑和传统开发工具不同。编辑器往往免费或按月、按年付费，多修一个 Bug 通常不会增加软件账单；编程 Agent 每完成一个任务都要运行模型推理。无论最终改了几行，它读入和生成的 Token 都会占用 GPU、TPU 等计算资源，同一个任务也会因为使用方式不同而产生不同消耗。
这会造成三个直接痛点：
- 额度掉得很快，却看不出花在了哪里。订阅用户通常只看到使用额度变化，很难把消耗对应到某个文件、某段日志或某次搜索。
- 会话越长，旧信息越难摆脱。缓存可以让重复读取更便宜，旧内容仍然占着上下文，也可能把 Claude 的注意力拉回已经无关的方向。
- 命令都认识，使用时机却容易选错。新任务该用
/clear，同一任务换阶段才考虑/compact，末尾几轮走偏更适合/rewind；Subagent 能隔离噪声，也会产生一套新的成本。
Anthropic 发布这份指南，就是为了回答这些会话管理问题。读完以后，你应该能够判断：当前消耗首先来自长会话、无关上下文、模型与 Effort 过度，还是提示缓存失效；也应该知道什么时候直接给文件、什么时候收短日志、什么时候切断历史，以及什么时候值得把工作交给 Subagent。
原文用同一个失败测试画出了两条路径。直接指出测试文件，Claude 读取测试和实现、修改并验证，五次请求完成；只说“测试挂了”，它需要先搜索仓库、打开候选文件、读取日志，最后走到同一个修复，用了十八次请求。
5 次与 18 次只代表图中的具体场景，不能直接换算成固定成本倍率。它说明了一件更重要的事：代码改动相同，进入会话的过程材料可能完全不同。指南追求的是让 Token 服务于必要的代码、推理和验证，把无关搜索、噪声输出和跨任务残留尽早切断。
五次请求的路径也解释了账单怎样形成。第一轮提交系统提示、CLAUDE.md 和任务；Claude 请求读取测试文件，文件结果追加进会话后再次发送；接着读取实现文件、提交修改、运行测试，最后生成简短总结。每一轮都包含此前的完整会话，但正常追加时，旧的连续前缀可以走缓存读取，只有新工具调用、新文件或新测试结果需要按正常输入价格 Prefill。
所以一次典型调用可能是数万输入 Token，只生成几百个输出 Token。数万输入并不等于全部按正常输入价重算：每轮费用由历史的缓存读取、新增内容的正常输入价和本轮输出价共同组成。理解这一点，才能看懂为什么少一次无意义搜索、中途少切一次模型，可能比压缩最后几十个字更有价值。
接下来先给出六个最常用的动作，再解释它们为什么有效。
先做这六件事
如果暂时不想研究 Token 机制，可以先按下面六条调整使用方式。
- 开局选定模型和 Effort。机械修改用够用的模型，模糊故障和架构判断再提高能力与工作深度。尽量不要在长会话中途频繁切换。
- 把已知范围直接交给 Claude。给出目标文件、失败测试、期望结果和验证命令；界面支持时，第一次就用
@文件名引用。 - 控制命令输出。只跑相关测试，使用 quiet reporter、错误过滤或
tail，别让几百行成功日志留在后续几十轮里。 - 最近几轮走偏时用
/rewind。它从会话末尾裁掉错误分支，前面的缓存前缀仍可能保留。 - 开始新任务前用
/clear。旧任务需要以后找回，可以先/rename，再清空当前上下文。 - 只有过程很吵、主会话只需要结论时才用 Subagent。扫描长日志、完整测试输出和 Git 历史适合隔离；小问题交出去可能更贵。
原文最后一张图给出了影响顺序：先看长会话，再看上下文过多，然后才是模型或 Effort 超过需要，以及提示缓存失效。这个顺序能避免在小处反复节省，却放任旧任务历史每轮重发。
下面这张决策图用来区分四个容易混淆的动作。四种适用边界默认全部可见；选择场景后，变化的是历史被清空、压缩、裁剪还是隔离。
先判断发生了什么，再选择处理动作
选择当前场景，查看历史会留下、压缩、裁掉还是隔离。
使用边界： 需要返回入口时先 rename，再 clear。旧会话仍可恢复，新任务从干净上下文开始。
- 开始另一个任务 ·
/clear - 旧任务已经结束
- 同一任务进入新阶段 ·
/compact - 旧细节已经失去价值
- 最近几轮走错 ·
/rewind - 前面的历史仍然有效
- 过程很吵，只需结论 ·
Subagent - 日志、测试或搜索量很大
第一优先：别让一个会话装下多个任务
Claude Code 的每一轮请求都会携带截至当时的会话内容。第一项任务留下的文件、日志和工具结果，如果继续留到第二、第三项任务，它们就会在后续请求中重复出现。
可以用一个近似关系理解累计负担：
会话负担 ≈ 上下文里累计的内容 × 这些内容还会经历的后续轮数 × 同时运行的独立上下文数。
最后再考虑模型、输出与缓存倍率。这是帮助理解的近似式，Anthropic 没有把它公布为精确账单公式。
原文的三任务示意图呈现了这种累积。第一段历史会被带入三轮，第二段带入两轮，第三段带入一轮；全部塞进一个长会话时，图中的 Token 量达到分会话方案的 1.9 倍。这个数字只属于图中的条件，值得带走的是“旧内容会乘上它之后存活的轮数”。
因此，/clear 应该跟着任务边界使用。它的准确时机是准备开始新任务，不必等到上下文快满。需要保留旧会话入口时，先 /rename 再 /clear。
/loop 也适用同样的判断。每次循环都是一轮完整请求。周期监控如果挂在一个很长的主会话里，会定期携带整段历史；单独开一个新会话，只放循环真正需要的材料更合适。
第二优先：别让无关内容过早进入会话
会话的初始负担早在第一条任务消息之前就可能形成。工具定义、系统提示、CLAUDE.md 和启用的 MCP 服务都可能进入上下文。新会话可以先运行一次 /context，检查启动时加载了什么；当前用不到的 MCP 服务，可通过 /mcp 检查并关闭。
长期适用且足够短的项目规则适合放进 CLAUDE.md。只在特定流程使用的长说明更适合按需加载。判断标准很简单：常驻内容要值得在每一轮都出现。
任务描述也决定了 Claude 是否需要重新发现你已经知道的范围。“测试失败了”会触发搜索和候选文件读取；“修复 utils.test.ts”可以省掉大部分搜索；在支持文件引用的界面里使用 @utils.test.ts，文件还能随第一条消息进入上下文，少一次 Read 工具调用。
文件进入会话后会留在那里。@文件名 省掉的是搜索、读取和一次往返，文件本身占用的上下文不会因此变小。不要在后续轮次反复 @ 同一个文件，否则可能附加第二份副本。CLI、Desktop、IDE 和远程环境对文件引用的支持也不完全相同，应以当前界面为准。
命令输出通常更容易失控。测试、构建、git log 和调试日志都会像文件一样追加进历史。原文发布时，超过 30,000 字符的输出会被写入文件，只把预览和路径放回上下文；这个阈值可通过 BASH_MAX_OUTPUT_LENGTH 调整，也可能随版本变化。更常见的问题是几百行没有触发保护的中等噪声。
这时最有效的动作包括：只运行相关测试文件，使用 quiet reporter，只返回错误附近，按日志级别过滤，或者用 tail 限制行数。例如把 npx vitest run <file> --reporter=dot 这类高频命令连同精简参数写进项目说明，可以省掉猜命令的一轮，也能避免几百行通过日志进入会话。需要统一约束时，还可以按 Claude Code 文档设置 Hook，在高噪声命令执行前自动改写参数。
下面的滑杆展示一段无关内容过早进入会话后，怎样被“内容量 × 后续轮数”放大。它是结构示意，不是 Claude Code 账单计算器。
一次加入，会在后续每轮继续参与处理
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
当前：8,000 个无关 Token 留在后续 8 轮。
第三优先：模型、Effort 和缓存尽量在开局定好
一次请求的价格受三个变量影响：模型、输入与输出阶段、提示缓存状态。
模型要按完成任务的总成本选择
更大的模型通常有更高的 Token 单价。明确的小修复、机械改名和格式调整，使用够用的模型往往更合适；架构判断、模糊故障和跨系统推理，才值得投入更强的能力。
只看单个 Token 的价格也会误判。困难任务上，小模型可能需要更多搜索、重试和验证，最后仍达不到同样质量。选择时应该比较达到可接受结果所需的总工作量。
Effort 会影响模型读多少文件、调用多少工具、验证到什么程度。模型决定能力范围，Effort 调整这一轮愿意投入的工作量。机械任务可以降低 Effort；需要追查和判断的任务则应保留足够深度。
原文还提到 MAX_THINKING_TOKENS=0 可在单次会话中关闭 Thinking，并注明 Fable 5 例外。这类环境变量和模型行为变化快，更适合作为经过当前版本确认后的高级设置，不应当成所有会话通用的默认建议。
输入是整段读取，输出是逐 Token 生成
请求先经过 Prefill，模型读取工具定义、系统提示、CLAUDE.md、消息、文件和命令结果。这段计算发生在模型运行所用的 GPU、TPU 等硬件上。随后进入 Decode，逐 Token 生成思考、工具调用和可见回复。
Anthropic 当前列出的主流 Claude 模型，输出 Token 单价大约是输入的 5 倍。让 Agent 少输出无用说明确实有帮助；长会话里数量更大的部分，往往仍是每一轮重新携带的输入历史。
提示缓存会自动工作，但不会清走历史
Claude Code 会自动管理提示缓存，不需要用户额外开启。它仍会把完整会话重新发送；请求开头与上一轮保持一致时，服务端可以复用缓存状态。Anthropic 当前 API 定价中，缓存读取约为普通输入价的 0.1 倍；五分钟缓存写入为 1.25 倍，一小时缓存写入为 2 倍。
缓存要求请求前缀从开头连续匹配。请求通常按工具定义、系统提示、对话历史的顺序组装，CLAUDE.md 位于对话前部；越靠前的部分发生变化，后面需要重新 Prefill 的内容越多。正常追加文件或工具结果时，旧前缀仍可能命中 0.1 倍读取；中途更换模型、Effort、打开 Fast Mode、运行 /compact，或者等到缓存过期后再回来，都可能让相关历史重新 Prefill。opusplan 进入和退出 Plan Mode 时会切换模型，也属于这种情况。原文特别说明，关闭 Fast Mode 回到原状态，在缓存层面没有同样的重算代价。
订阅会话与 API 默认 TTL 也不同。主材料给出的当前边界是订阅场景一小时、API Key 默认五分钟；API 可以选择一小时缓存。每次继续对话都会重新开始 TTL 计时；很久以后恢复旧会话时，缓存通常已经过期，启动时系统提示也会重建。具体实现和价格要以使用时的产品说明为准。
/model 和 /effort 还会记住上一次选择，新会话不一定回到默认值。因此开局先确认真实配置；需要切换时，优先放在新会话开头或刚执行完 /clear 之后，别等长历史形成后再换。
选择一种操作，查看下一轮从哪里开始重新计算
发生了什么： 工具结果加在末尾，旧历史继续命中缓存，只有新尾部按完整输入价处理。
缓存省下的是重复计算价格，不会让旧文件和日志退出上下文，也不会阻止它们影响模型判断。因此，清理无关历史通常比反复追求缓存技巧更重要。
/compact 和 /rewind 也有不同用途。同一任务进入新阶段、旧细节已经失去价值时，可以用 /compact 把历史重写成摘要；如果只是末尾几轮走错，优先 /rewind，因为它只裁掉错误分支，前面的缓存前缀仍可能保留。
准备离开较长时间，回来仍要继续同一任务时，可以在缓存有效期内先 /compact。生成摘要还能利用当前缓存，通常比缓存过期后先完整重读旧会话再压缩更合算。
Subagent 适合隔离噪声，不适合所有复杂任务
Subagent 使用独立上下文。它有自己的系统提示、工具和 CLAUDE.md，不会继承主会话的全部历史；任务结束后，通常只有答案或摘要回到主会话，中间读过的日志和尝试不会继续跟随主任务。主会话也只会得到 Subagent 主动写进报告的内容，遗漏的细节不会自动返回。
扫描长构建日志、运行输出巨大的完整测试、搜索大量 Git 历史，通常适合这种隔离。主会话需要结论，不需要把全部过程材料背到任务结束。
代价也很明确：Subagent 要重新加载自己的启动上下文，可能重读主会话已经看过的文件，还会产生独立的多轮请求。一个只需读几十行代码的问题，交出去往往只会增加开销。
如果某类高噪声任务会反复出现，可以为它建立专用 Subagent，并明确指定较小、较便宜的模型；原文举的是 Haiku 或 Sonnet。没有单独指定时，它会使用主会话当前的模型。这样能控制重复脏活的单次成本，前提仍是主会话只需要最终报告。
判断时问一句就够：这项工作的中间过程，主会话之后还需要吗？如果只需要结论，而且过程很吵，隔离有价值；如果过程本身会成为后续决策依据，就留在主会话。
使用这份指南时，记住四个边界
第一，这是一篇 Anthropic 面向 Claude Code 用户发布的官方实践指南。它能说明产品当前的机制和建议，不能证明 Claude Code 比其他 Agent 工具更省钱或更高效。
第二，订阅额度和 API 账单是两种成本表面。订阅用户未必看到逐 Token 金额，但同样的上下文仍会消耗使用额度；API 用户直接面对输入、输出和缓存倍率。
第三，模型、定价、缓存 TTL、界面能力、命令和环境变量都会变化。本文的倍率和操作边界依据 Anthropic 2026 年 8 月发布的文章及当期官方文档。
第四，5 对 18 次请求、6/1/0 次工具调用和 1.9 倍 Token 都是解释性场景，只适用于各自图中的条件。
真正有用的目标，是把 Token 留给任务需要的代码、推理和验证。开局定好模型与 Effort，给出已知范围，收短日志；末尾走偏用 /rewind，换任务用 /clear，高噪声过程才交给 Subagent。这样做不会保证每个任务都更便宜，却能减少会话里最常见的无效负担。