如何削减Claude Code令牌成本:Anthropic高效会话实用指南

Anthropic发布了一份实用指南,面向希望从每次Claude Code会话中获取更多价值的开发者。核心信息很简单:同样的编码任务,其成本可能因会话管理方式不同而存在显著差异。

发布于 2026年8月17日generalGEO 评分: 09 次阅读
如何削减Claude Code令牌成本:Anthropic高效会话实用指南

如何削减 Claude Code 的 Token 成本:Anthropic 高效会话实用指南

引言

Anthropic 发布了一份实用指南,帮助开发者从每一次 Claude Code 会话中获得更大价值。

核心信息很简单:同样的编程任务,根据你管理会话的方式不同,成本可能会有很大差异

Claude Code 不像传统编辑器那样每个任务费用固定。每个模型请求都有推理成本,而长对话会反复携带文件、工具结果、命令输出、系统指令和早期消息。如果这些上下文管理不当,一个简单的 bug 修复最终可能消耗远超必要的 Token。

图片展示了 Anthropic 关于最大化 Claude Code 会话价值的指南封面。背景为黑色,左侧有一个浅绿色图标,内含类似代码仓库的图案。右侧文字写着“最大化 Claude Code 会话价值”,下方副标题写着“如何运行高效会话并从每个 Token 中获取最大价值”。该图片位于文档引言部分,与上下文紧密相关,直观呈现了文档引导开发者通过高效管理 Claude Code 会话从每个 Token 中获取最大价值的主题。

源文章将建议提炼为六个实用习惯:

  1. 当一个任务完成、准备转向另一个任务时,运行 /clear
  2. 在会话开始时选择模型和推理力度,而不是在过程中反复切换。
  3. 使用 @ 直接引用文件,而不是让 Claude 自行搜索。
  4. 为那些否则会产生大量输出的命令添加静默标志。
  5. 在长时间休息前运行 /compact,趁现有提示缓存仍然有效时进行压缩。
  6. 将大量繁琐的调查工作交给子代理,使其中间上下文不会在主对话中累积。

Anthropic 自己的 TL;DR 还建议在新会话中运行 /context 查看已加载的内容,包括 CLAUDE.md 和 MCP 工具定义。

一旦你理解了 Token 在 Claude Code 会话中的流转过程,这些建议就更有意义了。

Token 的生命周期

Claude Code 可以通过付费 Claude 套餐或按量计费的 API 使用。对于个人用户,Claude Pro 目前按月付费为每月 20 美元,而 Claude Max 起价为每月 100 美元,还提供更高使用量档位。API 使用量则根据模型和 Token 数量单独计费。

Anthropic 的 Claude Code 成本文档指出,在企业部署中,平均使用量约为每个开发者每个活跃日 13 美元,大约为每个开发者每月 150-250 美元,不过实际成本会因模型、代码库、工作流程和自动化程度而有很大差异。

如果 Claude 必须搜索不必要的文件、运行冗长的命令,或反复携带无关的上下文,同样的任务成本可能会高出数倍。

图片展示 会话A和会话B的请求。会话A读取了两个文件,总共5个请求;会话B先执行搜索,总共18个请求。不同颜色的色块代表不同的组件:紫色表示工具定义、系统提示词和CLAUDE.md;绿色表示grep搜索结果;蓝色表示读取的文件;橙色表示命令输出。该图对应了前文提到的观点,即理解Claude Code的成本需要将每个请求拆分为两个阶段——读取输入和生成输出——并直观地展示了会话A和会话B在不同阶段的请求构成,帮助读者理解成本差异。

要理解原因,可以将

每个请求拆分为两个阶段。

预填充:读取输入

预填充阶段,模型一次性读取请求及其上下文。

该输入可以包括:

  • 工具定义
  • 系统提示词
  • CLAUDE.md
  • 你当前的消息
  • 之前的对话历史
  • Claude已读取的文件
  • 已添加到会话中的命令和工具输出

所有这些都计入输入令牌。

解码:生成输出

解码阶段,模型逐个令牌地生成其响应。

这包括推理令牌、工具调用以及你最终看到的文本。与预填充不同,解码是串行的:一个200令牌的响应需要模型一个接一个地生成200个令牌。

这就是为什么输出令牌通常比输入令牌贵得多。对于本文讨论的当前Claude模型,输出定价是基础输入价格的五倍。

当前标准API价格如下:

模型 输入 输出
Claude Opus 5 $5 / MTok $25 / MTok
Claude Sonnet 5 $2 / MTok $10 / MTok
Claude Haiku 4.5 $1 / MTok $5 / MTok

MTok表示一百万令牌。

