编者按:很多人使用 Claude Code 时,最直观的感受是 Token 消耗太快、长会话很容易吃额度。但从 Anthropic 工程师的视角看,真正影响成本的,往往不是你写了多少代码,而是系统有没有持续复用已经处理过的上下文。

本文分享的核心,就是如何通过缓存机制节省 Token。作者一周内通过缓存复用了超过 3 亿 Token,单日缓存量达到 9100 万。由于缓存 Token 的成本只有普通输入 Token 的 10%,这意味着 9100 万缓存 Token 实际计费约等于 900 万普通 Token。Claude Code 长会话之所以显得更「耐用」,不是因为模型免费工作,而是大量重复上下文被成功复用了。

Prompt caching 的关键在于「不要打断缓存」。Claude Code 会把系统提示、工具定义、CLAUDE.md、项目规则和历史对话分层缓存;只要后续请求的前缀保持一致,Claude 就可以直接读取缓存,而不是重新处理整段上下文。Anthropic 内部也会监控 prompt cache 的复用率,因为它不仅影响用户额度,也直接关系到模型服务成本和运行效率。

对普通用户来说,不必理解所有底层细节,只需要掌握几个关键习惯:不要让会话空置超过 1 小时;切换任务时做好 session handoff;避免频繁切换模型;大文档尽量放进 Projects,而不是反复粘贴进对话。

这篇文章与其说是在讲一个省 Token 技巧,不如说是在提供一套更接近工程师思维的 Claude Code 使用方法:把上下文当作资产管理,让缓存持续复用,让长会话少做重复计算。

以下为原文:

我这周省下了 3 亿 Token,单日 9100 万,一周超过 3 亿。

我没有改动任何设置。这只是 prompt caching 在后台正常发挥作用。

但当我真正理解了缓存是什么,以及怎样避免把缓存「打断」之后,在同样的使用额度下,我的会话可以持续更久。所以,这里整理一份 Claude Code prompt caching 的 80/20 入门指南,不涉及 API 层面的深度细节。

TL;DR

缓存 Token 的成本只有普通输入 Token 的 10%。9100 万缓存 Token,实际计费大约相当于 900 万 Token。

Claude Code 订阅版的缓存 TTL 是 1 小时;API 默认是 5 分钟;Sub-agent 永远是 5 分钟。

缓存分为三层:系统层、项目层、对话层。

会话中途切换模型会破坏缓存,包括开启「opus plan」模式。

缓存到底怎么算钱?

每一个被缓存的 Token,成本都是普通输入 Token 的 10%。

所以,当我的仪表盘显示某一天有 9100 万 Token 命中了缓存时,实际计费大概只相当于处理了 900 万 Token。这也是为什么和没有缓存相比,长时间使用 Claude Code 时,会让人感觉会话几乎是「免费」延长的。

仪表盘里有两个数字值得重点关注:

Cache create:把内容写入缓存时产生的一次性成本。它会在下一轮对话中开始发挥作用。
Cache read:Claude 从缓存中复用的 Token,比如你的 CLAUDE.md、工具定义、此前的消息等。相比重新作为输入处理,成本便宜 10 倍。

如果你的 Cache read 数字很高,说明你正在有效利用缓存;如果这个数字很低,就意味着你在为同一批上下文反复付费。

Anthropic 的 Thariq 有一句话让我印象很深:「我们实际上会监控 prompt cache 的命中率,一旦命中率过低,就会触发警报,甚至宣布 SEV 级别的事故。」

他还写过一篇很好的 X 文章。当缓存命中率高时,会同时发生四件事:Claude Code 体感更快,Anthropic 的服务成本下降,你的订阅额度显得更耐用,长时间编码会话也变得更现实。

但如果命中率很低,所有人都会吃亏。

所以,双方的激励其实是一致的:Anthropic 希望你的缓存命中率更高,你自己也希望命中率更高。真正会拖后腿的,只是一些看似不起眼、却会悄悄重置缓存的小习惯。

缓存是如何在每一轮对话中增长的?

缓存依赖的是 prefix matching,也就是「前缀匹配」。

不用陷入太深的技术细节,你只需要理解一点:只要某个位置之前的内容和已经缓存的内容完全一致,Claude 就可以复用这部分缓存 Token。

一次全新的会话,大致是这样展开的:

根据 Claude Code 文档,一个全新会话通常是这样运行的:

第一轮对话:还没有任何缓存。系统提示词、你的项目上下文(比如 CLAUDE.md、memory、规则),以及你的第一条消息,都会被重新处理一遍,并写入缓存。

第二轮对话:第一轮中的所有内容现在都已经被缓存。Claude 只需要处理你的新回复和下一条消息。这一轮成本就会低很多。

第三轮对话:逻辑相同。之前的对话仍然保留在缓存里,只有最新的一轮交互需要重新处理。

