Codex Ultrafast 模式偶尔消失？拆解本地模型目录 workaround
来源：李不凯正在研究的 X 原帖，发布于 2026 年 10 月 13 日。原帖称，作者在本地复制 Codex 的模型目录缓存，再通过
config.toml中的model_catalog_json指向该副本，从而让 Codex App 中的 GPT-6.1 Sol Ultrafast 选项稳定显示。作者关于 OpenAI 算力和账号控制的解释是个人猜测，并非已证实原因。本文整理的是社区 workaround，不代表 OpenAI 官方配置建议或服务承诺。
先说结论
如果你在 Codex App 中遇到 Ultrafast 选项时有时无，李不凯分享了一种本地配置 workaround：保留一份包含 Ultrafast 条目的模型目录 JSON 副本，再让 Codex 从这份本地副本读取模型能力信息。原帖称这样可以避免目录刷新后选项消失。
这项操作改变的是客户端用于展示或识别模型速度档位的目录来源。它不能增加账号本身的使用资格，也不能保证请求一定以 Ultrafast 速度运行。服务端是否接受对应档位、账号是否可用、当时是否发生降级，都需要分别验证。
原帖中的现象与方法
作者描述的问题是：部分 Pro 500 用户在 Codex App 里看不到 GPT-6.1 Sol 的 Ultrafast 选项；即使短暂出现，执行期间也可能消失或降级。作者还提到，通过 Dot 在项目中创建新任务时，当时没有遇到相同情况。这些是原帖作者汇总的用户反馈与个人体验，不是面向所有账号和版本的复现实验。
原帖给出的思路分为两步：
- 找到
~/.codex/models_cache.json，将包含ultrafast的速度档位和服务档位条目保存在本地副本中。配图展示的字段名是additional_speed_tiers和service_tiers。 - 在
~/.codex/config.toml添加model_catalog_json配置，将模型目录指向这份副本，然后完全退出并重启 Codex。
原帖正文把字段称为 speed_tiers，但配图中显示的是 additional_speed_tiers；图片还展示了 service_tiers。这是来源本身的文字与截图差异，不能擅自视为同一个字段。配图没有展示完整的 config.toml 配置行、路径格式、完整 JSON 结构或版本信息，因此这里不补写未经来源证明的 TOML 语法。具体字段是否仍被当前 Codex App 识别，应以你所用版本的实际行为为准。
为什么本地目录会影响选项显示
按照作者的解释，Codex 会读取模型目录里的速度档位与服务档位信息，决定界面为某个模型提供哪些模式。如果客户端持续刷新服务器上的模型目录，那么目录中某个档位的变化可能反映到界面上；固定读取本地副本则可以让这部分客户端目录保持不变。
这个解释能说明 workaround 的设计意图，但还不能证明 Codex 的所有版本都用相同字段、刷新逻辑或配置优先级。至少要区分三个层次：
| 层次 | 本地目录可能影响什么 | 不能由它证明什么 |
|---|---|---|
| 客户端目录 | 模型条目和速度档位是否出现在选择界面 | 账号已获得服务端资格 |
| 请求执行 | 客户端提交的档位以及界面显示状态 | 后端一定按该档位处理请求 |
| 服务端策略 | 账号资格、限额、负载和实际服务行为 | 不能通过编辑本地 JSON 改变 |
所以，按钮重新出现是一个 UI 结果；它本身不是服务端承诺，也不是速度或配额已经生效的证明。
作者猜测与已知事实要分开
原帖推测，Ultrafast 的波动可能与 OpenAI 算力不足、通过控制可用账号数量保障体验有关。作者也用“阴招”表达了对这种产品体验的不满。这部分是作者对现象的解释和评论，原帖没有提供官方说明、服务状态记录、账户级数据或可重复测试来证实原因。
更稳妥的表述是：作者观察到客户端中的选项会变化，并尝试固定本地目录来保持选项可见；变化背后的服务端原因尚未由这条帖子证实。即使这个 workaround 对某个客户端版本有效，也不能据此推断 OpenAI 的配额设计、资源状况或账号分配机制。
尝试前先留存与备份
如果你决定自行评估这类本地 workaround，先记录当前状态，确保能恢复原配置：
- 记下 Codex App 版本、操作系统、登录账号类型、模型名称，以及问题发生的时间。
- 记录 Ultrafast 是一开始就不可见，还是执行中消失；若界面显示降级，也一并记录。
- 备份现有
~/.codex/config.toml和~/.codex/models_cache.json。不要直接覆盖唯一副本，也不要把个人配置文件上传到公开仓库或论坛。 - 阅读你当前版本的配置和模型目录，确认字段结构、文件权限与路径。不要把截图中的片段误当成完整 JSON 文件。
- 若尝试固定目录，只改这一项并保留原文件。完全退出 Codex 后再启动，检查选择器和实际任务表现。
不要为了让界面出现某个选项而盲目粘贴来历不明的目录内容。模型目录可能随客户端更新而变化；字段遗漏、格式错误或路径失效都可能造成配置不被读取，甚至影响模型列表。
怎样验证是否真的有效
建议用小任务做前后对照，而不是仅凭菜单判断：
- 界面检查：重启后记录 GPT-6.1 Sol 的 Ultrafast 是否出现，并确认所选模式没有在新建任务时重置。
- 执行检查：运行一个低风险、耗时短且容易复现的任务，观察任务过程中所选档位是否仍然保留。
- 重复检查：退出并重启一次，再检查结果是否一致。只在一个会话中出现，不足以说明目录已经稳定生效。
- 分清性能与显示：记录耗时只能说明这次请求花了多久，不能单独证明后端使用了某个服务档位。若产品没有提供可信的请求级档位信息，就不要把速度变化归因于 Ultrafast。
- 设置停止条件：如果出现模型列表异常、启动错误、请求失败或档位仍自动变化，停止继续修改并恢复备份。
记录至少包括 App 版本、发生时间、操作步骤、配置变动和观察结果。这样才能区分目录文件是否被读取、界面是否稳定，以及请求是否真的按预期执行。
回滚与后续维护
若配置导致异常，完全退出 Codex，将备份的配置文件恢复到原路径，再重新启动。若 workaround 暂时有效，也应保留“何时从哪个版本复制了模型目录”的记录，并在 Codex App 更新后重新检查。
本地固定目录的代价是它可能变旧。服务器端新增模型或更新字段后，本地副本未必同步；如果未来官方更改客户端配置格式，旧配置也可能失效。因此更适合把它看作针对特定版本现象的临时排查手段，而不是一次配置、永久有效的开关。
适用边界
- 这篇文章转述的是李不凯的个人经验，不是对 Codex 内部实现的独立审计。
- 原帖没有给出完整
config.toml语法，因此本文不提供可直接复制粘贴的配置行。 - 固定本地模型目录至多可能影响客户端可见的目录信息，不能授予账号资格、绕过服务端限制或保证速度。
- 关于算力不足和按账号控制模式可用性的说法属于原作者猜测，尚不能从这条原帖确认。
- 在改动前备份文件；出错时恢复原文件，并以当前 Codex App 的实际配置行为为准。