Codex 缓存命中率实测

关键结论

• 正常值: 96.0%, 38 个用户连续对话的中位数，中间一半在 93.1%–97.2%
• 全部请求: 93.6%, 含换号、过期、新对话等全部未命中
• 最大的未命中原因: 连续对话中的新内容, 占未命中的 73%
• 各形态之间: 相差 2.1 个点, 桌面应用、终端界面、codex exec（非交互）

各客户端的缓存命中率多少算正常

数据周：2026-09-29 – 2026-10-05（UTC）

• 连续对话命中率（用户中位数）: 96.0%
• 中间一半用户: 93.1%–97.2%
• 达标用户: 38 (一周至少 20 个连续轮次)
• 全部请求的命中率: 93.6%

Codex 各形态的命中率

同一客户端的命令行、IDE 插件和桌面应用发出的请求基本相同，命中率也应接近。

• 桌面应用: 95.7% (27)
• 终端界面: 96.0% (8)
• codex exec（非交互）: 97.8% (6)

Codex 各版本的命中率

某个版本改动了请求前缀时，它的命中率会明显低于其他版本；这张表在出问题的那一周就能看出来。

• 0.160.0: 96.2% (21)
• 0.159.2: 96.1% (9)
• 0.159.0-alpha.12.1: 95.7% (5)
• 0.158.0-alpha.2.1: 93.5% (7)

为什么 Codex 缓存命中率低：未命中原因拆解

本周全部输入里有 6.4% 没有从缓存读取。下面按原因拆开，每一类给出可以做的事。

连续对话里的新增内容和前缀变化: 占未命中的 73%, 约占全部输入 4.7%

OpenAI 的缓存要求整个前缀一致。中途切换推理档位（reasoning effort）、工具、输出格式，或 Codex 自动压缩历史（compaction），都会让前缀变化。这是 Codex 未命中的最大来源。

新对话，或闲置超过 1 小时: 占未命中的 11%, 约占全部输入 0.7%

新对话的第一条请求，或闲置超过 1 小时后，只能重新写入缓存。

被路由到另一个上游账号或端点: 占未命中的 10%, 约占全部输入 0.6%

提示缓存保存在处理请求的那个上游账号里。中转站或多账号网关把同一对话的下一条请求发到另一个账号时，整段上下文要重新写入。直连官方不会出现这一项。

间隔超过 5 分钟，缓存已过期: 占未命中的 3%, 约占全部输入 0.2%

GPT-5.6 及以后的模型缓存默认保留 30 分钟，从最近一次写入或复用算起；更早的模型在闲置 5–10 分钟后通常就会失效。

并行请求（上一条还没结束）: 占未命中的 1%, 约占全部输入 0.1%

上一条请求还没结束就发出下一条（子代理、并行工具调用），后一条读不到前一条正在写入的缓存。

换了模型: 占未命中的 1%, 约占全部输入 0.1%

每个模型有独立的缓存，换模型后下一条请求要重新读入整段历史。

Codex 缓存多久失效（TTL）、怎么收费

• OpenAI 自动缓存提示前缀，不需要客户端打断点；GPT-5.6 及以后的模型从 1,024 token 起缓存。
• GPT-5.6 及以后：默认保留 30 分钟，从最近一次写入或复用算起。更早的模型：内存缓存通常在闲置 5–10 分钟后失效，最长 1 小时；部分模型支持 24 小时保留。
• 缓存读取一般按输入价的 0.1 倍计费，GPT-6.1 Sol 是 0.05 倍；GPT-5.6 及以后的模型对缓存写入收输入价的 1.25 倍。
• Codex 把会话 ID 作为 prompt_cache_key 发送（以源码为准），同一会话的请求会被送往同一份缓存。

OpenAI 提示缓存文档 · OpenAI 缓存未命中诊断 · Codex 源码（prompt_cache_key） · Codex issue #35416：切换推理档位导致未命中

怎么查看 Codex 的缓存命中率

• Codex CLI 退出时打印本次会话的 token 用量，括号里的 "+ N cached" 就是从缓存读取的输入（当前版本的行为，官方文档未写）。
• 自己算：usage.input_tokens_details.cached_tokens ÷ usage.input_tokens；GPT-5.6 及以后的模型还会返回缓存写入数。
• OpenTelemetry 指标 turn.token_usage 里有 cached_input 类型。
• 通过 Wokey 使用时，控制台的请求明细里每条请求都有缓存读取和缓存写入两列。

OpenAI 缓存未命中诊断

通过中转站使用时，命中率为什么更低

• 换账号：缓存属于上游账号，下一条被发到另一个账号就要整段重写。这是中转站最常见的原因，直连官方不会有。
• 协议转换：把 Anthropic 格式和 OpenAI 格式互相转换时，可能改动前缀或丢掉 cache_control 断点。
• 旧版 Claude Code（v2.1.181 之前）通过自定义 Base URL 时，系统提示开头的署名块每次带不同的 token，按请求体做缓存的网关会全部打不中；升级，或设 CLAUDE_CODE_ATTRIBUTION_HEADER=0。
• 自测：连续发两条前缀相同、超过最小缓存长度的请求，第二条的缓存读取应接近前缀长度。

Wokey 优先把同一对话的后续请求发往同一上游账号。2026-10-04 至 2026-10-10，Wokey 普通用户在 Claude Opus 5.5 上全部请求的命中率为 92.8%，同期 OpenRouter 整体为 87.8%。

对比 OpenRouter 的缓存命中率 · 实时数据：Wokey 公开缓存命中率接口（近 7 天）

怎么测的

• 数据来自 Wokey 网关上真实用户的请求，每周一 05:00 UTC 统计上一周（周一至周日）。
• 客户端按请求的 User-Agent 识别。SDK、HTTP 库和下游中转发来的请求看不出真实客户端，不计入；企业客户不计入。
• 连续轮次：和同一对话的上一条请求同模型、同上游账号，且在其结束后 5 分钟内发出。每个用户的命中率 = 连续轮次的缓存读取 ÷ 输入（输入含缓存读写），取一周至少 20 个连续轮次的用户的中位数。
• 每格至少 5 个达标用户才发布；和上周相比变化超过 3 个百分点时，先人工核对再发布。
• 已知偏差：只覆盖 Wokey 用户；不同用户的使用习惯差别很大；全部请求的命中率里包含网关自身的路由损失（见"被路由到另一个上游账号"一项）。

常见问题