codex selected model is at capacity 是什么意思：不是用量上限，按顺序试 6 种解决办法

Codex 里的“Selected model is at capacity”是什么意思？

意思是 OpenAI 为你选的那个模型准备的服务器不够用了，你的账号本身没有问题。Codex 显示这行字，来自其开源代码里的一个错误，即 codex-rs/protocol/src/error.rs 中的 ServerOverloaded；而用量上限是另一个错误，措辞也不同。把你看到的提示对照下表，这张表是我们 2026 年 10 月 18 日根据那个文件整理的：

区分的关键是两个词。个人上限的提示一定写“usage limit”，工作区上限则写“credits”或“spend cap”。容量提示里一个都没有，而且从不给出时间，因为你的账号没有任何变化。OpenAI 的 etraut-openai 账号负责在 GitHub 上回复 Codex 的问题，他在 2026 年 5 月 12 日说得很明白：“If you receive this message, it does not mean that you are being rate limited or are out of usage. It means that we are running low on capacity to serve this model in your region.”

OpenAI 的 API 把同类的资源短缺报告为 HTTP 503 server_is_overloaded。它的错误码指南给出的原因是“The requested model is temporarily overloaded.”有用户报告在桌面应用、CLI、VS Code 扩展以及 ChatGPT 桌面应用内的 Codex 中都出现过这行提示，ChatGPT 本身也出现过一次。2026 年 7 月 9 日，OpenAI 发布了一起事故，称用户“across multiple models”遇到该提示，来自状态订阅源的 Pulsetic 副本。

Codex 的容量问题会持续多久？

单次容量错误通常几分钟内就会消失，状态页公布的最糟糕的几天也在 3.4 小时内结束。我们在 2026 年 10 月 18 日查看了 OpenAI 的状态历史。有三起事故标记了容量问题：6 月 16 日的 "Codex 'Selected Model is at Capacity' Error"，持续 196 分钟；7 月 9 日的模型选择事故，持续 58 分钟；以及 7 月 17 日的 "Codex 5.6-sol Experiencing Increased Server-Overload Errors"，持续 203 分钟。此后再没有标记过。

论坛上的情况更长。用户在 6 月 15 和 16 日、7 月 28 到 30 日、9 月 7 到 10 日和 10 月 3 到 12 日集中发帖报告这个错误。后三波没有任何容量公告。9 月那一波里，唯一提到 Codex 的状态说明，是一起 25 分钟、关于 "unexpected usage limit resets" 的事故。7 月有位发帖者称 GPT-5.6 Sol 在 48 小时以上的时间里“almost continuously unavailable”。状态页是绿色，并不代表 Codex 没问题。

2026 年 8 月 1 日到 10 月 16 日，OpenAI 状态页上标题含 Codex 的事故有 13 起。它们持续 54 到 506 分钟，中位数为 95 分钟，其中四起超过三小时。我们按 OpenAI 首次发布更新到发布恢复通知之间的时间计算分钟数。历史页面从 7 月 20 日才开始，所以 6 月和 7 月的容量事故是我们搜索找到的，7 月 9 日那起来自 Pulsetic 的镜像。

怎样按顺序解决“Selected model is at capacity”？

先重试一次，再切换模型，然后开一个新对话。在你看到这行提示之前，Codex 已经重试过了。它的配置参考默认对失败的请求重试 4 次，对中断的数据流重试 5 次。再按十次回车也没多大用处。

1. 保存好提示词。 刷新任何东西之前先复制下来。有用户报告，在进行中的会话里，在同一个对话中输入“continue”常常能让任务接着做下去。
2. 一分钟后重试一次。 短暂的高峰会自行消退，重试一次就能知道是不是偶发。
3. 切换模型。 在 CLI 中运行 /model，或用 codex -m gpt-6-luna 启动。在桌面应用和 ChatGPT Work 中，使用输入框下方的模型控件。GPT-5.5 已于 2026 年 10 月 14 日从使用 ChatGPT 登录的 Codex 中下线，所以它不再是备选。
4. 用同一个模型开一个新对话。 OpenAI 员工 10 月在论坛里建议过这样做。运行 /new，或先运行 /compact 把摘要带过去。
5. 查看 status.openai.com，再看 /status。 有点名 Codex 的事故就等一等。状态页干净、你的用量也还有余量，说明短缺出在你的模型和地区。
6. 提交反馈。 在出问题的对话中运行 /feedback，并记下时间和你的时区，这正是 OpenAI 员工要求的。如果 /feedback 本身也失败，员工建议改为提交支持工单。

