Claude Código Dicas para poupar dinheiro: engenheiros economizam 300 milhões de tokens por semana com cache, o segredo está em não interromper

Claude Code 长对话吃额度？工程师 Nate Herk 揭露，一周靠快取机制省下 3 亿 Token，单日最高 9100 万。关键不是写多少程序，而是如何不「打断」快取，让重复上下文不再浪费成本。
（前情提要：鞭打 Claude code 加速的 badclaude 开源专案，被 Anthropic 寄侵权通知信了）
（背景补充：Claude Code 新增云端定时任务功能！不用开电脑，AI 自动审核 PR、升级）

本文目录

切换

• 快取成本只有 10%，9100 万 Token 等于 900 万
• 三层架构：系统、专案、对话，层层叠加
• 最常见的「断缓」陷阱：模型切换与空窗 1 小时
• 工程师自制仪表板：检视 Cache Read 与 Create
• 实战心法：Session Handoff 比 /compact 更省钱

很多开发者用 Claude Code 写程序时，最头痛的往往是 Token 用量配额像流水一样快速见底，长对话几乎成了奢侈品。

但常在社群分享 AI 使用技巧的网红 Nate Herk 在一则 X 推文中揭露，真正的成本杀手其实不是程式码量，而是系统有没有善用 prompt caching 机制。他本人一周内就靠快取节省了超过 3 亿 Token，单日快取量高达 9100 万：由于快取 Token 的成本仅为普通输入 Token 的 10%，这笔账算下来，等于一天只花了 900 万 Token 的费用，几乎是「免费」延长了整个程式设计对话回合的寿命。

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

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

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

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

Claude Code 订阅版的快取 TTL 是 1 小时；API 预设是 5 分钟；Sub-agent 永远是 5 分钟。

快取分为三层：系统层、专案层、对话层。

会话中途切换模型会破坏快取，包括开启「opus plan」模式。

coding agents need glass boxes now

jianshuo/ccglass

111 stars on github
created yesterday
mit + javascript
local proxy + web dashboard for claude code, codex, deepseek-tui, and kimi
shows the full system prompt, tool schemas, message history, token/cache/cost, and… pic.twitter.com/Wot5SFV16N

— Beau Johnson (@BeauJohnson89) 2026年5月24日

快取成本只有 10%，9100 万 Token 等于 900 万

每一个被快取的 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 只需要处理你的新回复和下一条讯息。这一轮成本就会低很多。

第三轮对话：逻辑相同。之前的对话仍然保留在快取里，只有最新的一轮互动需要重新处理。

最常见的「断缓」陷阱：模型切换与空窗 1 小时

快取本身可以分成三层：

来自 Thariq 的 X 文章：

系统层（System layer）：包括基础指令、工具定义（read、write、bash、grep、glob）和输出风格。这一层是全域性快取的。

专案层（Project layer）：包括 CLAUDE.md、memory、专案规则。这一层按专案快取。

对话层（Conversation）：包括回复和讯息，会随着每一轮对话不断增长。

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

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

Claude Code 订阅版：预设 TTL 是 1 小时。

工程师自制仪表板：检视 Cache Read 与 Create

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 小时视窗。

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

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

/compact 或 /clear 本来就会破坏快取，所以不如趁这个节点真正重建一次。

实战心法：Session Handoff 比 /compact 更省钱

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

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

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

有几件事会在没有明显提醒的情况下，把快取全部重建。

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

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

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

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

https://github.com/nateherkai/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 小时；切换模型会破坏快取；在任务之间做好清晰交接，通常比让一箇旧会话放到「过期」后再硬接着用更划算。

》原文链接