bug(codex-oauth): 带图片的长会话 prompt cache 崩到只剩 ~30k token 头部（真实流量 6-9%），而字节级稳定的合成请求可达 99%

环境

• 版本：v3.5.0（首次观察到问题），v3.5.2.1（今日升级后复测，行为相同）
• provider：openai-codex-oauth，单个 ChatGPT Pro OAuth 账号
• 客户端：Factory/Droid（OpenAI 兼容 Responses，走 provider 作用域路径）
• 模型：gpt-6-astra（主要）、gpt-6-sol；docker 部署

现象（真实流量）

长会话（历史早期包含图片）中，Model Usage Stats 日志里 Prompt 持续增长（347k → 478k token），但 Cached 卡死在一个固定"头部平台"：

时间 (UTC)	Prompt	Cached	占比
...（24 小时内 40+ 条）	347k → 478k	29,952（固定）	~6-9%
偶发	—	3,968 / 41,984（另外两个平台值）	—

关键观察：

1. 同一 workspace 下 astra 和 sol 两个不同模型的会话命中同一个 29,952 头部平台 → 说明匹配到的是一段共享的稳定头部（system/AGENTS/清单类内容），分歧点就在它之后、每个回合都变化。
2. 同面板同时段的纯文本长会话缓存 94-99.8%（例如 gpt-6-sol 151,839 → 150,528 = 99.1%）。
3. 出现过一次瞬时 miss 后立即恢复（同一 prompt 大小 152,849：19.6% → 重试 99.6%）。

排除项（合成探测，v3.5.0 与 v3.5.2.1 均已测）

用字节完全相同的请求对（同一账号、150 秒间隔、gpt-6-astra / low / deterministic 前缀）：

探测	冷请求	字节级相同的重复请求
纯文本 ~26k token	15.6%	99.8%
文本 + 图片（尾部）	15.4%	98.2%（第三次重复 99.6%，重复写入会扩展前缀）
文本13k + 图片居中 + 文本13k	15.3%	99.6%

结论：上游对图片本身可以正常缓存（包括穿过中间图片），面板对稳定 payload 的转发也正常。真实会话的问题不是"图片不能缓存"或尺寸因素。

无法自行定位的原因

面板目前没有请求体录制功能，我们拿不到真实会话逐轮的出站字节，因此无法区分：是客户端序列化逐轮变化，还是面板对真实请求形状（reasoning items 回放、tools 规范化、环境块等）做了逐轮不同的改写。作为背景：同一客户端在另一个代理（codex-lb）上的出站 payload 已被证明是字节级 append-only 稳定，那边的问题出在其自身传输层（见 Soju06/codex-lb#2465，仅供参考）。

想请教 / 请求

1. openai-codex-oauth 的 Responses 转发链路是否会对请求做逐轮变化的改写（reasoning/replay items、tools 归一化、注入的上下文块）？
2. 面板是否向上游发送或派生 prompt_cache_key / session 相关头？
3. 能否加一个（脱敏的）request-body 录制调试开关，或指点应该看哪些日志/代码位置来定位分歧点？

我们可以提供脱敏的 Model Usage Stats 日志、探测脚本和完整的测试表格。谢谢！