有些办法没有用。重装 Codex、删除 ~/.codex 或购买额度，都不会增加服务器。9 月有位发帖者试了 3 个地区的 4 个 IP 地址，都没用。如果所有模型都失败，OpenAI 在 9 月 25 日故障期间自己的建议是 "Login via API key will unblock access at this time." API 密钥会话按标准 API 价格计费，见 OpenAI 的 Codex 定价页，所以这条路留给真正的截止日期。

容量错误会消耗你的 Codex 用量上限吗？

不会。容量提示不是用量上限，OpenAI 的工程师也说它并不表示你“out of usage”。你十秒钟就能验证：在进行中的 CLI 会话里运行 /status，会显示当前模型和你的用量；网页上的 chatgpt.com/codex/settings/usage 显示同一个计量。如果计量还有余量而错误依旧，那就是容量问题。OpenAI 没有说过中途失败的一轮是否计入用量。

用量上限按它自己的时钟运行。OpenAI 的 Codex 定价页（2026 年 10 月 18 日查看）估计，Plus 和 Standard Business 在 GPT-6.1 Sol 上每五小时 15 到 160 条本地消息。GPT-6 Astra 为 5 到 45 条，GPT-6 Luna 为 350 到 3,000 条，并补充说："Pro plans currently have no five-hour limit." 此外可能还有每周限制。所以在 Pro 上，一堵从不写“usage limit”的墙就是容量问题，不是每周上限。Codex 用量上限列出了各套餐的窗口，以及它的上限提示给出的选项。

Codex 的第三种相似提示是“rate limit exceeded”，意思是请求发得太快。它与容量提示不同，针对的是你自己的请求频率，所以放慢一分钟，在同一个模型上就能恢复。

为什么付费套餐的 Codex 也会遇到容量问题？

因为套餐买到的是额度，而不是预留的服务器，OpenAI 按模型和地区来分配容量。报告往往集中在新模型发布前后。发帖者把 9 月那一波与 GPT-6 Astra 的发布联系起来。许多人用的是 Pro 20x 账号，也有人说同一时间 Pro 5x 账号一直能用。10 月有位发帖者把错误追溯到一个以对话命名的后台 GPT-6 Luna 请求。员工回复说，他们“can't confirm the background Luna explanation from the thread alone.”

真正的解决办法在 OpenAI 手里。2026 年 10 月 15 日，其员工在论坛写道："We've added capacity and shipped changes today to reduce these interruptions." 有一个请求，要求 Codex 在遇到容量错误时带退避地重试，即 issue #22390，自 2026 年 5 月 12 日起一直未关闭。在它上线之前，无人值守的任务一旦遇到超过内置重试次数的容量错误就会停下。

Codex 容量不足时可以用什么？

换另一家厂商的模型，处理不需要你代码仓库的那部分工作。关于堆栈跟踪的问题、重构计划或正则表达式，可以在 Codex 等待时交给 Claude 或 Gemini。粘贴一段任务的简短摘要（目标、已经决定的事、失败的地方），然后继续。

发布本页的 Whizi 并不能取代 Codex。它没有开发者 API，也不会接触你的代码仓库。它把 GPT、Claude 和 Gemini 放在同一个对话里：对话中途切换模型，会把整个对话交给新模型（切换如何运作），生成失败也会退款，不会扣费。Claude Sonnet 和 Claude Opus 需要每月 $29.99 的 Pro，所有套餐每小时都限 60 条消息。当短缺出在 OpenAI 一侧时，就选 Claude 或 Gemini 模型。