缓存本身可以分成三层:

来自 Thariq 的 X 文章:

系统层(System layer):包括基础指令、工具定义(read、write、bash、grep、glob)和输出风格。这一层是全局缓存的。

项目层(Project layer):包括 CLAUDE.md、memory、项目规则。这一层按项目缓存。

对话层(Conversation):包括回复和消息,会随着每一轮对话不断增长。

如果在会话中途,系统层或项目层的任何内容发生变化,所有内容都必须从头重新缓存一遍。这就是最「贵」的操作。可以想象一下:你已经聊到第 16 条消息,这时突然改了系统提示词,或者中途停了一个小时,那么从第 1 条消息开始的所有 Token 都要被重新处理一遍。

1 小时和 5 分钟的混淆

这是最容易让人误解的地方。

Claude Code 订阅版:默认 TTL 是 1 小时。

Claude API:默认 TTL 是 5 分钟。你可以付出更高成本,把它提升到 1 小时。
任何计划下的 Sub-agent:永远是 5 分钟。

Claude.ai 网页聊天:官方没有明确记录。可能和订阅版一样,但我还没有确认。

几个月前,很多人抱怨 Claude 订阅额度消耗得太快。当时有人以为 Anthropic 悄悄把 TTL 从 1 小时降到了 5 分钟,而且没有通知用户。但事实并不是这样,Claude Code 的 TTL 仍然是 1 小时。

问题在于,Claude Code 和 API 的文档是分开放的,而这两者本来就是完全不同的东西,于是造成了不少混淆。

如果你在大量运行 Sub-agent 工作流,或者直接使用 API,那么 5 分钟这个数字很重要。但对于 95% 的 Claude Code 用户来说,真正需要关注的,其实只有那个 1 小时窗口。

覆盖 95% 用户的三个习惯

下面这些,是我觉得日常使用中真正有用的部分。

不要暂停太久

如果你已经空闲超过一个小时,之前的内容基本都已经从缓存里过期了。你的下一条消息会重新构建缓存。这种情况下,与其继续恢复一个已经「变凉」的旧会话,不如做一次清晰的交接,然后开启一个新会话,成本通常更低。

切换任务时,直接重新开始

/compact 或 /clear 本来就会破坏缓存,所以不如趁这个节点真正重置一次。

我自己做了一个 session handoff skill,用来替代 /compact。它会总结我们已经完成了什么、还有哪些待定决策、哪些文件最重要,以及接下来应该从哪里继续。然后我执行 /clear,把这份总结贴进去,就可以像什么都没中断一样继续推进。

compact 命令有时候运行得也很慢。而这个 handoff skill 通常不到一分钟就能完成。

在 Claude 聊天里,大文档尽量放进 Projects

Claude.ai 上的缓存机制没有非常详细的官方说明,但 Projects 显然和普通对话线程采用了不同的优化方式。所以,如果你要粘贴很大的文档,最好把它们放进 Project,而不是直接塞进对话里。

哪些操作会悄悄破坏缓存?

有几件事会在没有明显提醒的情况下,把缓存全部重置。

切换模型:因为缓存依赖前缀匹配,而每个模型都有自己的缓存。只要切换模型,下一次请求就会在没有任何缓存命中的情况下,重新读取完整历史。

「Opus plan」模式:这个设置会在规划阶段使用 Opus,在执行阶段使用 Sonnet。我之前在一些 token 优化视频里推荐过它,是有原因的。但需要理解的是,每一次切换 plan,本质上都是一次模型切换,也就意味着要重新建立缓存。从长期看,它仍然有助于延长会话额度,但你需要知道底层到底发生了什么。

会话中途编辑 CLAUDE.md 是可以的:这个修改不会立刻生效,要等下一次重启才会应用。因此,当前正在运行的缓存不会受到影响。

我的免费 Token 仪表盘

我前面展示的截图,来自一个 token dashboard。

这是一个很简单的 GitHub 仓库。你把链接交给 Claude Code,让它在本地 localhost 上完成部署,它就会读取你过去所有的会话记录,而不是从空白状态开始统计。你一上来就能看到每天的 input、output、cache create 和 cache read 数据。

不过有一点需要注意:这个仪表盘统计的是本地设备上的 Token 数据。如果你从台式机切换到笔记本,数字就不会完全一致。每台设备都有自己的一套统计视图。

总结

Prompt caching 是一个可以研究得很深的东西。Thariq 那篇文章讲得比这里更完整,如果你想看全貌,值得去读。

但你不需要完全理解所有细节,才能从中受益。你只需要掌握最关键的 80/20:缓存 Token 比普通 Token 便宜 10 倍;Claude Code 的 TTL 是 1 小时;切换模型会破坏缓存;在任务之间做好清晰交接,通常比让一个旧会话放到「过期」后再硬接着用更划算。