一个 web_search 开关，账单涨了四五倍：复盘 Codex 在 Bedrock 上的提示词缓存事故

Sun, 23 Aug 2026 09:00:00 +0800

设想这样一个场景：你把自己常用的 Codex CLI 挂到了 AWS Bedrock 上，用 GPT-5.6 Sol 跑日常的 agentic 编码任务。一切看起来正常，命令照跑，代码照写，模型响应也很快。直到你打开 Cost Explorer，发现这周的账单比预期多出好几百美元。你翻来覆去检查自己的用量，请求数没有暴涨，代码量也没变多，可钱就是凭空多出来了。

这不是虚构。2026 年 8 月，一位开发者在 openai/codex 仓库提交了 issue #37674，记录的就是这样一起真实发生的事故。账单里多出来的那一大块，全是一个叫「cache-write」的东西。

账本里凭空多出的 85%

issue 作者贴出的数据很直接：在 8 月 5 日到 8 日这四天里，他通过 Bedrock 跑了 3656 次请求，累计产生了 1.719 亿个 cache-write token。按照 Bedrock 的费率估算，光缓存写入这一项就烧掉了约 1182 美元，而同期总成本约 1386 美元。也就是说，85% 的钱都花在了「写缓存」上，而「读缓存」的 token 是零。

这里需要先解释一个概念。所谓提示词缓存（prompt caching），指的是模型服务商把请求里重复出现的那段「前缀」缓存下来，比如系统提示词、工具定义、项目约定这些每次都一样的部分。下一次请求时，模型直接读缓存，不用重新计算，成本能降到正常输入的十分之一甚至更低。对应地，缓存有「写」和「读」两个动作：写缓存按正常 token 甚至略高的价格计费，读缓存则便宜得多。

一个健康的 agentic 编码会话，应该是「写一次、读很多次」。第一次请求把稳定的前缀写进缓存，之后每一轮对话只处理新增的那一小段尾巴。可 issue 里的数据恰好反了过来：读是零，写却占了 85%。这意味着每一次请求，模型都在把整段前缀重新写一遍，从来没从缓存里读到过任何东西。

作者还给了个更直观的观察：本地一次 76 个请求的 Codex 会话里，cache_write_input_tokens 高达 670 万，cached_input_tokens 是零，平均每个请求要写约 8.8 万个 token。而 CloudWatch 里没有任何客户端错误。也就是说，这不是报错，而是模型在「正常地」反复重写同一段内容，钱就是这么无声无息流走的。

提示词缓存 on Codexer

一个 web_search 开关，账单涨了四五倍：复盘 Codex 在 Bedrock 上的提示词缓存事故

账本里凭空多出的 85%