Codex: Selected model is at capacity. 模型容量已满排查

这个错误是什么意思

Selected model is at capacity. Please try a different model. 的重点是 selected model。请求没有优先失败在认证层，而是当前选中的模型、模型分组或上游路由没有足够可用容量。

如果你使用的是官方 Codex 登录态，它可能是 OpenAI 侧模型容量高峰。如果你通过中转站、Sub2API、CPA、NewAPI 或团队网关接入，它也可能是中转站背后的账号池、模型映射或分组路由没有可用出口。

别把它粗暴理解成“Codex 坏了”。更准确的判断是：当前模型通道暂时调度不到资源。

社区已有不少同类反馈：即使 /status 里还有上下文和额度，也可能触发这个提示。先把它当作模型容量或路由调度问题，不要第一反应就改 API Key 或查余额。

在一些 Sub2API 场景里，用户观察到上游原始失败更接近 Our servers are currently overloaded，中间层再把错误透传成 Codex 里的 at capacity 提示。问题不只是失败本身，而是 Codex 收到这类提示后可能不会自动续跑，于是长任务被频繁打断。

常见原因

1. 当前 Codex 模型处在高峰期，尤其是平台推荐迁移到新模型后，新模型更容易出现临时 Admission 失败。
2. gpt-5.4、gpt-5.3-codex 这类 Codex 相关模型可能有独立容量池，剩余额度不等于当前模型一定能调度成功。
3. 同一个模型在 ChatGPT 普通对话里可用，但 Codex 的连接被拒，说明 Codex 可能走不同的 Admission、工具调用或模型路由。
4. 中转站把你选的模型映射到一个已满载、限流或冷却中的上游账号池。
5. SSE 流式请求中途断开，客户端把上游 overloaded 或 stream 失败展示成 at capacity。
6. 同一个账号、同一个 Key 或同一个 provider 同时跑多个 Codex 会话，挤占了可用容量。

先判断你属于哪种场景

如果你用的是官方 ChatGPT 登录态，先换模型测试：从 gpt-5.4 切回 gpt-5.3-codex，或等几分钟后重试。不要先改 Key。

如果你用的是中转站、Sub2API、CPA 或 NewAPI，先用同一 Base URL、Key、模型名发最小请求，再换模型。最小请求也失败，看账号池和上游容量；只有长任务失败，再看上下文、流式输出和工具调用。

怎么快速处理

1. 先换模型。优先从 gpt-5.4 切回 gpt-5.3-codex 或另一个稳定模型，确认是不是单模型容量问题。
2. 等 1 到 5 分钟再重试。容量类错误通常是临时状态，立刻连续重试意义不大。
3. 降低当前任务的上下文压力：新开会话、减少附带文件、缩小修改范围，或先让 Codex 处理更小的步骤。
4. 如果你使用 Codex 的 /goal 能力，可以把目标拆清楚，让客户端在中断后更容易续跑。但这只是降低人工接管成本，不是解决上游容量。
5. 如果你使用中转站，切换模型分组、备用线路或 provider，并让服务商确认这个模型是否真的有可调度账号。

Sub2API 里的缓解办法

如果你自建或管理 Sub2API，可以尝试在账号管理里的错误透传规则中，把包含 Our servers are currently overloaded 或 at capacity 的上游错误改写成客户端会触发自动重试的错误文本，例如 upstream failed。

常见配置思路是：错误码保持空，关键词填 Our servers are currently overloaded、at capacity，匹配模式选择“错误码或关键词”，自定义错误信息填 upstream failed 或类似可重试文本。

这个做法的价值是降低长任务被中断的频率，不是让模型容量凭空变多。重试次数必须有上限，并且要观察消耗、失败率和是否进入循环。把所有 capacity 错误都吞掉，只会让你看不见真实容量问题，还可能把余额烧在无效重试上。

NewAPI 场景要更谨慎。社区反馈里提到 NewAPI 更常见的是状态码覆写，不一定能像 Sub2API 一样精细改写这类上游错误文本。不要为了追求自动重试，把所有错误都改成同一个可重试错误。