另一个主要变量是努力级别。在代理式编码会话中生成的大部分输出可能是推理。更高的努力级别允许模型花费更多令牌来思考难题,而较低的努力级别可能更适合常规工作。

该图展示了简单任务和困难任务下模型质量与任务成本之间的关系。左侧图表显示,在简单任务上,不同规格模型的曲线趋于收敛,意味着在花费相同任务数的情况下,质量相似;右侧图表显示,在困难任务上,不同规格模型的曲线不收敛,在花费相同任务数的情况下,更大的模型提供更高的质量。该图与上下文紧密相关,直观地说明了文本中关于模型规模和任务难度对输出质量影响的讨论。

实用规则很简单:使用更强的模型和更高的

当问题真正困难或模糊时付出努力,而不是对每个小任务自动这样做。

提示缓存是最大的成本杠杆

提示缓存是Claude Code成本模型中最关键的部分之一。

每个Claude Code请求都以大量重复内容开始:工具定义、系统提示、CLAUDE.md以及迄今为止积累的对话历史。

如果新请求的开头与最近的请求完全匹配,服务器可以重用先前计算的状态,而无需再次处理整个共享前缀。

读取缓存仅需正常输入令牌价格的0.1倍

写入缓存比正常输入更昂贵,因为服务器必须存储计算后的状态。标准的五分钟缓存写入成本为基础输入价格的1.25倍,而一小时缓存写入成本为2倍。关键点在于写入只发生一次,而后续的缓存命中可以反复以正常输入成本的十分之一重用前缀。

假设一个对话已经包含50,000个令牌的历史。如果没有缓存命中,模型在下一个请求时必须按正常输入速率预填充整个历史。如果缓存有效,共享前缀会以基础速率的0.1倍读取,只有新追加的内容需要按全价输入价格处理。

在长时间运行的代理循环中,这种差异可能变得相当可观。

什么会破坏缓存?

缓存必须从请求的开始处连续匹配。如果前缀前部附近的某些内容发生变化——或改变了部分缓存键——剩余的历史就无法再以同样的方式重用。

源文章强调了六种常见情况。

  1. 使用/model切换模型
  2. 每个模型都有独立的缓存。从一个模型切换到另一个模型意味着下一轮必须为新模型重新预填充现有对话。
  3. 使用/effort更改推理努力程度
  4. 努力程度是缓存键的一部分。在会话中途更改它可能会强制重新处理对话。
  5. 开启快速模式
  6. 快速模式也会改变缓存键。Anthropic建议如果你打算使用它,就在开始时启用。关闭快速模式不会产生同样的缓存惩罚。
  7. 运行/compact
  8. 压缩将对话重写为更简短的摘要。旧对话不再匹配,因此之前的对话缓存无法简单地继续使用。
  9. 让缓存过期
  10. 在Claude Code订阅中,Anthropic表示提示缓存在不活动一小时后过期。使用API密钥时,默认TTL为五分钟,除非明确启用了一小时缓存。
  11. 恢复旧会话
  12. 旧会话通常不再有活动缓存,而且Claude Code启动时会重新构建系统提示。因此,下一个请求通常需要全新预填充。

这并不意味着你永远不应更改模型、努力程度或压缩对话。这意味着存在更便宜的时机:在会话开始时或刚执行/clear之后,而非在长时间、昂贵的上下文进行到一半时。

还有一个不太明显的情况在

opusplan 模式。Anthropic 指出,进入或退出计划模式可能会切换模型,因此每次切换都可能使相关模型的缓存失效。

为什么休息前执行 /compact 更划算

/compact 会将当前对话压缩为更简短的版本。

由于生成摘要需要读取现有上下文,因此在对话仍可通过提示缓存获取时执行压缩会更便宜。如果你等到长时间休息后缓存已过期,Claude 可能需要在总结之前以正常的输入成本读取完整对话。

这就是为什么 Anthropic 建议在离开键盘较长时间之前先执行压缩。

你的会话正在悄悄变得庞大

提示缓存使重复上下文更便宜,但它并不能阻止上下文本身不断增长。

每次 Claude 读取文件,文件内容都会添加到对话中。每次它运行命令,输出也可能被添加进来。从那时起,后续轮次会持续携带这些内容。

第 40 轮不仅仅是最新的请求,它同时携带了第 1 到第 39 轮中发生的大部分内容。

这就是为什么长时间会话累积的成本可能远超开发者的预期。即使旧历史被缓存,反复携带不相关的上下文也并非免费,而且还会消耗上下文窗口中的空间。

Claude Code 确实对超大 Bash 输出设有防护机制。Anthropic 当前的文档指出,当命令输出超过 30,000 个字符时,Claude Code 会将输出写入文件,只在对话中保留简短预览和路径。

