ChatGPT 与 Codex 提示 Selected model is at capacity：从诊断到恢复的完整教程

当 ChatGPT、Codex CLI、IDE 插件或桌面端反复出现 Selected model is at capacity. Please try a different model. 时，最容易犯的错误是把它简单理解成“服务器忙”，然后不停重试、换 IP、切换第三方代理。实际上，相同提示可能来自平台容量、区域路由、客户端状态、网络链路、并发负载或账号安全检查。正确做法不是猜测某个隐藏机制，而是用最小变量实验逐层定位。

本文整理出一套安全、可复现的排障流程。它不会教你绕过访问控制，也不依赖修改请求、注入未知状态或使用共享账号；目标是在保护账号和数据的前提下，判断故障属于哪一层，并形成可提交给官方支持的证据。

一、先理解：同一句报错不等于同一个原因

at capacity 描述的是一次请求没有获得预期服务能力，却不能单独证明账号被限制，更不能证明模型真的“降智”。社区讨论中常见以下四类情况。

1. 平台或模型容量波动

某个模型、地区或产品入口在高峰期资源紧张，简单请求也可能失败。其特征通常是：

• 多名用户在接近的时间段同时遇到问题；
• 切换到其他模型后可用；
• 官方状态页、开发者社区出现集中反馈；
• 等待一段时间后，无需修改本地配置即可恢复。

2. 客户端或会话状态异常

网页缓存、过期登录态、旧版 CLI、IDE 扩展或本地路由层都可能让请求表现异常。此时同一账号在官方网页可用，但在某个客户端持续失败。

3. 网络与出口质量问题

公司网关、透明代理、频繁变动的出口、丢包或 TLS 中间层会干扰长连接和流式响应。网络问题常伴随超时、断流、503、连接重置，而不只是一条容量提示。

4. 账号安全或访问资格被临时重新评估

官方社区信息表明，某些模型或功能的访问可能因账号活动而被暂时限制，系统会自动重新评估，但官方通常不会公开具体检查规则。因此，只能把它作为一种可能性，而不能仅凭报错断言“被标记”。

二、10 分钟最小诊断：一次只改变一个变量

排障的关键是建立对照组。请先记录时间、时区、入口、模型、客户端版本和完整错误，再按下面顺序测试。不要同时换模型、网络和客户端，否则即使恢复也无法知道真正原因。

步骤 1：检查官方状态与公开反馈

先查看 OpenAI Status，并搜索开发者社区中同一时间、同一模型的报告。如果大量用户同时出现故障，应优先按平台事件处理，减少无意义的本地折腾。

步骤 2：使用官方入口执行最小请求

退出第三方代理、聚合工具和自动化脚本，直接使用官方网页或官方客户端，新建会话后发送不含附件的短请求，例如：

请只回复：OK

如果最小请求也连续失败，记录每次发生时间，不要用无限循环反复轰炸。高频重试既不能提高诊断质量，还可能制造新的限流变量。

步骤 3：做客户端对照

在不改变账号和网络的前提下，对比官方网页、桌面端、Codex CLI 与 IDE 插件。

• 只有一个客户端失败：优先检查版本、登录态、扩展冲突和本地配置；
• 所有官方客户端都失败：继续检查平台、网络和账号层；
• 官方入口正常、第三方入口异常：问题大概率在第三方路由或兼容层。

步骤 4：做模型对照

保持同一入口和同一网络，选择另一个当前可用模型发送相同短请求。只有特定模型失败，通常更接近容量或模型资格问题；全部模型失败，则应扩大到会话、网络或账号层排查。

步骤 5：做网络对照，但不要频繁跳区

如果条件允许，可在合规、可信的家庭网络和手机热点之间做一次对照。不要连续切换多个国家或数据中心出口，也不要使用来路不明的“纯净 IP”。频繁变化反而会增加安全风险，并污染实验结果。

三、根据结果选择恢复路径

完成最小诊断后，用下面的判断树行动。

路径 A：确认是平台容量事件

1. 保存状态页和社区事件链接；
2. 切换到可用模型完成紧急任务；
3. 降低并发与长任务数量；
4. 间隔一段时间再测试原模型；
5. 不要通过脚本每分钟强制重试。

这类问题的核心是“等待资源恢复”，本地重装通常没有帮助。

路径 B：只有 Codex、IDE 或第三方工具异常

先升级到官方稳定版本，然后退出并重新登录。暂时禁用会改写请求的扩展、代理和兼容层，用最小配置复测。若官方网页正常，应保留客户端日志、版本号和失败请求时间，再向对应工具维护方反馈。

不要把 /v1/models 能返回当作完整链路正常的证据：列出模型只说明基础鉴权或端点可达，不代表推理请求、流式通道和具体模型容量都正常。

路径 C：怀疑账号安全状态异常

