你有没有半夜三点半打开账单，发现没有一行代码变更、没有一次发布、没有任何手动操作痕迹，AWS 却告诉你这个月花了 1386.46 美元的时候。
往下翻翻，1182.09 是缓存写入。
一个叫 apexethdev 的倒霉蛋 8 月 9 号在 openai/codex 仓库提了个 issue：Codex CLI 走 Bedrock 调模型时，缓存写成本高到离谱。生产环境五天，3656 次请求，缓存写入 token 一亿七千多万。缓存读取呢？零。
好家伙，写了一亿多字，一个字节没读上。
评论区分了两波。有人说 3656 次请求一万多人民币，均下来一次三块多，也还行——“省了多少人工”。有人说这现象本身就逗：模型在一个会话里疯狂往同一个地方写，写完发现没人读，下一轮重新写。来来回回，把缓存玩成了自助烧烤炉——炭烧完了，肉还生着。
我觉得这事比“省不省钱”值得多想一层的地方，在 85%。缓存写入成本占模型总估算花费的 85%。而且你们注意到没有：一次本地会话 76 次请求，平均每次 8.8 万缓存写入 token，缓存读取还是零。76 次调用，每回都想把整段会话历史重写一遍，没有一次想着去读一下。什么概念？相当于买了 76 份外卖，每份都扔了，因为系统判定“这顿灵感跟上次不一样，得重新叫”。
这个行为，我熟。我自己 Claude Code 干过一模一样的事：一个 agent 为了修某个 production bug，花了大半天反复读一个从没被调用过的函数想从中找灵感。最后它自己放弃了，说“代码运行正常，可能是偶发问题”。后来查下来，那个偶发问题是变量名大小写拼错。
以前是人类对着错代码发呆，现在是你付钱让 AI 对着错代码发呆，发呆效率还更高了。
系统为什么非写不可、硬是不读？没人给你选项的时候，它默认“所有内容都不配当缓存”，于是每轮对话不管你的会话历史是一行还是两三万字，全部当冷启动重跑一遍。Codex 这边更惨：prompt_cache_key 发了，但从 HTTP 到 WebSocket、从请求头到请求体，prompt_cache_options 和 prompt_cache_breakpoint 一个没带上。你能想象那种感觉吗——钥匙都插进锁孔了，拧了一下没拧动，然后你选择站在门口等，而不是换个姿势再试一次。
我拿这事问了 AI 一句算不算缺陷。它特别认真地回我说：不一定，冷启动、完全不同的提示、分叉和压缩等场景都会产生缓存写入，不能一概而论，请您结合具体业务场景判断。
翻译成人话：“我不确定，但我不能让你知道我不确定，所以用 40 个字把你的问题变成了一道阅读题，并贴心地给你打了个及格分。”
CloudWatch 指标里没有客户端错误。系统全程健康、各项指标正常，就是这个健康的系统在频繁往缓存里写重复内容，每写一次收一次费。一个错都没犯，就把钱烧完了——这比有 bug 还让人来气。有 bug 你至少还能指着报错说“是它的问题”，这个你只能对着账单沉默。
上次我遇到同款“无错误消费”是在自己身上：半夜一点半改完需求合进去，第二天需求方改主意要改回原来的逻辑，改完 CI 发来一封祝贺邮件——“恭喜你，构建成功”。是成功了。绕了一大圈。成功在原地。
我翻自己的 token 账单，比它夸张多了。每次让 AI 解释报错，都得从它开头那两千个“收到，我来分析一下这个报错”开始付费。一次五十块的账，光是确认接单就有好几块。AI 确实记得我三小时前让它干嘛，但它得先把“它记得”这事证明给我看，证明用的 token 还得我自己掏钱。
我们这行什么时候学会了这种做派——为了显得自己专业，不惜先消费一遍自己。
这次 issue 的标题其实挺温和的：“支持在 Responses 提供方中为 GPT-5.6 增加 prompt_cache_options 序列化能力”，末了还不忘补一句“并非所有缓存写入都是缺陷”。这个“并非所有”的宽容语气我可太熟了，跟我跟 PM 说“不是所有需求变更都毫无意义”用的是同一款措辞。
（郑重声明：以上灵感来自真实账单，真实账单来自“需求方朝令夕改”这个我讲了无数遍的陈旧梗。毕竟缓存写那么多、读取还是零这件事，本身就是对陈旧最忠实的致敬 🫠）