棘手的情况是输出杂乱但仍低于该阈值的场景。

一个打印数百行成功测试行的测试套件可能仍低于 30,000 个字符。如果是这样,这些内容会留在对话中,并在后续轮次中继续被发送。

因此,Anthropic 建议主动保持工作上下文的精简。

1. 使用 @ 引用文件

如果你知道 Claude 需要哪个文件,直接引用它。

不要让 Claude 按名称查找文件,而是使用 @ 提及,使文件从一开始就附加到消息中。

一张图,展示三种不同提示对 Claude 工具结果的影响。当你输入“测试失败了”时,需要 6 轮对话,从 grep 结果开始,然后打开文件,最后读取 utils.test.ts。当你输入“修复 utils.test.ts”时,需要 1 轮对话,从 grep 结果开始,然后读取 utils.test.ts。当你输入“修复 @utils.test.ts”时,直接读取 utils.test.ts,无需其他操作。这张图呼应了前面关于避免不必要搜索和读取操作的观点,并直观展示了使用 @ 引用文件可以减少对话轮次并避免额外操作。

从概念上比较这些提示:

测试失败了。

Claude 可能需要在仓库中搜索、检查多个文件,并收集多个工具结果才能

触及了实际问题。

更具体的请求可以减少部分探索:

修复 utils.test.ts 中失败的测试。

而一个 @ 引用可以避免单独的 Read 调用:

修复 @utils.test.ts 中失败的测试。

无论哪种方式,文件仍会占用上下文。节省来自避免不必要的搜索和 Read 轮次。

另外,避免在同一对话中重复附加同一文件。一旦文件进入上下文,再次提及可能会添加另一份副本。

2. 为高噪音命令添加静默标志

重复的命令输出可能会悄悄主导整个会话。

对于你经常运行的命令,在 CLAUDE.md 中放入一个简洁版本,让 Claude 从一开始就知道低噪音的调用方式。

例如:

使用 npx vitest run <file> --reporter=dot 运行单个测试文件

点状报告器可能只返回一个紧凑的结果,而不是数百行的详细输出。

这是一个小的配置更改,但在多次轮次中,它可以节省大量重复上下文。

3. 将高输出工作隔离到子代理中

子代理拥有自己的上下文窗口。

它有自己的系统提示、工具和 CLAUDE.md,但它不会继承整个主对话。它可以检查日志、运行命令、搜索历史或读取大文件,然后只将答案返回给父会话。

这对于以下任务非常有用:

  • “浏览这个构建日志,告诉我哪里出了问题。”
  • “搜索这个大文件并报告相关部分。”
  • “运行完整的测试套件并返回重要的失败项。”
  • “检查 Git 历史并总结引入此行为的更改。”

当子代理完成时,中间的文件读取和命令输出会消失。只有它返回的答案进入主会话。

这里有一个权衡:因为子代理不会继承父对话,它可能需要重新阅读主会话已知的材料。对于小型任务,这种开销可能使子代理效率较低。当隔离的任务噪音足够大,你不想让它的过程保留在主上下文中时,它就值得了。

4. 任务变更时使用 /clear

这是最简单也最有价值的习惯之一。

一旦你完成了一个错误修复并开始不同的任务,运行:

/clear

先前任务的文件读取、命令输出、失败的方法和临时上下文不再需要跟随后续的每一轮。

Anthropic 自己的对比显示,在一个连续会话中保留三个独立任务,比在任务之间清除发送更多的 token。

如果你需要保留旧会话以备后用,Anthropic 建议在 /clear 之前使用 /rename

如果你仍在处理同一任务,只需要压缩对话中较旧的部分,/compact 是更好的工具。

仅在需要时使用 /rewind

最后几轮对话出了问题

还有一个很容易被忽略的有用选项:

/rewind

如果会话只是在最后几轮偏离了方向,倒回可以移除这些轮次,而无需重写之前更早的对话。

这对缓存很重要。Anthropic 表示,倒回点之前的部分可以保持缓存状态,而 /compact 会重写对话,因此会产生自己的成本。

所以这三个命令用途不同:

命令 最佳用途
/clear 你要开始一个全新的任务
/compact 你在继续同一个任务,但需要更短的上下文
/rewind 只有最近的几轮是错误的或不再有用

管理 Token 正在成为一项开发者技能

一旦这些机制清晰了,一个更大的模式就浮现出来。

高效的 AI 辅助编程现在需要一种新的操作判断力。开发者不仅需要知道如何编写和调试代码,还需要知道:

  • 哪个模型适合该任务
  • 多少推理投入是合理的
  • 什么应该放入活动上下文
  • 什么时候应该清空或压缩会话
  • 哪些工作应该移交给子代理
  • 哪些命令会产生不必要的输出
  • 哪些更改会使提示缓存失效