先做账号卫生治理，而不是研究绕过方案：

1. 修改为唯一且高强度的密码；
2. 开启多因素认证；
3. 退出不认识或不再使用的设备；
4. 停止共享账号、多人共用会话和来源不明的自动化；
5. 暂停高并发、长时间无人值守任务；
6. 静置一段合理时间后，仅从官方入口低频复测。

这些步骤的价值在于终止异常活动、降低账号泄露风险，而不是保证“养号后必然解除限制”。官方没有公开一套可验证的养号公式，诸如“固定使用某种语言”“精确静置若干小时”等说法只能视为个别经验。

路径 D：疑似网络或出口问题

优先使用稳定、可信、长期一致的网络环境，关闭不必要的多层代理，检查 DNS、系统时间、证书与防火墙策略。企业环境中应让网络管理员确认 WebSocket、HTTP/2 和流式响应是否被拦截。

四、如何判断“模型降智”，而不是只凭感觉

容量错误和回答质量下降是两个问题。若想判断模型质量是否真的变化，应建立小型基准集，而不是用一次复杂对话下结论。

建立 5～10 个固定任务

任务应覆盖你真实使用的场景，例如：

• 修复一个有确定测试结果的代码缺陷；
• 从固定文档提取结构化字段；
• 按明确约束生成 SQL；
• 总结同一段技术材料；
• 执行有标准答案的逻辑题。

对每次测试记录模型、入口、时间、提示词、输出、耗时和错误。使用自动化测试或人工评分表比较正确率、约束遵循率和稳定性。只有在控制变量后持续出现显著差异，才有理由怀疑质量变化。

避免三个误区

• 上下文污染：旧会话中的错误信息会影响后续回答，测试时应新建会话；
• 任务难度漂移：每次问题不同，无法横向比较；
• 确认偏差：预先相信“被降智”，容易只记住失败案例。

五、向官方支持提交一份可处理的工单

“我的模型变笨了”很难定位。高质量工单应包括：

• 订阅类型与受影响产品，但不要提交密码、Cookie 或完整密钥；
• 错误原文和截图；
• 首次发生及最近发生的时间、时区；
• 受影响模型、官方入口和客户端版本；
• 最小复现步骤；
• 不同客户端、模型和网络的对照结果；
• Request ID、Feedback ID 或可安全分享的诊断编号；
• 已执行的账号安全措施。

可使用下面的模板：

问题：官方入口持续提示 Selected model is at capacity
时间：2026-09-20 14:20—16:10，UTC+8
入口与版本：Codex CLI x.x.x / ChatGPT Web
受影响模型：模型 A；模型 B 正常/同样异常
最小复现：新会话发送“请只回复 OK”，连续三次失败
对照结果：官方网页……；其他网络……；其他客户端……
诊断编号：……
期望：请确认是否存在账号级访问异常或区域容量事件

六、哪些做法不建议尝试

网络上常见通过注入非公开字段、复用临时状态、拦截并篡改请求来恢复模型的方案。这些做法存在明显边界：

• 非公开字段可能随时变化，无法保证结论真实；
• 请求篡改可能违反服务条款或触发额外安全检查；
• 本地代理可能接触对话、代码和凭证，带来供应链风险；
• 所谓“恢复”可能只是容量波动结束，缺乏对照实验；
• 共享脚本可能包含窃取令牌或远程更新逻辑。

生产账号尤其不应执行来源不明的注入脚本。真正紧急的业务，应准备模型降级、任务排队、断点续作和多供应商容灾，而不是把稳定性寄托在非官方状态字段上。

七、面向团队的长期预防清单

账号与权限

• 每位成员使用独立账号，开启多因素认证；
• 不共享 Cookie、会话文件和访问令牌；
• 定期清理设备和第三方授权。

工程稳定性

• 为任务设置指数退避和最大重试次数；
• 保存可恢复的中间结果，避免失败后从头执行；
• 把模型、客户端版本和请求标识写入内部诊断日志；
• 为关键流程准备备用模型，并验证输出差异；
• 将容量错误、限流、鉴权失败和网络超时分开统计。

数据安全

• 不把生产密钥和隐私数据交给未知代理；
• 审查第三方插件的权限、源代码和更新渠道；
• 工单与截图中遮盖凭证、Cookie、内部地址和敏感代码。

结语：先建立证据，再选择动作

面对 Selected model is at capacity，最可靠的顺序是：先查平台状态，再用官方入口做最小请求，随后分别对比客户端、模型和网络，最后处理账号安全或提交证据完整的工单。

社区经验可以提供线索，但不应被包装成官方结论。尤其不要因为焦虑而高频重试、购买不明代理或运行请求注入脚本。把问题拆成可验证的变量，既更可能找到根因，也能最大限度保护账号、代码和业务数据。