Codex Selected model is at capacity 怎么解决：不是额度用完

Codex 的一个回合停在这一行：

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 把 ServerOverloaded 显示成上面这句英文，会话日志里记作 codex_error_info: "server_overloaded"。触发它的只有两种服务器响应：

• HTTP 503，响应体里的 error.code 是 server_is_overloaded；
• 回复流已经开始输出，中途收到一个 response.failed 事件，错误码同样是 server_is_overloaded。

server_is_overloaded 这个码在 OpenAI API 错误码指南里也有，原因写的是"The requested model is temporarily overloaded"（请求的模型暂时过载）。指南把它和两种 429 分开列：请求速率涨得太快的 slow_down，以及达到速率上限。也就是说，服务器发这个码时说的是"模型忙"，不是"你请求太多"。

OpenAI 的 Codex 维护者在 GitHub 上说过几次。在 Codex issue #17014 里的原话是："This isn't a rate limiting message — that is, it's not specific to your account."（这不是限流提示，也就是说，它不是针对你账号的。）在 Codex issue #19583 里，他说这条消息意味着"we are running low on capacity to serve this model in your region"。这里的 region 是服务区域、数据中心，不是你所在的国家，所以换 VPN 节点不对症，后面会细说。

所以屏幕上剩余额度还很多、/status 显示一切正常的时候，照样可能碰到这句，两者并不矛盾。

几种容易混在一起的报错，按屏幕原文分开：

Codex 报错前已自动重试：本地复现是 5 次请求、约 4 秒

很多人看到这句就马上手动重发。其实 Codex 在打印它之前，已经对 HTTP 503 过载自动重试过了；只有回复流中途失败的情况，它不会重试。

这一点可以从源码看出来，也做了一次本地复现：用 ChatGPT 桌面版自带的 codex-cli 0.162.0-alpha.17.2，在隔离的 CODEX_HOME 里配一个自定义 provider，指向一个本地 mock 服务器，让它按三种方式返回过载，重试参数保持默认，每种情况跑一次 codex exec：

三种情况的退出码都是 1，所有请求带的都是同一个模型名，Codex 没有自己换模型。

这张表对排查有三点用处：

• 没看到任何 Reconnecting 提示就出现这句，要么是 Codex 已经在几秒内对 503 重试过几次，要么是回复流中途失败、按设计不重试。两种情况下立刻手动重发，碰到的多半还是同一波容量不足。
• 只有服务器给了 Retry-After，Codex 才会把整个回合按服务器建议的间隔重来，这时你会看到 Reconnecting... 1/5 这类提示。源码的测试 sse_overload_with_retry_after_is_terminal 也写明，流中途的过载即使带了重试建议，也直接结束这个回合。
• Codex 客户端不会悄悄把你的模型换成别的。服务端会不会这样做，公开资料里没有说明。

这次复现的边界：只跑了一个 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。

Codex issue #53531 的报告者统计到的情况类似：10 月 8 日到 13 日共 97 个失败回合，其中 56 个发生在模型已经输出、工具已经运行之后，同一回合里的下一次请求被拒。Codex issue #53648 报告 GPT-6.1 Sol 连续三个回合都在工作 9–18 分钟后失败，其中一次是容量报错，另外两次是回复流中断。

中途中断的回合，工具可能已经改过文件。重跑之前先在项目里看一眼：

git status --short
git diff --stat

确认哪些改动已经落地，再决定是让 Codex 接着做，还是先撤回。维护者在 Codex issue #26290 里说明过，这类容量错误不会写进模型看到的对话内容，错误消失后会话可以完全恢复，所以不需要为了"清掉错误"删除会话。

这批日志的边界也要说清楚：只有一个账号、一台机器，大多是自动化任务。10 月 8 日的失败里有 11 个来自一小时内并发启动的单回合任务；同一台机器上一个长时间交互的会话，221 个回合里有 202 个正常完成。它能说明失败形态，不能说明原因或者被分到了哪个区域。

先确认是哪一种：会话日志里的 server_overloaded

屏幕上的英文句子可能被中转改写，也可能被你记混，日志里的 codex_error_info 更可靠。Codex 的会话记录默认在 ~/.codex/sessions/年/月/日/rollout-*.jsonl（设置过 CODEX_HOME 的，在那个目录下的 sessions）。

macOS 或 Linux 下，列出碰到过这个错误的会话文件，最新的排在最后：

grep -rl "server_overloaded" ~/.codex/sessions | sort | tail -5

统计出现了多少次、错误文本是什么：

grep -rh "server_overloaded" ~/.codex/sessions | grep -o '"error":{[^}]*}' | sort | uniq -c

输出类似下面这样，就是本文说的容量报错：

  17 "error":{"message":"Selected model is at capacity. Please try a different model.","codex_error_info":"server_overloaded"}

Windows 的会话目录是 %USERPROFILE%\.codex\sessions。下面这条 PowerShell 命令是等价写法，没有在 Windows 上实测过：

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 状态页，看 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 里报告，公开事件恢复之后自己仍连续失败了 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 汇总了 2026 年 9 月 8 日 GPT-6 Astra 发布后的一波报告，很多人选任何模型都失败；#53531 的报告者换了 4 个模型也一样。换一次模型，跑一个短回合，还是失败就别再挨个试下去了。

长对话开新线程，或者 compact、fork

Codex issue #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 与桌面端路径检查 里的方法，用同一个提示在两边各跑一次。

开着 Fast 的话，关掉试一次

支持 Fast 的模型可以切换 Fast 模式。Codex issue #37790 里有一位用户说，用 5.6 Sol 的 fast 被限制，关掉 fast 就好了。这只是单个用户的经历，好在关掉随时能再打开，可以当作一次对照测试。

什么时候该停止重试

满足下面三条，继续重发只会浪费时间：

• 日志里连续都是 server_overloaded；
• 换过一次模型、开过一次新线程，仍然失败；
• 状态页没有进行中的事件。

这时去写报告。另外，同时跑很多并行任务时，碰上一波容量不足，失败的回合也会一起变多。上面那台 Mac 在 10 月 8 日的失败大多来自并发任务；这不能证明并发是原因，但长任务可以先少开几个，等恢复了再放开。

Codex 容量报错是不是账号被风控：没有公开证据

没有公开证据支持"账号被风控、请求被路由进风控池"这类说法。

维护者的说法是这条消息不针对账号（#17014），而是这个模型在你所在的服务区域容量不足（#19583）。也有看起来像是"按账号"的报告：Codex issue #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 怎么选。

有些中转会把这个错误改写成别的错误，让 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 里说，Codex 已经把压缩改到本地，走和普通回合相同的接口，消除了远程压缩出错的问题。还看到这句的话，先把 Codex 升到最新版本。

向 OpenAI 报告 server_overloaded 时带上这些信息

确实要报告时，在 Codex 里用 /feedback 把日志发给维护者，或者到 OpenAI Codex 的 GitHub 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 过载自动重试，一般看到这句时已经重试过了；回复流中途的过载按设计不重试。中转把错误改写成别的类型、让客户端多试几次，会掩盖真实原因、增加请求次数，问题如果出在中转的上游，这样做也解决不了。