Codex 报「模型已满」：常见原因与排查步骤
使用 Codex 等 AI 编程工具时，经常遇到“Selected model is at capacity. Please try a different model.”。本文把这个报错拆成四类原因：服务端容量、账号状态被风控、代理与网络链路，以及客户端和系统升级后的兼容问题，并给出一份从易到难的排查清单和可操作的解决思路，帮助你分清到底是平台忙还是自己的环境有问题。
连续几天调用 AI 编程工具时反复弹出一句 Selected model is at capacity. Please try a different model.，重试几次偶尔能通过，多数时候直接失败；手动换到另一个模型能跑，但过一阵子它也报同样的错。有人还伴随回答质量下滑、上下文变短、响应变慢。看起来像是“服务器太忙”，可偏偏只有自己一直遇到，别人却正常。
这个报错的字面意思是“所选模型当前容量已满，请换一个模型”。它既不是代码写错，也不是配置项拼错，而是请求在服务端或链路中间被拒了。关键在于：拒绝的原因可能真的只是平台忙，也可能是你的账号状态、网络出口或客户端状态让请求“看起来不对劲”。下面按可能性从高到低拆开说。
这个报错大致对应哪几种情况
| 类型 | 典型表现 | 判断线索 |
|---|---|---|
| 服务端容量或模型级限流 | 换个模型立刻好，过一会儿再切回来也能跑 | 与时间段、模型热度相关，多个账号同时出现 |
| 账号状态异常 | 只有某个账号必现，换账号就正常 | 与额度、并发、登录设备数量有关 |
| 网络与代理链路 | 报错之外还伴随超时、连接重置、流式中断 | 换手机热点后明显改善 |
| 客户端或系统兼容 | 某次系统或客户端升级后突然开始 | 换一台机器或换一个客户端就正常 |
服务端确实忙
新模型上线初期、工作日的集中时段，容量吃紧是常态，平台侧会直接拒绝一部分请求而不是排队。这种情况个人几乎无解，只能错峰或临时换模型。它的特征是“间歇性”，同一分钟内重试有时能成。
账号被判定为异常使用
这是最容易被忽略的一类。当同一个账号在短时间内被多个客户端、多个 IP、多个脚本同时消耗，或者登录设备频繁变动，平台可能降低该账号的可用性：轻则限流，重则大量请求被拒。表现出来的样子，和“模型满了”几乎一样。
需要说明的是，把账号交给第三方中转、多人共享，或者用来路不明的代充，本身就违反大多数平台的服务条款。一旦被识别，损失的不只是几天额度，可能是整号封停，且申诉成功的概率很低。这类做法不建议尝试，本文也不提供任何相关操作细节。
代理与网络链路
这条线索在讨论里出现得最多，也最符合“只有我出问题”的特征。系统大版本升级之后，依赖虚拟网卡（TUN 模式）的代理工具有可能失效或半失效：部分流量走了代理，部分走了直连，或者连接被系统网络栈重置。表现出来就是请求时好时坏，偶尔还夹着证书或连接类错误。
另外，分流规则也值得看一眼。如果客户端请求的域名被规则判成“直连”，而本地网络又访问不到，就会表现为超时或异常失败；反过来，如果所有流量都从一个人人都用的公共出口出去，也可能被平台的风控策略区别对待。
客户端与系统升级
系统升级后，旧版本的代理客户端、旧版本的 CLI 工具、旧的证书链都可能出问题。典型症状是“升级前好好的，升级后天天报错”。这种情况下换回旧版本或者更新到官方最新版，往往比反复重试更有效。
一份从易到难的排查清单
建议按顺序做，每一步都记录结果，避免同时改多个变量导致无法判断根因。
- 换模型验证：立刻切到另一个模型重试。如果秒过，基本可以锁定是模型级容量或该模型对你的限流；如果照样失败，问题更可能在账号或链路上。
- 换网络对比：断开当前网络，用手机热点跑一次同样的请求。热点下正常，说明问题在本地的代理或路由；热点下依旧报错，问题在账号或服务端。
- 检查代理工作模式：确认是系统代理还是 TUN 模式，是否有全局/规则分流的差异；系统刚升级过的话，优先把代理客户端更新到官方最新版，或者临时换成另一种工作模式（例如把 TUN 换成系统代理）做对比。
- 查账号状态：确认额度是否耗尽、是否有其他设备或自动化脚本在用同一账号、最近的登录地是否异常。
- 退出全部会话再登录：在账号安全设置里登出所有设备，等一段时间后只在一台机器上重新登录，观察是否恢复。这一步能排除多端并发导致的判定异常。
- 核对客户端版本：把 CLI 或桌面客户端升级到官方最新版，注意命令行工具和配置文件里的模型名要与官方文档一致，写错模型名也可能得到类似的报错。
- 看日志而不是靠猜：打开详细日志，区分是 HTTP 4xx/5xx、连接超时还是流式中断。错误类型不同，处理方向完全相反。
解决思路
如果是容量问题：错峰使用，或者把工作流改成“主模型 + 备用模型”双通道，主模型失败时自动降级。写代码这类任务对模型差异的容忍度其实不低，先跑通再优化。
如果是账号问题：只保留一个干净的登录环境，不要多端并发、不要共享、不要用中转。额度紧张时优先减少无效重试——短时间内高频重试本身就可能加重风控判定。
如果是网络问题：把出口固定下来。固定出口、固定设备、减少节点切换，是让账号“看起来稳定”的最简单办法。如果本地网络本身就不稳定，或者需要让 AI 工具长时间在线跑任务（夜间批量重构、长任务代理），可以考虑把运行环境放到一台长期在线的远程机器上，例如整台 Mac mini 放在新加坡机房、按月租用、远程连接的方案，网络出口和机器状态都相对固定，也不用担心本机休眠或代理掉线。这是可选做法之一，是否值得取决于你对稳定性的要求。
如果是兼容问题：优先升级客户端和代理工具，而不是回退系统；确实需要回退时，先确认工作必需的其他软件是否受影响。
几个容易踩的坑
- 不要用报错信息直接下结论。同一句提示背后至少有四种原因，先做换模型、换网络两个对照实验，能省掉大半时间。
- 不要迷信“降智”说法。回答变短、变敷衍，有时确实是模型或策略调整，有时只是上下文被截断或服务降级，需要结合日志判断。
- 不要为了省事把账号交给第三方托管。短期可能好用，长期是把自己的使用记录和账号安全交出去。
- 平台策略和客户端行为变化较快，具体的模型名、配置字段和限制规则请以官方最新文档为准，本文只提供排查思路。
小结
Selected model is at capacity 不是一个“修复某个开关”就能解决的问题，它更像一个信号：请求在某一层被挡了回来。先用换模型、换网络两个动作把范围缩小到“服务端、账号、链路、客户端”四者之一，再针对性地处理。多数情况下，稳定单一的登录环境加上固定可靠的网络出口，能消掉绝大部分偶发报错；剩下的那部分，交给错峰和备用模型即可。
