GitHub 上有个 Issue 值得关注。
一位开发者在使用 Codex CLI 的 Amazon Bedrock 原生 provider 接入 GPT-5.6 Sol 时，发现 4 天花掉了约 1386 美元，其中85% 花在了 prompt cache write 上，而不是真正的推理使用。
事情是这样的：Codex 在工作时会维护一个 prompt_cache_key，这个 key 用来标记可以复用的缓存前缀。但在 Bedrock 的 Responses API 请求里，prompt_cache_options 和 prompt_cache_breakpoint 两个字段都没有被序列化出去。结果就是每次请求都重新写入缓存，没有一次读取，缓存完全白写。
战术数据很具体：3656 次请求，171.94M 的 cache-write tokens，而 cached_input_tokens 为零。一次本地 Codex 会话的 76 次 Sol 请求中，平均每次有 88K 的 cache-write tokens，没有任何缓存命中。
这个 Issue 还关联了上游的 #35300，说明这不是单例。评论区另一位用户 kevmyung 补充说，从 0.146.0 升级到 0.147.0 后，cache write-to-read ratio 从 0.08 飙到了 8.84，日成本至少翻了 5 倍。
AWS 的文档里已经明确写了 Bedrock 上 GPT-5.6 的显式缓存模式，专门为 agentic 工作流（稳定的 system prompt + tool definitions 前缀 + 变化中的 tool/user content）设计的。Codex 的 workload 正好匹配这个场景，但接口没连上。
Issue 作者提了四个具体的修复请求：
- 对支持 GPT-5.6 的 Responses provider 序列化
prompt_cache_options - 给 content blocks 加上
prompt_cache_breakpoint字段 - 在 Codex 的稳定 instruction/tool 前缀末尾自动打断点
- 在每轮 usage telemetry 里暴露 cache reads 和 cache writes
有一点要说明，Issue 作者很严谨地解释了：不是所有 cache write 都是 bug，冷启动、分支、fork、compaction 都会产生写入。问题是 Bedrock 原生 provider 完全没给用户选择显式缓存的机会。
另外，评论区还有另一层讨论：cache_write_input_tokens 应该作为独立的诊断指标展示，但不应该自动加到 provider 的 input_tokens 上去算总成本，除非 provider 确认这两个 bucket 是不重叠的。这个语义细节如果搞错了，会直接导致成本展示翻倍。