夜雨聆风一顿午饭的时间，足以让你的AI编程助手从"经济舱"跳价到"头等舱"，而你写的代码，一行都没变。
原因藏在缓存机制深处
创业者Xiaoyin Qu翻遍了自己一个月的Claude Code真实账单，从110个会话、46,580轮对话中提炼出一个惊人发现：你离开工位的时间长度，直接决定了你下一条消息的价格。
▲ Xiaoyin Qu原帖的双面板对比图：左侧按闲置时长分桶，右侧对比"新会话+摘要"与"硬续旧会话"的成本差异
具体来说，
去倒杯咖啡，回来发一条消息，成本大约是正常工作时的1.3倍，几乎无感。
开完一个半小时的会回来，1.6倍，还能接受。
但如果你吃了顿午饭，悠哉悠哉晃回来，点击"继续"，
13倍
同一条消息，同一个模型，同一个项目
你什么都没改，只是去吃了顿饭
你的对话记录，每一轮都在"重新发送"
要理解这件事，得先拆开AI编程Agent的引擎盖。
和很多人的直觉相反，大语言模型其实是"失忆"的。
它不像微信聊天那样天然记住上一轮内容，每一次你发送新消息，Claude Code都要把从头到尾的全部对话历史重新打包发送一遍。
系统提示、项目说明、工具定义、此前的用户消息、模型回复、文件读取结果……全部塞进去，新内容接在最后面。
你跟AI聊到第50轮的时候，那一次API调用携带的信息量，可能已经是几十万个token。
如果每次都从头"重新算"一遍，账单会像坐火箭一样往上窜。
所以Anthropic做了一个关键优化：Prompt Caching（提示缓存）。
原理不复杂：既然前后两轮对话的"前缀"几乎一模一样（只有末尾多了一轮新内容），那服务器就把上一次算好的中间结果存起来。
下一轮请求进来，发现前缀没变？
直接读缓存，省掉大量重复计算
关键数字来了
根据Anthropic官方定价：
- 缓存命中（读取）
：只需基础输入价的 0.1倍，一折 - 缓存未命中（重新写入）
：要付基础输入价的 1.25倍（5分钟档）或 2倍（1小时档）
▲ Anthropic文档中的缓存定价结构：读取0.1×，写入最高2×基础价
换句话说，缓存热的时候，重读历史便宜得像白送；
缓存冷掉以后，你要为整本聊天记录付一笔"重建费"，而且这笔费用比正常输入还贵。
60分钟：那道看不见的"悬崖"
缓存会过期
它有一个TTL（Time To Live，存活时间）。
对Claude Code的订阅用户来说，主对话默认使用1小时TTL。
也就是说，你最后一次发消息之后，服务器会帮你保留缓存大约60分钟。
在这个窗口内，每一次命中都会刷新计时器，所以只要你持续写代码，几分钟发一轮，缓存可以永远保持"热"的状态。
但一旦你离开超过60分钟，
缓存蒸发
下一条消息进来，服务器发现：前缀是对的，但缓存已经不在了。
于是它必须把你那几十万token的对话历史，从头到尾重新处理一遍，写入一份全新的缓存。
这就是"午饭税"的全部秘密：整本聊天记录从廉价的"缓存读取"模式，一脚踏空掉进了昂贵的"缓存重建"深渊。
用官方定价做个粗算：缓存重建（2×）与缓存读取（0.1×）之间的有效单价之比，理论上可以达到20倍。
Xiaoyin Qu实测到的中位数13倍，考虑到还有输出token、未缓存尾部等混合因素，完全在合理区间内。
▲ Claude Code文档明确写明：订阅自动请求1小时TTL，超限降级时可能缩短至5分钟
新开会话贴摘要，比"硬续"便宜三分之二
Xiaoyin Qu给出的解法朴素得令人意外：
离开前，让Agent执行一句 "summarize where we are."，把进度摘要存下来。
回来后不要点"继续"，而是新开一个会话，把摘要贴进去。
她的数据显示，这样做的成本大约是4.5倍，依然比活跃状态贵，但比硬续冷会话的13倍低了将近三分之二。
道理也简单：旧会话硬续，等于对一本厚厚的长历史做全量cache write。
新会话只带一段短摘要和当前任务说明，前缀短得多，重建成本自然低得多。
▲ Josh Herzberg建议：把对话细节持续落到.md文件，新会话随时可接
这个思路也得到了社区的广泛呼应
Josh Herzberg建议把项目状态持续写入一个.md文件，让Agent自己维护进度档案，这样"永远不怕丢信息"。
Routekit Shell则更进一步，认为巨型单体聊天本身就是反模式，应该把嘈杂的执行工作交给sub-agent，让主编排器的上下文保持精简，"这样即使cache miss，也只是零头"。
6000美元的通宵噩梦：当缓存陷阱遇上无人值守
如果说"午饭税"还只是日常小痛，那接下来这个故事足以让人冷汗直流。
开发者Om Patel分享了一起真实事故：有人用Claude Code的 /loop 功能，设置每30分钟自动检查一次开放的PR，无人值守跑了大约26小时、46次循环。
醒来一看，
账单：约6000美元
▲ Om Patel详述/loop事故：30分钟间隔远超5分钟TTL，每次触发都是冷缓存重建
机制一拆就明白：loop间隔30分钟，远超5分钟的缓存TTL（API场景下的默认档）。
每一次触发，都是一次完整的冷缓存重建。
对话历史还会持续增长，到后期，一轮请求携带的上下文可以膨胀到约80万token。
每次冷启动都在为这本越来越厚的"历史书"付全价，"查PR"的输出费用反倒只占很小一部分。
任何间隔大于TTL的定时Agent任务，都会把冷启动cache write变成周期税，且上下文持续增长时，税率逐轮上升。
用cron定时调LLM却不重置会话、多Agent编排中父Agent被子任务阻塞超过TTL、CI流程中复用超长transcript……都是同一个坑的不同变体。
一场围绕"五分钟"的暗战
事情还有更深的一层
2026年初，开发者Sean Swanson通过分析大量Claude Code会话日志发现：1小时TTL在约2月初出现，又在约3月上旬被悄悄退回到以5分钟为主。
一个本来能撑过午饭的缓存窗口，突然缩短到了只够你倒杯咖啡。
▲ DevClass报道：TTL从1小时静默调回5分钟，引发社区配额争议
这在社区引发了轩然大波
大量Max订阅用户反映"$200/月的额度此前很少用完，3月后频繁触顶"。
Anthropic员工Jarred Sumner回应称，回到5分钟对整体更便宜，因为大量请求是一次性的，缓存根本只用一次；
但重度用户的感受恰恰相反
这是一个经典的"平均值陷阱"：对全局one-shot请求最优的默认值，对长会话重度用户可能恰恰是最贵的选择。
同一套参数调整，一边看到"更便宜"，另一边看到"更烧钱"，取决于你站在分布的哪个位置。
社区逆向分析还发现了一些疑似bug：对话中出现billing、tokens等特定字符串时，可能触发前缀被悄悄改写，导致缓存每轮都失效；
通过 --resume 恢复会话时，工具附件的注入位置与新开会话不一致，同样会破坏前缀匹配。
▲ Om Patel转述社区逆向发现：未缓存token成本可能达到命中缓存时的10-20倍
从"聊天窗口"到"带仪表盘的运行时"
社区没有坐等官方修复，而是迅速长出了一整个"缓存经济学"工具生态。
claude-thermos，一个开源反向代理，在TTL到期前自动发送极小的warm请求给缓存"续命"。
它的用户在185个会话上测出，约22%的账单纯粹来自缓存重建，也就是说，近四分之一的钱花在了"把已经算过的东西再算一遍"上。
还有keepalive插件，用Stop hook在闲置将满时注入廉价心跳；
有SuperBased这样的产品，用一杯咖啡的比喻提醒你"离开后下一条可能更贵"，并展示缓存倒计时和风险金额。
▲ 用户质疑：这类优化为何不内置进应用？是"不会做"还是"不想做"？
Tall Tale Bro的质问代表了很多人的心声：这些东西难道不应该内置到应用里吗？
Ben Dickson则从另一个角度回应，"推理栈的认知里藏着alpha"。
他特别提醒：为了省钱中途换成更便宜的模型，反而可能触发全量缓存重建，总账更高。
▲ Ben Dickson：换模型会使缓存失效，试图省钱反而可能花更多
竞品方面，Teortaxes直接拿DeepSeek做对比，声称其缓存TTL超过12小时，且写入免费、默认开启，并称Claude的体验"像原始人技术"。
当然，各家定价条款和实际体验各有差异，但竞争压力是真实的。
一张"汇率表"背后的认知革命
Xiaoyin Qu这条帖子提供的参考，不局限于13x或4.5x这些具体数字，毕竟那是她个人一个月样本的中位数，换个人、换个项目，数字会不同。
它的价值在于，第一次用大规模实测数据，把一个纯后端的技术参数，翻译成了普通用户能感知的"汇率表"。
在AI编程Agent的世界里，你的真实成本 = 标价 × 缓存命中结构 × 会话管理习惯。
同一个订阅档位下，会摘要交接的用户与死续冷会话的用户，账单可以差出一个数量级。
缓存管理已经成了每个Agent用户都该掌握的生存技能。
离开前说一句 "summarize where we are"，回来后新开一个窗口，这个动作不到十秒，但可能帮你省下三分之二的缓存重建费用。
在AI成为基础设施的时代，看不见的计费机制，往往比标价更能左右最终账单。