报错好歹会留下点东西，状态码、堆栈、一行英文提示，拿去搜总能搜到点什么。Codex 变慢就麻烦得多：任务照样能跑完，只是原本几分钟的活拖成半小时，界面一直在转，回头想反馈，手里只有「感觉慢」三个字。这类讨论往往吵成两派，一派说官方那边扛不住，一派说是自己网络的事，两边都拿不出数据。
状态页上记了什么
能对上时间的，是 OpenAI 的状态页历史。写这帖时重新翻了一遍，10 月最后一周记了这几条（页面上的日期跟时区有关，下面按页面标的日期写）：
- 10 月 30 日两条：一条是 Dots、ChatGPT Work 和部分 ChatGPT 思考类功能里的搜索出错，受影响组件标的是 ChatGPT Work 和 dots。另一条是 API 里 GPT Image 2 图片编辑的错误率升高。
- 10 月 27 日两条：一条叫「6.1 Sol Degraded Model Performance」，受影响组件是 API 下的 Chat Completions、Responses 和 Batch，一个多小时后恢复。另一条是私有 GitHub 仓库上的托管 Code Review 和 Security Review 错误率升高，没有标记受影响组件，半小时左右解决。
标题里直接写着 Codex 的，最近一条要往前翻到 10 月 20 日前后的「Degraded performance in ChatGPT, Codex, and APIs」，再往前是 13、14 日的两条。
也就是说，最近十来天状态页上没有专门针对 Codex 变慢的事故。6.1 Sol 那条标的是 API 组件，页面没说 Codex 用这个模型时有没有受影响，这一点没法从状态页推出来。单条事故点进去，能看到受影响的组件，以及调查、缓解、恢复每一步的时间，比列表页上的标题有用得多。拿自己变慢的时间段去对照，组件和时间都对得上才算数。可状态页没记，也不等于后台一定没出问题。目前「变慢」只有用户自己的反馈，官方没有确认过。
换个入口、换个模型
同一个仓库、同一个任务，拿 CLI、桌面端、IDE 插件各跑一遍。如果只有某一个入口慢，问题多半在那个客户端或者它所在的环境，比如插件版本、编辑器里装的其他扩展、WSL 这一层。要是几个入口一样慢，就换个模型再试。换了模型立刻正常，说明慢在那个模型上，拿这个结论去反馈才有分量。
插件一直转圈、WSL 下的问题，站里这篇有讨论。中途报 stream disconnected 的是另一类毛病，见这里。这帖说的是不报错、单纯慢。
本机这一段
走代理或者公司网关的，顺手看一眼同样走这条路的其他 HTTPS 请求慢不慢。换一个网络（比如手机热点）跑同一个任务，耗时差得多的话，问题多半出在本地网络这一段，跟 Codex 关系不大。
把「慢」变成数字
想让反馈有用，得能复现：
- 固定一段提示和一个小仓库，每次从同一个提交开始。
- 记下从发出到第一段输出的时间、整个任务的总时长、中间调了多少次工具。
- 把客户端版本、模型、推理强度一起记上，换任何一项都另记一行。
- 隔几个小时、换几个时段重复跑，看是全天都慢，还是集中在某些时段。
有了这张表，再去对照状态页的时间线，哪个时段变慢、差了多少、和哪条事故重叠，都能看清楚。没有这些数字，「我觉得慢」很难被当成问题处理。
最近用 Codex 的，有人实际测过首段输出要等多久吗？