十多人共用 4 个 Codex 账号，频繁遇到 Selected model is at capacity，反复重试也无效。文章拆解这条报错的三种成因——服务端容量波动、账号被降权、调度判定异常，给出串行使用、会话内不切号、退避重试、错峰等可立即执行的缓解步骤，并对比一人一号、席位订阅与第三方中转的适用场景与风险。
一个十来人的团队，手里只有 4 个 Codex 账号，长期靠一个共享池轮着用。最近几乎每次请求都弹回同一句话：Selected model is at capacity. Please try a different model.，反复重试也没用，正常工作几乎停摆。要解决的问题有两个：这套共享模式还能不能救回来，以及要不要重新买号、从哪买。
类似情况并不只出现在多人共用的场景。有人一个人用一个更高档位的订阅，某个下午也会密集遇到这条提示，第二天又自己恢复正常；也有人两三个号轮着用，一旦在同一个任务中途换号，报错就跟着来。这些现象放在一起，说明它不是简单的「谁把额度用超了」。
这条报错到底在说什么
字面意思是「所选模型当前容量已满，请换一个模型试试」。但它出现的位置很微妙：既可能出现在服务端整体吃紧的时候，也可能出现在某个账号被放进了低优先级的调度队列里。
几个可以用来判断的观察点：
- 时段性：集中在工作日白天、整点前后、额度重置周期附近，第二天自行缓解，更像服务端容量波动。
- 账号相关性：同一个号怎么试都失败，换一个号立刻正常，更像这个账号被限流或降权。
- 行为相关性：只在共享池、任务中途切号、多设备同时请求时出现，更像调度策略判定异常。
三类原因的处理方式完全不同，所以第一步不是急着换方案，而是先把范围缩小。
常见诱因与判断方法
| 诱因 | 典型表现 | 怎么判断 |
|---|---|---|
| 多人共用一个账号 | 偶发报错逐渐变成常态 | 记录同一分钟内的请求数，远超单人使用强度 |
| 任务中途切换账号 | 报错集中出现在切换点之后 | 跑一次全程不切号的同样任务做对比 |
| 客户端自动重试或批量并发 | 越重试越糟，失败率上升 | 关掉自动重试，手动发一次请求 |
| 订阅或账单状态异常 | 长期稳定报错，不随时段变化 | 核对订阅是否正常续费、支付方式是否仍有效 |
| 服务端容量波动 | 同一时段多人都受影响 | 让团队同步一下各自报错的时间点 |
立刻能做的几件事
- **先做单变量验证。**挑一个账号、一台设备、一个会话，单线程跑一次完整任务。如果仍然报错，基本可以排除并发问题，往账号状态或服务端容量方向查。
- **串行化。**约定同一时间只有一个在使用同一个账号，用共享文档或群里报时的方式排队，而不是谁想用就用。这一步对缓解压力最直接，也最不需要成本。
- **一个会话只用一个账号跑完。**不要把长任务拆到多个账号接力，中途换号会让上下文和缓存全部作废，还容易触发异常判定。宁可把任务切成更小的块，一块一个会话。
- **给重试加退避。**不要在报错后一秒内连点，那只会让情况更糟。
- **临时降级模型。**不重要的任务遇到容量报错时，切到较轻量的模型先做完，把主力模型留给关键工作。
- **错峰。**避开工作日白天高峰和额度重置前后那段时间。
- **核对订阅状态。**确认账单、支付方式没有异常，避免账号因为计费问题被放到低优先级。
重试逻辑可以写成这样，把命令替换成你实际在用的 CLI 调用即可：
# 关键点：失败后拉长间隔，不要在 1 分钟内反复请求
for wait in 30 120 300 600; do
if COMMAND; then
echo "ok"
exit 0
fi
echo "capacity 报错，${wait}s 后重试"
sleep "$wait"
done
echo "仍然失败，先停手，避免把账号状态拖得更差"
exit 1
账号该怎么配才合理
| 方案 | 适用场景 | 代价与风险 |
|---|---|---|
| 一人一号 | 核心开发者、每天长时间使用 | 最稳定，成本也最高 |
| 少量共用加排班 | 十来人但真正高频的只有几个 | 依赖团队纪律，仍会偶发不可用 |
| 官方团队/席位订阅 | 使用人数稳定在十人以上 | 按席位付费、账号不共用，具体档位与规则以官方最新说明为准 |
| 第三方中转或代理 | 非敏感、可丢弃的临时任务 | 稳定性不可控，提示词和代码会经过第三方，存在被记录留存的可能 |
| 购买来路不明的账号 | 不建议 | 来源不明、支付方式异常、随时可能被回收 |
有两条路需要特别提醒。
**一是用技术手段掩盖共用。**比如给每个账号配不同出口、按优先级轮流切换、刻意错开请求节奏，本质上都是让平台难以识别多账号共用。这类做法通常违反服务条款，即使短期见效，一旦被判定异常，账号可能被限流甚至封禁，历史会话和数据也拿不回来。团队已经有十几个人，掩盖共用的成本其实高于直接按人数买席位。
**二是买号或租号。**账号所有权不在你手上，随时可能被原持有人找回或被平台回收；付费记录、上下文历史、团队协作数据都不可控。需要扩容就走官方购买流程，别在灰色渠道上赌。
排查清单
- 单账号、单设备、单会话是否仍然报错
- 报错是否集中在固定时段，隔天是否自行缓解
- 是否有任务在运行中途切换过账号
- 客户端是否开启了自动重试、批量任务或多线程并发
- 订阅状态和支付方式是否正常
- 团队同一时间在跑多少请求，是否远超单人使用强度
- 报错发生时，其他人是否也在同一时段报错
两个容易忽略的点
**时效性。**订阅档位、席位规则和限流策略调整得很频繁，采购前请以官方页面的最新说明为准，不要照搬几个月前的经验。
**运行环境。**如果团队真正卡住的不是额度，而是任务必须长时间挂着跑——比如夜间批量重构、长时间跑测试，本地机器休眠或网络抖动会打断会话，重连后又触发一轮新请求，把有限的额度消耗在重试上。这种情况可以把 CLI 放到一台长期在线的机器上运行，例如机房里的独享 Mac mini，远程连接使用，减少中断带来的重复请求。但这只是改善运行环境，解决不了账号容量和并发问题，额度该不够还是不够。
小结
先分清是服务端容量波动、账号被降权，还是调度判定异常，再决定动作。短期靠串行使用、会话内不切号、退避重试和错峰把可用性拉回来；中期按实际人数配席位，别把十几个人压在 4 个账号上。来路不明的账号不要买，也别用技术手段去掩盖共用。