💾 Claude Code 缓存机制详解：如何省 80% Token
一、原文概括
这篇长文来自 @MinLiBuilds，通过本地实验（Gemma 4 + Qwen 3.5）和逆向 Claude Code 源码，深入讲解了大模型的 KV 缓存机制，以及 Claude Code 具体是如何实现上下文缓存来节省 token 的。核心结论是：理解缓存机制并保持良好使用习惯，可以让你的 Claude Code 套餐多撑 3-5 倍，省下 80% 的 token。
文章从一个直观现象入手：同一段对话，大模型第一次处理需要 30 秒，后续对话却只需要 0.2 秒——这种百倍加速就是 KV 缓存带来的。作者解释了 Transformer 架构中 KV 缓存的原理：Key 和 Value 是历史 token 计算得到的，一旦计算完成就不再变化，可以缓存起来重复利用，只有新 token 的 Query 需要计算。因此，模型越大，缓存带来的收益越大。
接着作者分析了 Claude Code 的工程实现：它采用前缀匹配缓存，将 prompt 分层（系统提示词 + 工具定义 + CLAUDE.md + 对话历史），只要前缀不变就能复用缓存；提供两档 TTL（默认 5 分钟，Pro/Max 用户延长到 1 小时）；还有缓存断裂检测机制，自动分析缓存失效原因。
最后给出了实用的使用建议：保护缓存就是省钱，不要轻易开新 session、不要修改 CLAUDE.md、不要频繁切换模型、不要频繁加减 MCP 工具，应该在一个 session 里持续对话。进阶技巧还包括利用 TTL 刷新机制给缓存”续命”。
二、数据信息核实
| 声称 | 核实结果 | 来源 |
|---|---|---|
| KV 缓存可以避免重复计算历史 token | ✅已证实 | LMCache 博客、ClaudeCodeCamp 文章、GitHub 开源讨论 |
| Claude Code 使用前缀匹配的上下文缓存 | ✅已证实 | ClaudeCodeCamp 实验验证，reddit 用户讨论 |
| 合理使用缓存可以省下 70-80% token | ✅已证实 | 多个独立来源验证，计算方式吻合 |
| 缓存断裂会导致后续所有 token 重新计费 | ✅已证实 | Claude Code 源码分析，社区实验确认 |
| Pro/Max 用户缓存 TTL 可延长到 1 小时 | ⚠️有争议 | 作者声称来自源码，但公开文档未明确说明，实际使用中因使用模式不同可能有差异 |
三、辩证思考
3.1 独立观点
这篇文章对 KV 缓存的解释非常清楚，尤其是用本地实验展示了缓存带来的百倍加速，非常直观。Claude Code 的缓存机制分析也很到位，很多结论和其他独立实验结果一致，实用性很强。
我同意作者的核心观点：持续对话比频繁开新 session 省钱得多。这一点在实际使用中感受非常明显，很多人抱怨 Claude Code token 用得快，其实就是习惯不好，喜欢不停开新会话。
但也要指出，作者给出的”省 3-5 倍”是理想情况。实际使用中，缓存不可避免会因为 TTL 过期、修改配置等原因断裂，而且很多人确实需要切换模型、调整工具，所以实际收益大概在 2-3 倍，不会达到 5 倍。
3.2 关联分析
KV 缓存不是什么新技术，Transformer 架构出来就有了。但是 Claude Code 把它用到了极致，通过工程化实现变成了实实在在的省钱利器。这背后其实是大模型API 按 token 计费的商业模式催生的优化——用户越省钱，越愿意持续订阅。
关联来看，现在各家大模型 API 都开始支持上下文缓存了，OpenAI、Anthropic、Google 都推出了类似功能。这会带来几个变化：
- 长上下文变得更便宜：之前长对话每轮都要全价付费，现在大部分可以缓存，价格下来了，使用门槛降低
- 对客户端工程能力要求更高：怎么组织 prompt、怎么分层、怎么管理缓存断点，这些都变成了 client-side 的技术活
- 催生了”上下文工程”这个新领域：怎么设计 prompt 结构来最大化缓存命中率，这会变成 AI 开发的一个重要技能
3.3 预判
缓存机制会越来越重要。随着上下文窗口越来越大（现在已经到 1M 了），缓存带来的成本节约会越来越明显。未来可能会出现：
- 更智能的缓存管理：自动识别哪些内容可以长期缓存，哪些容易变，自动调整
- 跨会话缓存：相同的系统提示词、工具定义可以在多个会话间复用，进一步省 token
- 用户可配置缓存策略：重要项目延长 TTL，不重要项目自动清理
但缓存也不是银弹。缓存带来了内存占用的增加，服务端要存储更多用户的 KV 缓存，成本其实转移到了服务商那里。最终价格会不会下降，还是要看规模化效应。
🤔 其他视角/质疑
**缓存续命技巧真的有用吗？**作者提出每 55 分钟发一次请求刷新 TTL 来无限续命。这个在原理上说得通，但实际使用中，Anthropic 可能会对这种行为进行限制，而且长期占用缓存资源对其他用户不公平。不建议大规模使用，偶尔用用问题不大。
**Sub-agent 真的完全不能复用缓存吗？**作者说几乎不能复用，这是对的，因为每个 agent 有独立的上下文和工具集。但是如果能设计成增量式的，主线程的前缀部分其实还是可以复用的，未来 Claude Code 可能会优化这一点。
**/compact 真的一定破坏缓存吗？**根据其他社区实验，/compact 只会压缩对话历史，前缀（系统提示词、工具、CLAUDE.md）还是保留的，所以缓存不会完全断裂。作者说”消息历史变了 = 断裂”有点绝对，实际影响没那么大。当上下文太长时，该用还是得用。
四、总结
一句话结论： 理解 Claude Code 的缓存机制，保持一个会话持续对话，不要随意修改配置切换模型，可以省下 70-80% 的 token，让套餐用量多支撑 2-3 倍。
使用建议/关注点：
- ✅ 绿灯行为：一个 session 持续干活、工作开始前配好所有工具、定期整理 CLAUDE.md 但不要工作中途改、利用 btw 共享缓存
- ❌ 红灯行为：频繁开新 session、工作中修改 CLAUDE.md、随意加减 MCP 工具、频繁切换模型、没事就 /compact
- ⚠️ 注意事项：超过 TTL 缓存会过期，长时间离开后回来可能要重新付费；缓存断裂是连锁反应，断在前面，后面全废，所以前缀要尽量稳定