你最近把 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。

作者自己也强调，这不是一个纯粹的 decoder 跑分，而是「真实 Codex 响应速度」的近似度量。恰恰是这种贴近真实工作流的测法，才更能反映日常使用里的体感。

三、一组对照实验，把差距摆到台面上#

所有实验都在 GPT-5.6-sol 模型、high 推理档位下进行。配置矩阵如下，数字是输出 token 每秒的中位数：

配置中位 TPS
桌面端 + API Key + 配置 service_tier=fast54.7
桌面端 + API Key + 强制 Fast UI（打过补丁）87.3
桌面端 + API Key + 档位 + feature flag60.7
桌面端 + API Key + 仅 feature flag45.4
桌面端 + API Key + 无任何 Fast 设置59.3
CLI + API Key + Standard57.5
CLI + API Key + Fast90.2
桌面端 + ChatGPT 账号 + Standard35.3
桌面端 + ChatGPT 账号 + Fast/Priority45.6

几组数字摆在一起，结论就清楚了。CLI 里开 Fast 能跑到 90.2 TPS，而桌面端就算你在配置文件里老老实实写了 service_tier=fast，也只有 54.7 TPS，跟 CLI 的 Standard（57.5）几乎一模一样。也就是说，桌面端把 Fast 请求悄悄降回了普通档位。

更关键的是「打过补丁」那一行：一旦把桌面端里那两处隐藏逻辑改掉，同样是 API Key，TPS 立刻跳到 87.3，跟 CLI 的 Fast 几乎持平。这等于把因果关系锁死了：问题既不在 API Key，也不在账号权限，就在桌面端渲染层的判断逻辑上。

四、根因：渲染层把 service_tier 剥掉了#

Denta 翻了日志，看到桌面端在发请求时，把 service_tier 直接写成了 None，等于把 fast 这个参数整个吞掉了。

他的补丁项目 codex-fast-mode-patcher 进一步定位到：桌面端渲染层里有两个「字节级一致」的比较判断，一个控制界面上是否展示 Fast 模式选项，另一个控制在构造请求时 Fast 是否被视为可用。这两个判断都以「是不是用 API Key 登录」作为门控条件。

换句话说，API Key 用户一登录，这两道门就自动关上，Fast 模式从界面到请求都被拦下。而 ChatGPT 账号用户则完全不受影响。这也解释了为什么改 TOML 配置文件一点用都没有：真正的门控根本不在配置文件里，而在渲染层那些不透明的判断里。

五、补丁能修，但代价不小#

Denta 在项目里明确写了，这是一个「故意做得危险」的概念验证，不是推荐日常使用的工具。它做的事情包括：替换 /Applications/ChatGPT.app、破坏 OpenAI 的代码签名、再用本地 ad-hoc 签名把改过的 bundle 签回去。

这一连串操作意味着很多副作用：官方更新可能失效，Keychain 访问和系统权限可能出问题，通知和深链可能断掉，插件和启动行为可能异常，最坏的情况是整个应用都得删掉重装。而且它只支持一个特定版本（26.803.61601、build 6396、仅 macOS），任何版本不一致都会直接拒绝执行。

所以他给读者的建议是一句很重的话：别盲目让你的 agent 去干这件事。

六、我的看法：真正的问题是不透明#

这件事表面上看是一个 Fast 模式的开关问题，但我认为它戳中了桌面端产品一个更普遍的现象：同一个功能，在 CLI 和桌面端之间出现了配置漂移。

CLI 是透明的。配置文件、环境变量、日志都摆在明处，Fast 能不能用、为什么不能用，你自己能查、也能改。桌面端则是一个黑盒，渲染层的判断逻辑既不写在文档里，也不出现在界面上。当两者的行为不一致时，用户只能靠猜，或者像 Denta 这样，靠逆向和实测去把真相挖出来。

这跟很多开发者在使用 Codex 时的体感是一致的：CLI 让人安心，桌面端让人省心，但省心的代价是失去了对底层的控制。对于在意速度、成本和确定性的重度用户来说，这种不透明本身就是一种成本。

从更务实的角度看，如果你今天就想让 Codex 桌面端跑得快一点，有几条路可以走。一是继续用 CLI，它的 Fast 模式对 API Key 是放开的。二是接受 Standard 档位，把省下来的钱花在更多任务上。三是如果你确实需要桌面端的界面体验、又愿意承担风险，可以参考 Denta 的补丁思路，但一定要在非生产机器上操作，做好完整备份和回滚准备。

我个人更倾向于第四条路：把这个问题如实反馈给官方，让它在后续版本里把开关对 API Key 用户放开。补丁能解决问题，但解决问题的正确位置应该在产品侧，而不是在用户篡改过的二进制里。

总结#

一场「Fast 模式消失」的小抱怨，最终演变成了一次完整的取证：从现象到假设，从假设到自建工具，从工具到对照实验，再到逆向定位根因，最后给出一个危险的补丁。

它给我的最大启发，不是「桌面端有个 bug」，而是一种态度：当工具的行为不符合预期时，与其反复猜测，不如动手测量。数据一旦摆出来，很多模糊的争论自然就有了答案。

参考来源：

  • Andrew Denta，《Codex Blocks Fast Mode with an API Key on Desktop》，2026-08-13
  • adenta/codex-fast-mode-patcher（GitHub）
  • adenta/codex-tps（GitHub）