# Codex Selected model is at capacity 怎么解决：不是额度用完 > Codex 报 Selected model is at capacity，指服务端模型容量不足，不是额度用完或限流，额度充足也会出现。查日志确认后再等待、换模型或开新线程。 - URL: https://blog.laozhang.ai/zh/posts/codex-selected-model-at-capacity - Published: 2026-10-15 - Updated: 2026-10-15 - Author: LaoZhang AI Team (https://blog.laozhang.ai/zh/about) - Topic: 故障排查 - Tags: Codex, Selected model is at capacity, server_overloaded, 报错排查, OpenAI --- Codex 的一个回合停在这一行： ```text Selected model is at capacity. Please try a different model. ``` 中文意思是"所选模型已达容量上限，请尝试其他模型"。它说的是 OpenAI 那边承载这个模型的容量暂时不够，不是你的额度用完，也不是针对你账号的限流。如果服务器是用 HTTP 503 拒绝的，Codex 在显示这句之前已经自动重试过几次。先别改密码、删 `~/.codex` 或重装，按下面的顺序处理： 1. 用会话日志确认记录的是 `server_overloaded`，排除别的报错。 2. 看一眼 OpenAI 状态页。有进行中的 Codex 事件就等它恢复；没有事件时，可以在自己的模型列表里换一个模型，或者把长对话开成新线程再试。 3. 换模型、开新线程都不行，状态页又一切正常，就别再一遍遍手动重发了，带着日志里的信息去报告。 用中转站或自定义 provider 的话，还要先确认这句是不是中转返回的，见后面单独一节。 ## Codex 容量报错什么意思：服务端模型容量不足，不是额度用完 这句话在 Codex 源码里对应一个固定的错误类型。截至 2026 年 10 月 15 日，[Codex rust-v0.162.1 的 error.rs](https://github.com/openai/codex/blob/rust-v0.162.1/codex-rs/protocol/src/error.rs) 把 `ServerOverloaded` 显示成上面这句英文，会话日志里记作 `codex_error_info: "server_overloaded"`。触发它的只有两种服务器响应： - HTTP 503，响应体里的 `error.code` 是 `server_is_overloaded`； - 回复流已经开始输出，中途收到一个 `response.failed` 事件，错误码同样是 `server_is_overloaded`。 `server_is_overloaded` 这个码在 [OpenAI API 错误码指南](https://developers.openai.com/api/docs/guides/error-codes)里也有，原因写的是"The requested model is temporarily overloaded"（请求的模型暂时过载）。指南把它和两种 429 分开列：请求速率涨得太快的 `slow_down`，以及达到速率上限。也就是说，服务器发这个码时说的是"模型忙"，不是"你请求太多"。 OpenAI 的 Codex 维护者在 GitHub 上说过几次。在 [Codex issue #17014](https://github.com/openai/codex/issues/17014) 里的原话是："This isn't a rate limiting message — that is, it's not specific to your account."（这不是限流提示，也就是说，它不是针对你账号的。）在 [Codex issue #19583](https://github.com/openai/codex/issues/19583) 里，他说这条消息意味着"we are running low on capacity to serve this model in your region"。这里的 region 是服务区域、数据中心，不是你所在的国家，所以换 VPN 节点不对症，后面会细说。 所以屏幕上剩余额度还很多、`/status` 显示一切正常的时候，照样可能碰到这句，两者并不矛盾。 几种容易混在一起的报错，按屏幕原文分开： | 你看到的 | 实际是什么 | 去哪处理 | | --- | --- | --- | | `Selected model is at capacity. Please try a different model.`，日志里是 `server_overloaded` | 服务端这个模型容量不足，Codex 已重试过 | 本文 | | `exceeded retry limit, last status: 429`，没有别的说明 | 429 重试次数用尽，和容量报错是两条分支 | [Codex exceeded retry limit 429、401 与 Stream Disconnected 排查](https://blog.laozhang.ai/zh/posts/codex-exceeded-retry-limit-429) | | 提示达到使用上限（usage limit） | 额度真的用完了，要等重置 | [Codex 每周限额什么时候重置](https://blog.laozhang.ai/zh/posts/openai-codex-usage-limits)；Plus 用户另见 [ChatGPT Plus 的 Codex 额度：5 小时估算、周限制与 credits](https://blog.laozhang.ai/zh/posts/chatgpt-plus-codex-weekly-limit-credits) | | 提示模型不存在或不可用 | 模型已退役或你的套餐不提供 | [Codex 提示 GPT-5.5 模型不存在？按套餐换模型](https://blog.laozhang.ai/zh/posts/codex-gpt-5-5-model-not-found) | | `unexpected status 503` 后面跟着别的内容 | 也是 503，但响应体不是 `server_is_overloaded`，不会显示成容量报错 | 先看状态页；用中转的看中转日志 | ## Codex 报错前已自动重试：本地复现是 5 次请求、约 4 秒 很多人看到这句就马上手动重发。其实 Codex 在打印它之前，已经对 HTTP 503 过载自动重试过了；只有回复流中途失败的情况，它不会重试。 这一点可以从源码看出来，也做了一次本地复现：用 ChatGPT 桌面版自带的 `codex-cli 0.162.0-alpha.17.2`，在隔离的 `CODEX_HOME` 里配一个自定义 provider，指向一个本地 mock 服务器，让它按三种方式返回过载，重试参数保持默认，每种情况跑一次 `codex exec`： | 情况 | mock 返回 | Codex 发出的请求 | 用时 | 屏幕上看到 | | --- | --- | --- | --- | --- | | HTTP 503，无 Retry-After | 503 + `server_is_overloaded` | 5 次，间隔 0.21 / 0.42 / 0.76 / 1.72 秒 | 约 4 秒 | 直接出现容量报错，没有任何 Reconnecting 提示 | | HTTP 503，带 `Retry-After: 2` | 同上，加响应头 | 30 次，每次间隔 2.0 秒 | 58 秒 | `Reconnecting... 1/5` 到 `5/5`，然后容量报错 | | 流中途失败 | HTTP 200，流里出现 `response.failed` | 1 次 | 不到 1 秒 | 立即出现容量报错 | 三种情况的退出码都是 1，所有请求带的都是同一个模型名，Codex 没有自己换模型。 这张表对排查有三点用处： - 没看到任何 Reconnecting 提示就出现这句，要么是 Codex 已经在几秒内对 503 重试过几次，要么是回复流中途失败、按设计不重试。两种情况下立刻手动重发，碰到的多半还是同一波容量不足。 - 只有服务器给了 `Retry-After`，Codex 才会把整个回合按服务器建议的间隔重来，这时你会看到 `Reconnecting... 1/5` 这类提示。源码的测试 `sse_overload_with_retry_after_is_terminal` 也写明，流中途的过载即使带了重试建议，也直接结束这个回合。 - Codex 客户端不会悄悄把你的模型换成别的。服务端会不会这样做，公开资料里没有说明。 ![本地 mock 复现中 Codex 对三种过载响应的重试次数、用时和屏幕显示对比](https://blog.laozhang.ai/posts/zh/codex-selected-model-at-capacity/img/codex-retry-before-error.webp) 这次复现的边界：只跑了一个 CLI 版本的 `codex exec`，对面是 mock 服务器，不是 OpenAI 的真实后端，也没走 ChatGPT 登录。它说明的是 Codex 收到这种响应之后怎么处理，说明不了 OpenAI 为什么会发这种响应。桌面版和 IDE 插件没有单独测。 ## 两种失败形态：几秒内被拒，或工作 14–34 分钟后中断 真实环境里，这句话出现的时机分两种，处理办法也不同。 一台用 ChatGPT 登录的 Mac 上，Codex 会话日志里共有 17 个回合以这句结束，模型都是 `gpt-6.1-sol`，时间在 2026 年 10 月 3 日到 8 日之间，其中 15 个在 10 月 8 日（UTC）： - **4 个在 6–17 秒内失败**，模型一个字都没输出，看起来就是请求被直接拒绝。 - **13 个已经开始输出**，其中 12 个跑了 14–34 分钟、1 个跑了约 67 秒，才突然中断。长任务做到一半，这一回合的结果没了，日志里 `last_agent_message` 是 `null`。 ![17 个以容量报错结束的 Codex 回合：4 个几秒内被拒，13 个开始输出后中断，以及重跑前要查看的改动](https://blog.laozhang.ai/posts/zh/codex-selected-model-at-capacity/img/codex-capacity-failure-shapes.webp) [Codex issue #53531](https://github.com/openai/codex/issues/53531) 的报告者统计到的情况类似：10 月 8 日到 13 日共 97 个失败回合，其中 56 个发生在模型已经输出、工具已经运行之后，同一回合里的下一次请求被拒。[Codex issue #53648](https://github.com/openai/codex/issues/53648) 报告 `GPT-6.1 Sol` 连续三个回合都在工作 9–18 分钟后失败，其中一次是容量报错，另外两次是回复流中断。 中途中断的回合，工具可能已经改过文件。重跑之前先在项目里看一眼： ```bash git status --short git diff --stat ``` 确认哪些改动已经落地，再决定是让 Codex 接着做，还是先撤回。维护者在 [Codex issue #26290](https://github.com/openai/codex/issues/26290) 里说明过，这类容量错误不会写进模型看到的对话内容，错误消失后会话可以完全恢复，所以不需要为了"清掉错误"删除会话。 这批日志的边界也要说清楚：只有一个账号、一台机器，大多是自动化任务。10 月 8 日的失败里有 11 个来自一小时内并发启动的单回合任务；同一台机器上一个长时间交互的会话，221 个回合里有 202 个正常完成。它能说明失败形态，不能说明原因或者被分到了哪个区域。 ## 先确认是哪一种：会话日志里的 server_overloaded 屏幕上的英文句子可能被中转改写，也可能被你记混，日志里的 `codex_error_info` 更可靠。Codex 的会话记录默认在 `~/.codex/sessions/年/月/日/rollout-*.jsonl`（设置过 `CODEX_HOME` 的，在那个目录下的 `sessions`）。 macOS 或 Linux 下，列出碰到过这个错误的会话文件，最新的排在最后： ```bash grep -rl "server_overloaded" ~/.codex/sessions | sort | tail -5 ``` 统计出现了多少次、错误文本是什么： ```bash grep -rh "server_overloaded" ~/.codex/sessions | grep -o '"error":{[^}]*}' | sort | uniq -c ``` 输出类似下面这样，就是本文说的容量报错： ```text 17 "error":{"message":"Selected model is at capacity. Please try a different model.","codex_error_info":"server_overloaded"} ``` Windows 的会话目录是 `%USERPROFILE%\.codex\sessions`。下面这条 PowerShell 命令是等价写法，没有在 Windows 上实测过： ```powershell Get-ChildItem -Recurse "$env:USERPROFILE\.codex\sessions" -Filter *.jsonl | Select-String -Pattern "server_overloaded" -List | Select-Object Path ``` 判断方法： - 有命中，而且时间对得上，就是服务端容量问题，继续看下一节。 - 没有命中，屏幕上却是 429、额度或模型不存在的提示，回到上面的对照表，去对应的页面处理。 - 顺手在 Codex 里输入 `/status` 和 `/usage`，看看当前会话配置和账号用量，排除额度问题。 ## Selected model is at capacity 怎么解决：等待、换模型、新线程 这几步都可以撤销，从代价最低的开始。 ### 先看 OpenAI 状态页，有 Codex 事件就等 打开 [OpenAI 状态页](https://status.openai.com/)，看 Codex 相关组件有没有进行中的事件。2026 年 10 月 13 日有一次"Degraded performance in GPT-6.1 Sol Codex and Work mode"，影响 CLI、VS Code 插件、Codex API 和 Codex Web；10 月 14 日又有一次"Degraded performance in Codex and ChatGPT Work"，影响桌面版里的 Codex。两次都已标为恢复，事件说明里没有直接提到这句报错，但同期 GitHub 上集中出现了 20 多个以这句为标题的 issue。 状态页没有事件，不代表不会碰到。10 月 8 日状态页没有 Codex 事件，上面那台 Mac 的失败却集中在那天，UTC 14 点到 15 点那一波持续了大约一小时。 要等多久，OpenAI 没有公布过。已恢复的事件一般在几个小时内结束；也有用户在 [Codex issue #53952](https://github.com/openai/codex/issues/53952) 里报告，公开事件恢复之后自己仍连续失败了 7 小时 41 分钟，77 次全是 `server_overloaded`。 ### 在自己的模型列表里换一个模型 报错本身就是建议你换模型。容量是按模型算的，这个模型忙，另一个不一定忙。 - CLI：输入 `/model`，从列表里选模型和推理强度；只想这一次换，可以启动时加 `-m`，比如 `codex -m gpt-6-sol`；想改默认值，改 `config.toml` 里的 `model = "..."`。 - 桌面版和 IDE 插件：用对话框里的模型选择器。 只从你自己列表里出现的模型中选。这个列表是从服务器拉取的，不同套餐不一样：截至 2026 年 10 月 15 日，ChatGPT 登录下 Plus、Pro、Business、Enterprise、Edu 有 `gpt-6-sol`，Free 和 Go 用 `gpt-6-luna`，`gpt-6.1-sol` 正在向 Plus 及以上推出，`gpt-5.6-sol`、`gpt-5.6-terra`、`gpt-5.6-luna` 仍在列表里。用 ChatGPT 登录的话不要去选 `gpt-5.5` 或 `gpt-5.4`，它们已经不再对 ChatGPT 登录提供，选了只会换来"模型不存在"。 换模型不一定有用，两种报告都有。[Codex issue #43738](https://github.com/openai/codex/issues/43738) 汇总了 2026 年 9 月 8 日 GPT-6 Astra 发布后的一波报告，很多人选任何模型都失败；#53531 的报告者换了 4 个模型也一样。换一次模型，跑一个短回合，还是失败就别再挨个试下去了。 ### 长对话开新线程，或者 compact、fork [Codex issue #53524](https://github.com/openai/codex/issues/53524) 的报告者用 Windows 桌面版，继续一个很长的旧对话时反复失败，换了 GPT-6.1 Sol、GPT-5.6 Sol、GPT-6 Sol、GPT-6 Astra 都一样，而"Creating a new chat works immediately"（新建对话立刻就能用）。 所以长对话卡住时，值得试一下： - `/new`：在当前会话里开一个新对话，把任务要点手动带过去； - `/compact`：先把旧对话压缩成摘要，再继续； - `/fork`：从当前对话分出一个副本试。 这是一个测试，不是保证有效的修复。#53952 的报告者新开了一个对话，4 分钟内照样失败了 4 次。新线程能跑通，就先在新线程里把活干完；新线程也失败，说明问题不在这段对话上。 想对比 CLI 和桌面版的表现，可以照 [Codex Windows 应用变慢？先做 CLI 与桌面端路径检查](https://blog.laozhang.ai/zh/posts/codex-app-slow-cli-vs-desktop) 里的方法，用同一个提示在两边各跑一次。 ### 开着 Fast 的话，关掉试一次 支持 Fast 的模型可以切换 Fast 模式。[Codex issue #37790](https://github.com/openai/codex/issues/37790) 里有一位用户说，用 5.6 Sol 的 fast 被限制，关掉 fast 就好了。这只是单个用户的经历，好在关掉随时能再打开，可以当作一次对照测试。 ### 什么时候该停止重试 满足下面三条，继续重发只会浪费时间： - 日志里连续都是 `server_overloaded`； - 换过一次模型、开过一次新线程，仍然失败； - 状态页没有进行中的事件。 这时去写报告。另外，同时跑很多并行任务时，碰上一波容量不足，失败的回合也会一起变多。上面那台 Mac 在 10 月 8 日的失败大多来自并发任务；这不能证明并发是原因，但长任务可以先少开几个，等恢复了再放开。 ## Codex 容量报错是不是账号被风控：没有公开证据 没有公开证据支持"账号被风控、请求被路由进风控池"这类说法。 维护者的说法是这条消息不针对账号（#17014），而是这个模型在你所在的服务区域容量不足（#19583）。也有看起来像是"按账号"的报告：[Codex issue #46103](https://github.com/openai/codex/issues/46103) 里，同一台机器、同一网络、同一模型，Plus 账号 11 次全部失败，Free 账号 11 次全部成功。维护者对此的回复是："I suspect this is because your two sessions were routed to different regions (data centers)."（我怀疑是两个会话被路由到了不同的区域，也就是不同的数据中心。）这只是推测，不是确认，但它说明不同会话可能落到不同的数据中心。这和"账号被风控"是两回事。 几种流传的"修复办法"，都没有依据： - **改密码、重开两步验证、退出所有设备后静置几小时到 48 小时**：#53531 的报告者改过密码、开了两步验证、退出又重新登录，还分别等了 1 小时、5 小时、24 小时，都没用。 - **换 VPN 节点或出口 IP**：#53524 的报告者试过美国、日本、新加坡线路，#53531 的报告者换了美国住宅出口 IP，都没用。维护者说的 region 是数据中心，你的出口在哪个国家改变不了它。 - **删除配置目录、重装 Codex**：删 `~/.codex` 或重装都不对症，这句报错来自服务器响应，本地配置没有坏；删掉目录还会把可用来排查的会话日志一起删了。 ## 用中转或自定义 provider：这句可能来自中转站 通过 API Key、自定义 provider 或第三方中转用 Codex 时，Codex 解析的 503 或流事件，来自你配置的那个 Base URL，不是直接来自 OpenAI。只要中转返回的错误码是 `server_is_overloaded`，Codex 就会显示同一句话。这句话可能是中转原样透传了上游的过载，也可能是中转自己的上游账号池或排队满了，自己生成的。后一种情况下，OpenAI 状态页和 GitHub issue 都不会有任何记录。 分辨方法： - 看中转的控制台或请求日志，失败的那一刻它记的是什么。 - 用 ChatGPT 登录或者 OpenAI 官方 API Key，跑一个短回合做对照。官方路线正常而中转失败，问题出在中转这一侧，要找中转方处理。 - 核对自己的 provider 配置，Base URL、`wire_api` 怎么写，见 [Codex 自定义 API 配置：Key、Base URL 与 Provider 怎么选](https://blog.laozhang.ai/zh/posts/codex-config-toml)。 有些中转会把这个错误改写成别的错误，让 Codex 当成可重试的错误自动多试几次。这是第三方的做法，Codex 本身不这样处理。改写之后，你在屏幕上再也看不到真实原因，请求次数还会成倍增加。 ## Reviewer model is at capacity 与 remote compact 报错 这两种写法都是同一类容量问题，只是出现在 Codex 的不同环节： - **Reviewer model is at capacity**：社区里有人报告这种写法，出现时会挡住代码修改。它来自自动审查（auto-review）用的审查模型。v0.162.1 的审查模块碰到 `ServerOverloaded` 会自己重试审查；这句报错的确切文本在 v0.162.1 源码里没有找到，按用户报告的说法记录。处理方法和主报错一样，先等待；一直出现的话，报告时说明失败发生在审查环节。 - **Error running remote compact task: Selected model is at capacity**：这是旧版本在远程压缩对话时碰到的容量错误。维护者在 [Codex issue #28303](https://github.com/openai/codex/issues/28303) 里说，Codex 已经把压缩改到本地，走和普通回合相同的接口，消除了远程压缩出错的问题。还看到这句的话，先把 Codex 升到最新版本。 ## 向 OpenAI 报告 server_overloaded 时带上这些信息 确实要报告时，在 Codex 里用 `/feedback` 把日志发给维护者，或者到 [OpenAI Codex 的 GitHub issues](https://github.com/openai/codex/issues) 提交。带上这些信息，比只贴一句报错更容易被定位： - 使用方式和版本：CLI（`codex --version`）、桌面版或 IDE 插件的版本号； - 登录方式和套餐：ChatGPT 登录、API Key 还是自定义 provider； - 模型和推理强度，是否开着 Fast； - 失败时间（写明 UTC 或时区），会话或线程 ID； - 日志里的 `codex_error_info` 和出现次数（用上面的统计命令）； - 是几秒内失败，还是工作了一段时间才中断； - 换模型、开新线程各试过没有，结果如何； - 当时状态页有没有 Codex 事件。 不要贴提示词、代码或密钥。会话文件里有完整的对话内容，只摘 `error` 那一段。 ## Codex 容量报错的其他问题 ### Codex 报 Selected model is at capacity，要多久才能恢复？ OpenAI 没有公布过恢复时长。状态页上已恢复的 Codex 事件一般持续几个小时；10 月 8 日那台 Mac 碰到的一波持续了大约一小时；也有用户报告连续失败了 7 小时 41 分钟。与其干等，不如先换模型、开新线程各试一次。 ### 额度还剩很多，Codex 为什么还报这句？ 因为它和额度无关。额度用完有单独的提示；这句来自服务器返回的 `server_is_overloaded`，意思是这个模型此刻在服务端容量不足。#53531、#53952 的报告者都是在每周额度剩下大半时碰到的。 ### 中转站能不能让 Codex 自动重试这个错误？ Codex 本来就会对 HTTP 503 过载自动重试，一般看到这句时已经重试过了；回复流中途的过载按设计不重试。中转把错误改写成别的类型、让客户端多试几次，会掩盖真实原因、增加请求次数，问题如果出在中转的上游，这样做也解决不了。 ## 参考来源 本文引用的外部页面，按正文出现顺序排列。最后更新于 2026-10-15。 - [Codex rust-v0.162.1 的 error.rs](https://github.com/openai/codex/blob/rust-v0.162.1/codex-rs/protocol/src/error.rs) (github.com) - [OpenAI API 错误码指南](https://developers.openai.com/api/docs/guides/error-codes) (developers.openai.com) - [Codex issue #17014](https://github.com/openai/codex/issues/17014) (github.com) - [Codex issue #19583](https://github.com/openai/codex/issues/19583) (github.com) - [Codex issue #53531](https://github.com/openai/codex/issues/53531) (github.com) - [Codex issue #53648](https://github.com/openai/codex/issues/53648) (github.com) - [Codex issue #26290](https://github.com/openai/codex/issues/26290) (github.com) - [OpenAI 状态页](https://status.openai.com/) (status.openai.com) - [Codex issue #53952](https://github.com/openai/codex/issues/53952) (github.com) - [Codex issue #43738](https://github.com/openai/codex/issues/43738) (github.com) - [Codex issue #53524](https://github.com/openai/codex/issues/53524) (github.com) - [Codex issue #37790](https://github.com/openai/codex/issues/37790) (github.com) - [Codex issue #46103](https://github.com/openai/codex/issues/46103) (github.com) - [Codex issue #28303](https://github.com/openai/codex/issues/28303) (github.com) - [OpenAI Codex 的 GitHub issues](https://github.com/openai/codex/issues) (github.com)