Codex 桌面端藏起了 Fast 模式：API Key 用户实测吞吐掉四成

Fri, 14 Aug 2026 09:00:00 +0800

你最近把 Codex 桌面端从 ChatGPT 账号切换成了 API Key。理由很充分：按月充值、按量付费，成本看得见，也更好控制。结果刚切完，你就发现一个不对劲的地方，那个熟悉的 Fast 模式开关不见了。

你翻出 TOML 配置文件，手动把 service_tier 写成 fast，保存、重启应用，速度却纹丝不动。你甚至怀疑是不是自己哪里配错了，或者 Fast 模式本来就只对订阅账号开放。

一位叫 Andrew Denta 的开发者遇到了完全相同的问题。不同的是，他没有停留在猜测，而是自己写了个测速工具，跑了一组严格的对照实验，最后不仅定位到了原因，还直接改掉桌面端 Electron 应用的源码来证明自己的结论。

一、Fast 模式到底是什么，值得这么较真吗

Fast 模式是 OpenAI 提供的一档更高优先级的推理服务。在官方 API 文档里，符合条件的请求可以显式指定 service_tier: “fast”（等价于 priority 档位），响应里也会标明实际落到了哪一档。它的代价是更高的单价，换来的则是更高的吞吐、更低的排队延迟。

对于整天在终端里跟 Codex 打交道的开发者来说，Fast 和 Standard 之间的差距是能直接感受到的：同一个任务，Fast 可能几分钟跑完，Standard 就要多等上一阵。所以当桌面端的开关消失时，这个问题立刻变得很具体：你是真的变慢了，还是只是心理作用在作祟？

Denta 最初的判断依据很朴素：Fast 模式在 CLI 里用 API Key 完全正常，唯独在桌面端不生效。如果这是官方有意为之，那 CLI 里为什么又能用？他倾向于认为，这更像是一个 bug，而不是一个深思熟虑的产品决策。

二、怎么证明「变慢了」：自己造一把尺子

空口说「变慢」没有说服力，得拿出数字来。Denta 写了一个叫 codex-tps 的小工具，原理很巧妙：它不调用任何 API，也不发送任何遥测，而是直接去读 Codex 本地家目录里已经存好的 rollout JSONL 日志。

这份日志记录了每次模型响应精确的 token 用量，但缺少逐 token 的时间线。于是他用一个折算公式来近似：effective TPS 等于输出 token 数除以模型响应耗时。响应窗口从上次输入或用量边界之后开始，到最后一个模型生成的条目结束，中间的工具执行时间被剔除，首 token 延迟算进去，输出 token 里包含推理 token。

实测 on Codexer

Codex 桌面端藏起了 Fast 模式：API Key 用户实测吞吐掉四成

一、Fast 模式到底是什么，值得这么较真吗

二、怎么证明「变慢了」：自己造一把尺子