---
title: "Codex 报错 at capacity 怎么办：10 月官方故障记录与 4 步排查（2026）"
description: "Codex 提示 Selected model is at capacity 时，先看官方状态页和 cdnping 判断是否服务端故障，再升级 CLI、查本地网络。附 9 月底至 10 月 14 日事件时间线和重试改动。"
url: https://cdnping.org/blog/codex-outages-october-2026-capacity
language: zh-CN
published: 2026-10-18
category: "排障指南"
tags: ["Codex","故障排查","OpenAI","状态页","报错"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# Codex 报错 at capacity 怎么办：10 月官方故障记录与 4 步排查（2026）

遇到 Codex 报错 at capacity（"Selected model is at capacity"），多数情况是服务端算力紧张，不是你的网络或配置出了问题。先查官方状态页和 [/down/codex](/down/codex)，确认没有进行中的事件，再把 CLI 升级到最新版，最后才轮到检查本地网络。本文整理 2026 年 9 月下旬到 10 月 14 日的官方事件记录，并给出一套可以照做的排查顺序。

## 这段时间 Codex 出了哪些官方记录？

[OpenAI 状态页历史](https://status.openai.com/history)显示，2026 年 9 月 17 日之后，标题含 Codex 的事件不止下表这些（9 月 18 日、20 日还各有一起），下表只列 9 月 25 日起的 8 起，按状态页标题整理，时间为状态页列出的时间，具体时区以页面为准。

| 日期 | 状态页标题（大意） | 备注 |
| --- | --- | --- |
| 9 月 25 日 | Issues with Codex | 无 |
| 10 月 3 日 | ChatGPT 与 Codex 错误率升高 | 部分 Codex remote control 用户需要重新配对手机 |
| 10 月 6 日 | Codex Cloud 错误率升高 | 无 |
| 10 月 6 日 | ChatGPT、Codex 与 API（含 Agents API）错误率升高 | 无 |
| 10 月 7 日 | Dot 可能无法创建新线程 | 无 |
| 10 月 7 日 | Codex 与 Work 模式性能下降 | 状态页提到响应延迟、turn 失败等 |
| 10 月 13 日 | 某一模型在 Codex 与 ChatGPT Work 中性能下降 | 无 |
| 10 月 14 日 | Codex 与 ChatGPT Work 性能下降 | 无 |

状态页只给标题和简短说明，不会写明根因，也不一定写出具体的报错文字。所以"at capacity"与上面哪一起事件对应，官方没有说，不要自行对应。

## 怎么判断是官方故障还是自己的网络？

按下面顺序做，大约几分钟：

1. 打开 [OpenAI 状态页](https://status.openai.com/history)，看有没有未恢复的 Codex 或 ChatGPT 事件。
2. 打开 cdnping 的 [/down/codex](/down/codex) 和 [/status/openai](/status/openai)。前者综合官方状态页、每 5 分钟的 API 探测和用户报告，后者是从 Cloudflare 边缘探测官方 API 入口。注意 cdnping 从 2026-10-17 才开始采集，只能反映当前，不能当作这段时间的历史统计。
3. 如果官方和探测都正常，但只有你报错，再去查本地：出口、DNS、代理是否一致。可以参考[ChatGPT 挂了吗？三步判断是服务故障还是自己的网络问题](/blog/is-chatgpt-down-or-my-network)和[开发者网络自检清单（2026 版）](/blog/developer-network-self-check-2026)。
4. 报错带有明确的 "at capacity"、429 或 5xx 字样，且别人也在反馈，多半是服务端问题，等待和重试比折腾网络更有效。

状态页怎么读、事件等级代表什么，见[怎么看 OpenAI 状态页和 Claude 状态页](/blog/how-to-read-ai-status-pages)。同期其他服务的情况可以看[AI 服务故障盘点：2026 年 9–10 月](/blog/ai-service-incidents-sep-oct-2026)。

## 升级 CLI 有用吗？

有一定帮助。[官方更新日志](https://learn.chatgpt.com/docs/changelog)里与过载相关的改动如下：

- Codex CLI 0.161.0（2026-10-07）：条目写明 Responses 重试和 WebSocket 回退到 HTTP 时会遵循服务端的重试建议，以减少过载时的过早失败；同时修复了恢复线程时历史不完整的问题。
- Codex CLI 0.162.0（2026-10-08）：对可重试的 Responses 与 WebSocket 失败，遵循服务端的 Retry-After 建议；并为执行器重连增加了抖动。

也就是说，旧版本在服务端过载时更容易直接失败。升级后遇到同样的报错，客户端会按服务端给的间隔重试，而不是立刻放弃。升级方式按你的安装途径（npm、包管理器等）操作，具体命令以官方文档为准。升级后用 `codex --version` 确认版本不低于 0.162.0。

## 官方有没有说加了算力？

我在官方状态页和更新日志中没有找到关于"增加算力"或"自动会话恢复"的明确表述。社交媒体 X 上有帖子称，相关负责人在 10 月 15 日前后宣布增加算力并加入自动会话恢复，目的是减少 "Selected model is at capacity" 报错。这一说法只有该来源，我没能在官方渠道核实，请当作未经证实的信息。更新日志里能确认的只有上一节提到的重试与恢复改动。

## 报错期间可以怎么做？

- 不要连续手动重试。短时间内大量请求只会增加排队，新版 CLI 本身会按服务端建议退避。
- 长任务中断后，用 CLI 的恢复会话功能继续，而不是重头开始，具体子命令以官方文档为准。
- 换时间段再试，具体恢复时间看状态页每起事件的更新。
- remote control 用户在 10 月 3 日事件后可能需要重新配对手机。
- 如果自己的连接慢但服务正常，用 [/](/) 测一下到各家 API 的首次连接和往返，再对照[AI API 延迟拆解](/blog/api-latency-connect-rtt-ttft)看慢在哪一段。

## 想持续跟踪怎么办？

- 官方改动：看 [/changes](/changes) 里的 Codex 日志，逐行记录增删，带 RSS。
- 额度问题：与容量报错不同，额度用尽的提示需要另行处理，见[Codex 额度怎么算](/blog/codex-plans-usage-limits-explained)和[Codex 额度重置时间线](/blog/codex-usage-limit-reset-timeline)。
- 自定义接口地址的配置方法见[Claude Code 自定义 API 与 Codex、OpenCode 接口地址配置](/blog/configure-custom-api-endpoint-claude-code-codex)。

## 参考来源

- [OpenAI 状态页事件历史](https://status.openai.com/history)，核对于 2026 年 10 月 17 日
- [ChatGPT 更新日志（Codex CLI 0.161.0、0.162.0）](https://learn.chatgpt.com/docs/changelog)，核对于 2026 年 10 月 17 日