一年前,这些决策在日常软件开发中几乎不存在。现在它们可以决定两位开发者完成基本相同的工作是否要支付截然不同的费用。

Anthropic 自己就说明了这在规模化时有多重要。

该公司在 2026 年报告称,合并到 Anthropic 代码库中的代码有 80% 以上是由 Claude 编写的,而且普通工程师

每天合并的代码量约为 2024 年的 8 倍。在另一个内部优化基准测试中,一个基于 Claude 的系统从 2025 年约 3 倍的加速提升到 2026 年 4 月约 52 倍

在如此级别的 AI 使用下,推理效率不是一个小账目细节。

因此,Anthropic 指南中更深刻的教训不仅仅是“少花 token”。而是要理解 token 都花在了哪里,并确保它们被花在有用的推理、代码更改和工具工作上,而不是过时的历史和可避免的输出上。

常见问题

为什么 Claude Code 在长时间会话中会变得更贵?

每一轮新对话都会携带相关的对话历史,包括消息、文件、工具调用和命令输出。提示缓存使重复的前缀便宜得多,但不断增长的上下文仍然会消耗 token 和上下文窗口容量。

Claude 提示缓存能节省多少?

提示缓存命中按正常基础输入 token 价格的 0.1 倍计费,这意味着缓存输入部分降低了 90%。缓存写入比正常输入更贵,但重复的缓存读取可以很快抵消初始写入成本。

在 Claude Code 中我应该使用 /clear 还是 /compact

当你切换到不同任务且不再需要当前上下文时,使用 /clear。当你仍在同一个任务上但希望 Claude 将较早的对话历史总结为更小的工作上下文时,使用 /compact

Claude Code 中的 /rewind 有什么作用?

/rewind 可以让你跳回

返回到之前的一条消息,并从活动上下文中删除其后的对话轮次。当只有对话的最新部分走错了方向,且你不需要压缩或清除整个会话时,这非常有用。

更换 Claude 模型会增加 Token 成本吗?

可能会。每个模型使用独立的提示缓存,因此在长对话中途切换模型可能会迫使现有历史记录以新模型的完整输入价格重新处理。

为什么在引用文件时应该使用 @

@ 文件引用会将文件直接附加到消息中,这可以避免 Claude 搜索文件或额外发起一次 Read 调用。文件内容仍然会消耗上下文,因此好处是避免不必要的查找步骤,而不是让文件本身免费。

我什么时候应该使用 Claude Code 子代理?

对于会产生大量你不需要在主对话中看到的中间输出的工作(例如检查日志或执行广泛搜索),请使用子代理。子代理在独立的上下文中工作,只将最终答案发送回主会话。

如何查看当前哪些内容正在占用上下文?

在新的 Claude Code 会话中运行 /context。Anthropic 建议使用它来检查启动上下文,如 CLAUDE.md 和 MCP 工具定义,以便删除你不需要的指令或集成。

相关工具

  • Claude Code:Anthropic 的代理式编码工具,可在终端、IDE、Web 和其他受支持环境中处理代码库。
  • Claude:Anthropic 的主要助手界面和账户入口,也是包含 Claude Code 的 Claude 套餐的起点。
  • Claude Agent SDK:该 SDK 公开了与 Claude Code 相同的代理循环、工具和上下文管理基础。
  • Vitest:一个 JavaScript 测试框架,用于 Anthropic 示例中通过 --reporter=dot 减少嘈杂的测试输出。

相关链接

难度。

  • 提示缓存至关重要:Anthropic 关于在智能体工作流中保持提示缓存效率的工程经验。
  • 当 AI 构建自身:Anthropic 关于内部 AI 编写代码、工程产出和模型驱动优化实验的报告。

摘要

Claude Code 的成本受多种因素影响,而不仅仅是模型价格。上下文长度、推理强度、命令输出、会话时长、缓存命中率、文件发现和子代理的使用,都会改变一项任务消耗的 token 数量。

最有价值的习惯很简单:任务变化时清除上下文,避免在会话中途进行不必要的模型或推理强度切换,保持嘈杂输出简短,直接引用已知文件,长时间中断前先压缩上下文,以及在更适合使用子代理时隔离高输出量工作。

这些做法并非不惜一切代价追求 token 使用量最小化,而是为了确保你所支付的 token 都在为任务做出贡献,而不是反复承载无关的历史信息。

高效使用 Claude Code 越来越成为一种上下文工程:保持上下文相关,在有益时保留缓存,并将推理用在真正能改善结果的地方。