Selected model is at capacity
这个提示通常表示当前选中的 Codex 模型或模型路由暂时没有可用容量。它不优先指向 API Key 写错，也不一定是本地配置坏了；先换模型、等待恢复或让中转站确认模型通道容量。
错误摘要
报错：Selected model is at capacity. Please try a different model. 先把它当作模型级容量或路由拥塞处理：换模型、等待一段时间、降低上下文，使用中转站时让服务商确认账号池和模型分组。
这个错误是什么意思
Selected model is at capacity. Please try a different model. 的重点是 selected model。请求没有优先失败在认证层，而是当前选中的模型、模型分组或上游路由没有足够可用容量。
如果你使用的是官方 Codex 登录态，它可能是 OpenAI 侧模型容量高峰。如果你通过中转站、Sub2API、CPA、NewAPI 或团队网关接入，它也可能是中转站背后的账号池、模型映射或分组路由没有可用出口。
别把它粗暴理解成“Codex 坏了”。更准确的判断是：当前模型通道暂时调度不到资源。
OpenAI Developer Community 在 2026-04-23 已有同类报告：用户提到使用 gpt-5.4 时持续出现这个提示，后续也有人反馈 Codex Desktop macOS / Windows 的长时间工作流会被突然打断。这个现象更像 Codex 客户端、模型容量和流式稳定性叠加出来的问题，不是标准 HTTP 429。
在一些 Sub2API 场景里，用户观察到上游原始失败更接近 Our servers are currently overloaded，中间层再把错误透传成 Codex 里的 at capacity 提示。问题不只是失败本身，而是 Codex 收到这类提示后可能不会自动续跑，于是长任务被频繁打断。
常见原因
- 当前 Codex 模型处在高峰期，服务端建议切换到其他模型。
- 中转站把你选的模型映射到一个已满载、限流或冷却中的上游账号池。
- API Key 所在分组没有可用的 Codex 模型供应商，或该模型只对部分套餐开放。
- 当前任务上下文太长、工具调用太多，导致高成本模型更容易被容量限制拦住。
- 同一个账号、同一个 Key 或同一个 provider 同时跑多个 Codex 会话，挤占了可用容量。
怎么快速处理
- 先换一个可用模型。不要死磕同一个高峰模型，尤其是 Codex 专用模型、pro 模型或高 reasoning 档位。
- 等 1 到 5 分钟再重试。容量类错误通常是临时状态，立刻连续重试意义不大。
- 降低当前任务的上下文压力：新开会话、减少附带文件、缩小修改范围，或先让 Codex 处理更小的步骤。
- 如果你使用中转站，切换模型分组、备用线路或 provider，并让服务商确认这个模型是否真的有可调度账号。
- 如果你使用官方 Codex App 或 VS Code extension，保留截图、时间、模型名和 request id，再通过 Codex 的反馈入口或 GitHub issue 报告。
- 如果所有模型都失败，再检查 OpenAI 状态页、中转站状态页、余额、套餐权限和 Base URL 配置。
Sub2API 里的缓解办法
如果你自建或管理 Sub2API，可以尝试在账号管理里的错误透传规则中，把包含 Our servers are currently overloaded 或 at capacity 的上游错误改写成客户端会触发自动重试的错误文本，例如 upstream failed。
这个做法的价值是降低长任务被中断的频率，不是让模型容量凭空变多。重试次数必须有上限，并且要观察消耗、失败率和是否进入循环。把所有 capacity 错误都吞掉，只会让你看不见真实容量问题，还可能把余额烧在无效重试上。
和 429、503 有什么区别
429 更偏向请求频率、额度或限流；503 更偏向服务不可用或账号池没有可用出口。
Selected model is at capacity 不是 429。它更具体地指向“当前选中的模型或上游模型路由没有容量”，有时底层表现是上游 overloaded 或流式请求中断。所以第一反应应该是换模型、换模型路由或做有上限的自动重试，而不是先改 API Key、重装 Codex，或者盲目迁移整个 provider。
这里有个容易自欺的点：如果你在用中转站，这个提示不一定证明官方 Codex 不稳定，也可能只是你的中转站把热门模型卖超了。先做最小请求和换模型测试，再判断是不是 provider 层面的容量问题。