很多开发者用Claude Code写代码时，最头疼的是Token用量配额像流水一样快速见底，长对话几乎成了奢侈品。但常在社群分享AI使用技巧的网红Nate Herk在一条X推文中揭露，真正的成本杀手其实不是代码量，而是系统有没有善用prompt caching机制。他本人一周内就靠缓存节省了超过3亿Token，单日缓存量高达9100万：由于缓存Token的成本仅为普通输入Token的10%，这笔账算下来，等于一天只花了900万Token的费用，几乎是“免费”延长了整个编程对话回合的寿命。
缓存成本仅10%：9100万Token实际只付900万
每一个被缓存的Token，成本都是普通输入Token的10%。当仪表盘显示某一天有9100万Token命中了缓存时，实际计费大概只相当于处理了900万Token。这也是为什么和没有缓存相比，长时间使用Claude Code时，会让人感觉会话几乎是“免费”延长的。仪表盘里有两个数字值得重点关注：Cache create（把内容写入缓存时产生的一次性成本）和Cache read（Claude从缓存中复用的Token，比如你的CLAUDE.md、工具定义、此前的消息等）。如果Cache read数字很高，说明你正在有效利用缓存；如果数字很低，意味着你在为同一批上下文反复付费。Anthropic的Thariq有一句话让人印象很深：“我们实际上会监控prompt cache的命中率，一旦命中率过低，就会触发警报，甚至宣布SEV级别的事故。”
三层缓存架构：系统、项目、对话
缓存依赖的是前缀匹配。只要某个位置之前的内容和已经缓存的内容完全一致，Claude就可以复用这部分缓存Token。一次全新的会话大致是这样展开的：第一轮对话还没有任何缓存，系统提示词、项目上下文（如CLAUDE.md、memory、规则）以及第一条消息都会被重新处理并写入缓存；第二轮对话中，第一轮的所有内容都已被缓存，Claude只需处理新的回复和下一条消息，成本低很多；后续每轮逻辑相同。缓存本身分三层：系统层（基础指令、工具定义、输出风格，全局缓存��、项目层（CLAUDE.md、memory、项目规则，按项目缓存）、对话层（回复和消息，随对话增长）。如果在会话中途，系统层或项目层的任何内容发生变化，所有内容都必须从头重新缓存——这是最“贵”的操作。
最易忽视的“断缓”陷阱：模型切换与空窗1小时
Claude Code订阅版默认TTL是1小时；API默认5分钟；Sub-agent永远是5分钟。如果你已经空闲超过一小时，之前的缓存基本都已过期，下一条消息会重新构建缓存。这种情况下，与其继续恢复一个已经“变凉”的旧会话，不如做一次清晰的交接后开启一个新会话，成本通常更低。切换模型会破坏缓存：因为缓存依赖前缀匹配，每个模型都有自己的缓存，一旦切换模型，下一次请求就会在没有任何缓存命中的情况下重新读取完整历史。“Opus plan”模式本质也是模型切换，虽然有助于长期延长会话额度，但底层确实会重建缓存。另外，/compact或/clear命令也会破坏缓存。
实战心法：Session Handoff比/compact更省钱
Nate Herk自己做了一个session handoff skill，用来替代/compact。它会总结已经完成了什么、还有哪些待定决策、哪��文件最重要，以及接下来应该从哪里继续。然后执行/clear，把这份总结贴进去，就可以像什么都没中断一样继续推进。compact命令有时候执行得很慢，而handoff skill通常不到一分钟就能完成。此外，如果要在Claude.ai上贴很大的文件，最好把它们放进Project，而不是直接塞进对话里。会话中途编辑CLAUDE.md不会立即生效，要等下次重启才应用，因此当前正在运行的缓存不会受影响。
Nate还分享了自制的token dashboard（GitHub仓库：nateherkai/token-dashboard），部署到本地localhost后，它会读取所有会话记录，展示每天的input、output、cache create和cache read数据。需要留意：仪表盘统计的是本地设备的Token数据，从台式机切换到笔记本时数字不会完全一致。Prompt caching可以研究得很深，但开发者只需要掌握最关键80/20：缓存Token比普通Token便宜10倍；Claude Code的TTL是1小时；切换模型会破坏缓存；在任务之间做好清晰交接，通常比让一个旧会话放到过期后再硬接着用更划算。