📢 Gate 广场 TradFi 交易分享挑战上线！
晒单瓜分 $30,000 奖池，新人首帖 100% 中奖！
📌 参与方式：
带 #TradFi交易分享挑战 发帖，满足以下任一即可：
🔹 带今日指定 TradFi 币种标签发帖交流。
🔹 完成单笔大于 $10U 的 TradFi CFD 交易并挂载交易卡片。
🏷️ 今日指定标签：USDJPY、AUDUSD、US30、TSLA、JPN225
🎁 宠粉福利：
1️⃣ 卡片分享奖： 抽 50 人，每人送 $100 仓位体验券！
2️⃣ 发帖榜单奖： 冲排行榜，赢 WCTC 限定 T 恤！
3️⃣ 新粉见面礼： 新人首次发帖，100% 领 $10 体验券！
详情：https://www.gate.com/announcements/article/51221
Claude 代码省钱技巧：工程师一周靠缓存节省 3 亿 Token，关键在别打断
Claude 代码长对话吃额度？工程师 Nate Herk 揭露，一周靠缓存机制省下 3 亿 Token，单日最高 9100 万。关键不是写多少程序，而是如何不「打断」缓存，让重复上下文不再浪费成本。
（前情提要：鞭打 Claude code 加速的 badclaude 开源项目，被 Anthropic 寄侵权通知信了）
（背景补充：Claude Code 新增云端定时任务功能！不用开电脑，AI 自动审核 PR、升级）
本文目录
Toggle
很多开发者用 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」模式。
缓存成本只有 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。
》原文链接