“Selected model is at capacity”：Codex 容量异常排查与恢复说明
Posted August 12, 2026 by YAI 技术团队 ‐ 16 min read
恢复更新（2026 年 8 月 12 日）：OpenAI 状态页已将“API、Codex 和 Work Mode 错误增加”标记为已恢复；今天早上的同行反馈和我们收到的用户反馈，也显示服务正在回到此前的稳定水平。我们仍会继续观察个别账号和区域的表现。
这不是一篇把所有问题都归咎于某一层的声明，而是一份给用户、企业客户和同行的排查记录：过去两周，部分通过 YAI Router 使用 Codex 的用户，反复看到下面这条提示：
Selected model is at capacity. Please try a different model.
它看起来像一句普通的“换个模型再试”，但这次异常持续时间长、出现账号不完全一致，而且同一账号有时成功、有时失败。对依赖 Codex 完成长任务、代码审查和企业自动化的用户来说，这已经不是可以忽略的偶发抖动。
先说结论
我们的结论分成四点：
- 这不是 YAI Router 单方面的故障。 公开报告显示，官方 Codex 客户端和多个兼容入口中也出现了相同现象，官方 issues 和状态记录提供了交叉证据。
- “容量不足”不等于账号被限流、余额不足或订阅失效。 OpenAI Codex 协作者在 issue #19583 中明确说明，这条消息可能表示“所在区域服务该模型的容量不足”，而不是用量耗尽。
- 问题呈现出账号、区域或上游容量池维度的差异。 老账号长期稳定，新开通的一批账号更容易触发；也有用户在同一会话中前后成功。这与简单的全局限流模型不符。
- 我们已经撤回为临时缓解而加入的特殊处理，恢复网关的干净路径。 上游恢复后继续在网关里吞掉或改写这类错误，可能造成重复请求、流式会话破坏和更难排查的隐患。
这里的“上游容量池”是我们的运行判断，不是 OpenAI 对内部调度实现的正式确认。我们无法从外部证明某个账号对应一台具体物理机器，也不会公开完整认证票据、目标 IP 或账户标识。
YAI Router 在这条链路中的位置
YAI 长期主要为企业客户提供稳定可靠的 AI API 服务，覆盖 Codex、Grok 等模型。基于可靠的 API Gateway 底座，我们构建了 yairouter.com，为 C 端用户提供统一的 AI 服务入口。目前服务已经覆盖几十家高校、上百家企业；不少企业客户还在内网或私有云中独立部署了 YAI Router，并长期稳定运行。
因此，这次调查首先要回答的不是“上游偶尔报错是否可能”，而是一个更具体的问题：
为什么同一套网关代码、同一套请求处理逻辑，会在最近新开通的账号上集中出现，而老账号和许多其他用户仍然正常？
为什么这个问题特别难定位
1. 它不是全局故障
很多用户一直没有遇到问题，甚至在同一时间切换到另一个账号就能继续工作。这让我们一度反复检查：
- 模型名、推理强度和请求协议是否有差异；
- WebSocket 与 HTTP 的路径是否行为不同；
- 新机器是否缺少本地缓存或配置；
- API Key、充值状态、套餐和权限是否异常；
- 网关路由、重试、会话粘性是否把请求送错。
经过对比，老账号继续稳定运行；新开通的一批账号即使换了机器、重新发起最小请求，也仍可能收到容量提示。这个现象降低了“本地环境或业务代码差异”的可能性。
2. HTTP 状态码是 200，但语义是错误
本次链路中，我们观察到上游返回的 HTTP 状态码是 200，响应体却表达了模型容量不可用。对网关而言，这意味着：
- 只看 HTTP 状态码的监控会认为请求成功；
- 通用的 4xx/5xx 重试策略不会被触发；
- 必须读取并解析响应体，才能识别真正的业务失败；
- 流式响应、用量统计和客户端状态可能因此产生不同步。
为减少用户侧影响，我们曾临时加入实时检查每一条 200 响应、解析错误语义并做缓解的代码。这能降低一部分表面影响，却不能创造上游算力，反而让热路径变得复杂。确认问题来自上游后，我们选择还原这批临时代码。
3. 账号正常，不代表每个模型路由都可用
充值成功、认证有效、账号没有被封禁，只能说明账号本身具备使用资格；它不等于每个模型在每个区域、每个时段、每个上游容量池都有可用席位。把“资格”和“即时接入容量”混为一谈，是这条错误最容易造成的误解。
我们如何逐步缩小范围
| 观察到的现象 | 对排查的意义 |
|---|---|
| 同一套 YAI Router 代码下，老账号稳定、新账号更容易失败 | 不支持“网关代码整体失效”的解释 |
| 新机器、最小请求也能复现 | 不像本地缓存、配置或单个客户端损坏 |
| 部分账号始终正常 | 不像影响所有用户的简单全局限流 |
| 账号有余额、有权限仍收到提示 | 容量拒绝与额度/资格是两类状态 |
| 同一会话前后可能成功 | 更像瞬时接纳、路由或容量池波动 |
| 上游 200 + 错误语义 | 需要做业务层错误识别，不能只看传输层状态 |
综合这些信号，我们将重点从自己的请求代码转向了上游账号登录后的路由和容量分配。某些认证会话会带有 edge gateway 的主机元数据，我们在新旧账号之间观察到路由相关差异；这支持“部分账号落入异常的上游路由/容量池”这一运行假设，但不构成对 OpenAI 内部节点拓扑的证明。
为避免泄露敏感信息，下面只展示脱敏后的结构示意，不是任何真实账号的凭据：
{
"host": "chat.gateway.<redacted>.api.openai.com",
"iss": "edge-gateway",
"aud": ["chatgpt.com"],
"iat": "<redacted>",
"exp": "<redacted>"
}官方公开信息与 Codex issues 给出的交叉证据
这次判断并非只来自我们的单点日志。我们同时核对了 OpenAI 官方状态页和 openai/codex 仓库的公开讨论。
官方状态页
- 2026 年 8 月 11 日：API、Codex 和 Work Mode 错误增加：状态页记录了调查、缓解和恢复过程，并于 UTC 22:42 标记“所有受影响服务已完全恢复”（北京时间 8 月 12 日 06:42）。
- 2026 年 7 月 9 日：选择模型时出现容量错误：官方描述为多个模型出现 “Selected model is at capacity”。
- 2026 年 7 月 17 日：Codex 5.6-sol 服务器过载错误增加：状态页记录了 Codex 5.6-sol 的 server-overload 错误和后续恢复。
- 2026 年 6 月 16 日：Codex “Selected Model is at Capacity” Error：这是此前同类事件的官方记录。
状态页同时提醒，公开可用性指标是跨套餐、模型和错误类型的聚合值，单个用户的体验可能因套餐、模型和 API 功能而不同。这正好解释了为什么“很多人正常”和“部分账号持续异常”可以同时成立。
官方 Codex 仓库
- Issue #19583：用户在仍有大量额度时遇到容量错误；OpenAI 协作者说明，这条消息不一定意味着限流或用量耗尽，而可能是所在区域服务该模型的容量不足。
- Issue #17014：同一账号额度充足，某个模型短暂失败，随后最小请求又成功；报告将其识别为模型接纳/容量问题，而不是持续性的账号额度耗尽。
- Issue #30073：在活跃会话中间歇出现错误，前后请求仍可能正常，说明会话本身未必失效。
- Issue #33853：用户请求在容量错误后暂停队列并重试，反映出这类瞬时失败对长任务和任务编排的实际影响。
单个 GitHub issue 是用户报告，不应被当作内部根因公告；但当官方协作者的解释、状态页事件和不同客户端的独立反馈指向同一类容量/接纳问题时，它们足以说明：这不是 YAI 独有的现象，也不能简单归结为某个用户的余额或配置。
我们采取了哪些措施
在问题尚未确认前，我们优先做了对用户影响最小的处理：
- 逐条检查 200 响应的业务语义。 识别容量错误，避免网关把失败当成成功记录。
- 保留原始上下文和证据。 对比账号、模型、入口、时间和响应特征，不用“换号”掩盖问题。
- 向官方和同行同步。 我们通过 X.com 向相关负责人员反馈，也和使用相同上游的同行交换了时间线与复现情况。
- 确认上游恢复后回滚临时代码。 不再把上游容量问题伪装成网关成功，也不在没有明确策略时擅自切模型。
- 继续监测分层指标。 观察老账号、新账号、不同模型和不同入口的恢复情况，而不是只看一个全局成功率。
我们没有选择无上限重试，原因很实际：大上下文 Codex 任务重试可能重复消耗、放大上游拥塞、重复计费，甚至破坏会话和流式状态。可靠性不只是“再试一次”，还包括让失败保持可解释、可恢复、可审计。
用户现在应该怎么做
如果你再次看到这条提示：
- 先查看 OpenAI Status，确认是否有 API/Codex 相关事件。
- 不要连续提交同一个大型 Agent 任务；保留原提示和会话，间隔一段时间后再重试。
- 记录发生时间（含时区）、模型、入口、是否只有某个账号受影响，以及请求 ID；不要提交 API Key、访问令牌或完整响应中的敏感字段。
- 业务有明确时限时，可以在网关或客户端配置经过验证的备用模型，但应提前评估能力、上下文、延迟和成本差异。
- 企业私有部署用户可以把脱敏后的时间线和请求特征发给我们，我们会协助判断是本地网关、上游账号还是模型容量问题。
我们对可靠性的承诺
YAI Router 从上线以来，始终把稳定性、可观测性和企业可控性放在模型数量之前。此次事件也提醒我们：
- 网关必须同时监控 HTTP 状态和响应体语义；
- 上游容量、区域路由和账号分层需要更清晰的健康度指标；
- 临时兼容代码必须有退出条件，问题确认后及时回归主路径；
- 企业场景需要可审计、可控的备用路由，而不是隐式地改写用户请求。
感谢这段时间用户、企业客户和同行的包容、复现和反馈。我们会继续完善 API Gateway、YAI Router 以及 Codex/Grok 周边模型服务，为更多高校、企业和个人用户提供稳定、透明、可持续的 AI 基础设施。