从对话、登录到 Agent 与 Atlas，受影响清单接近十五项；约二十分钟后先回来一批，剩下的分批补齐。
OpenAI 把这次事故标成「ChatGPT 与 Codex 错误率升高」，一句话交代完。真正有信息量的是它列出的受影响范围：对话、登录、ChatGPT Work、Codex 桌面端、合规 API、搜索、文件上传、语音模式、GPTs、图像生成、深度研究、Agent、ChatGPT Atlas、Sites，以及连接器与应用。
把这份清单读一遍就会发现，「登录」和「图像生成」被并排列在一起，而这是两类完全不同的东西——一个是账号入口，一个是推理任务；「文件上传」和「深度研究」同样如此，一个走存储，一个走长任务编排。它们同时躺倒，通常不指向某一片模型集群，而指向这些产品共用的那一层：网关、鉴权、请求路由。
同一晚 Anthropic 那边的事故正好是个反例。它的状态页点了具体型号——Mythos 5.1、Fable 5.1、Opus 5，随后补上 Opus 4.8 和 Opus 4.6，而 Sonnet 5 是当天更早的另一条独立事故。模型层出问题，通报里会有型号名单；入口层出问题，通报里就是一长串产品名。这次 OpenAI 从头到尾没有点任何模型的名字。
恢复曲线也对得上。故障起于美东时间 9 月 3 日上午 10:58，也就是北京时间当晚 22:58；大约二十来分钟后就有用户报告能用了，但 OpenAI 当时的措辞是已经实施修复、正在观察效果，并承认服务仍处于降级状态。把全部受影响项标回正常，比第一批用户恢复要晚不少。
如果坏的是入口层，这个形状是自然的：网关一恢复，短请求当场就通，所以「二十分钟回来一半」；但排队积压的长任务——深度研究、Agent、批量文件上传——要等下游把堆积消化完才算真正恢复，尾巴因此拖得长。对只是聊两句的人来说，这次故障的体感是十几分钟；对挂着 Codex 跑任务、或者正在等一份深度研究结果的人来说，完全是另一回事。同一条事故记录，对两类用户的实际含义差出好几倍。
时间点确实敏感。故障发生时 OpenAI 正处在新模型 Astra 的发布前夕，官方账号那几天还在放「The stars are almost aligned」这样的预热话。社区顺手就把两件事连起来了——上新前的灰度、路由表调整、容量预热，任何一项都可能让入口层抖一下。
但目前没有任何一方给出这种因果。BleepingComputer 在报道里直接给了反向判断，认为与 Astra 相关的可能性不大，理由很朴素：ChatGPT 本来就常挂。这个说法不好听，却站得住——把每一次故障都归到最近一次发布，是一种成本极低、也经常猜错的推理。在官方给出根因之前，两件事只能算同一天发生，不能算同一件事。
值得留意的是，状态页从头到尾没有解释这次为什么会挂。更新只有三段：正在调查、已找到修复方式、正在恢复。没有根因，也没有承诺事后复盘。同一晚 Claude 和 Grok 各自出状况，三家的状态页写法几乎是同一个模子——时间精确到分钟，内容止步于「已修复」。
对个人用户，这没什么影响，刷新几次就过去了。对把这些接口接进自己产品的人，差别就大了：状态页能告诉你此刻能不能用，却不能告诉你下周会不会再来一次。这一晚最实在的信息大概不是十五项功能同时躺倒，而是躺倒之后，你依然拿不到那个「为什么」。