使用 Codex 等客户端时返回 Selected model is at capacity，重试有时立刻恢复，有时连续失败一整天。本文梳理这条报错的真实含义、常见诱因（服务端容量、并发过高、长任务占位、出口网络异常），并给出从低成本重试、降低并发到账号与网络排查的可执行步骤，同时说明哪些“偏方”有封号风险。
使用 Codex 或其他调用同类模型的客户端时，界面可能突然返回一句英文：Selected model is at capacity. Please try a different model.，意思是「所选型号已满，请尝试其他型号」。它常出现在任务跑到一半，或者连续发了几条指令之后；点重试有时立刻恢复，有时连续十几次都过不去。
同一个报错，不同人的经历差别很大：有人几秒钟就恢复，有人被卡一整天；有人只在开高并发时遇到，有人单开一个会话也会撞上；也有企业版用户表示同事同样遇到过。下面把各种判断整理成一条可执行的排查顺序，从最省事的做法开始。
这条报错到底在说什么
字面意思很清楚：服务端在模型这一层没有空闲容量了，建议你换一个型号。它属于容量类错误，不是本地安装损坏、不是 API Key 写错、也不是提示词有问题。几个可以帮判断的特征：
- 重试或让任务继续一两次后自行恢复；
- 集中在某些时段出现，其他时段完全正常；
- 长任务、多并发、多个子任务并行时更容易撞上；
- 企业版同样会出现，说明它跟套餐等级不完全挂钩。
要把它和「额度用完」区分开。额度或配额问题通常会明确提示配额不足、账单异常之类；「at capacity」指向的是模型侧的可用容量，与你账户里还剩多少钱关系不大。
常见原因，按可能性排序
| 原因 | 典型表现 | 怎么判断 |
|---|---|---|
| 服务端真实容量紧张 | 同一时段多人同时报错，几分钟到几十分钟后缓解 | 看官方状态页、官方公告，或换个网络、换个账号仍复现 |
| 单账号并发过高 | 多开终端、多开 agent、批处理同时跑时集中出现 | 把并行数降到 1–2 后明显缓解 |
| 长任务长时间占用 | 单个请求耗时长，跑大仓库、长上下文时出现 | 把任务拆小、缩短单次运行时间后减少 |
| 出口网络或环境异常 | 只在某些网络下稳定复现，换网络就好 | 对比不同网络出口的表现 |
| 客户端自身分发子任务 | 一次两次，随后自动恢复 | 日志里能看到是子任务调用时报的 |
有一种说法是「只有某一地区的用户才会遇到」，这个结论没法证实。更合理的解释是：不同人群使用的网络路径、访问方式和并发习惯不同，导致遇到概率有差异，不必把它当成定论。
处理办法
第一步：先做低成本重试，但要退避
大多数瞬时容量问题，继续一两次就过去了。问题在于很多人写成无限循环重试，反而把并发压力放大。建议用指数退避，并设置上限：
第 1 次：等 1 秒
第 2 次：等 2 秒
第 3 次：等 4 秒
第 4 次：等 8 秒
第 5 次：等 16 秒，仍失败则停止并提示人工处理
要点：最多重试 5 次左右；只对「容量类」错误重试，鉴权失败、参数错误重试没有意义；把重试过程写进日志。
第二步：把并发降下来
这是最有效的一招，也最容易被忽略。逐项检查：
- 同时开着的终端窗口、编辑器插件、后台进程是不是都在跑同一个模型；
- 自动化脚本里是否有隐藏的并行队列；
- 批量任务能不能改成串行，或者错峰执行；
- 单个大任务能不能拆成若干小步骤，每步单独确认。
讨论中不少人反馈，把并发从较高值降到一两个之后，报错频率显著下降，这比反复重试更管用。
第三步：按提示换模型或换入口
报错本身就建议「换个型号」。客户端一般支持通过启动参数或配置文件指定模型，具体写法以官方文档为准。另外，同一个账号在不同入口（交互式命令行、脚本调用、编辑器集成）上的限制不一定相同，可以交叉验证是账号问题还是某个入口的问题。
第四步：确认是不是普遍故障
如果同一时段多人复现、官方状态页有相关说明，那基本只能等。这时候折腾本地环境、反复登录退出都没有意义，反而可能触发额外的异常判定。
第五步：检查账号与网络环境
如果只有你长期、稳定地复现，而别人正常，就需要看环境：
- 出口 IP 是否频繁变化，代理节点是否来回切换；
- 是否在多台设备上同时登录同一个账号；
- 是否有自动化脚本以不自然的高频方式发请求。
网络抖动、出口频繁变更本身就会让长会话中断，重连后又被当成新请求压上去。若长时间运行的会话经常因为网络问题断掉，一种可选做法是把这类任务放到出口稳定的远程机器上跑，例如整机放在新加坡机房的独享远程 Mac，按月租用、远程连接、可长期在线，能减少本地断网和切换节点带来的干扰；但这只解决网络侧问题，解决不了服务端容量不足。
关于「开新号」「找人共号」这类说法
讨论里出现过直接退款、重新注册账号的建议。需要提醒的是：批量注册新账号、购买或共享他人账号来绕过限制，通常违反服务条款，可能导致账号被永久封禁，历史会话和工作数据一并丢失，代价远大于等几个小时。
更稳妥的路径是：
- 企业版或团队版走管理员渠道提交支持工单，附上出现时间、模型名称、请求 ID 和并发情况；
- 个人账号通过官方支持入口反馈，说明是容量错误而非账单问题；
- 在等待期间用其他可用模型或降低任务规模过渡。
检查清单
- 先继续/重试一两次，别急着改配置；
- 重试要有退避和次数上限，写进日志；
- 把并行任务数降到 1–2，关掉多余的窗口和后台进程；
- 拆小长任务，缩短单次运行时间；
- 换模型或换入口交叉验证；
- 查官方状态页与公告，确认是否普遍故障；
- 检查出口网络是否稳定，避免频繁切换节点和多设备同时登录；
- 长期复现再走官方支持渠道，不要靠注册新号规避。
小结
Selected model is at capacity 本质是一条容量提示，不是封号通知，也不是本地环境坏了。绝大多数情况下，退避重试加上降低并发就能解决；剩下的部分要么等服务端恢复，要么从网络出口和账号使用习惯上找原因。模型的容量与限流策略变化较快，具体参数和可用型号请以官方最新文档与公告为准。