ChatGPT Plus 一直提示模型容量已满：原因排查与恢复思路

订阅了 ChatGPT Plus，某天开始几乎所有对话都只回一句话：「Selected model is at capacity. Please try a different model.」。换浏览器、重装 App、退出重登都试过，报错纹丝不动。更奇怪的是，同一时间普通聊天还能用，可一旦涉及 Codex、agent 之类的功能就立刻失败。

这句话的字面意思是「你选的模型当前容量不足，换一个模型或稍后再试」，属于典型的临时性提示。但当它连续几天、几十次出现，就不再是「稍后再试」能解释的了。不同账号的表现也差别很大：有人隔一天自己恢复，有人换个号就正常，有人只在某个具体功能上崩，还有人怎么折腾都没用。下面把这几种情况的成因、可以自己动手做的排查，以及各种恢复做法的取舍整理一遍。

先分清是哪一类问题

同样是这行报错，背后的原因完全不同。花两分钟做一次对照，比盲目重试有效得多。

多数人的实际情况是上面几项叠加：账号本身已经被限流，网络出口又不干净，于是换什么模型都撞墙。

按从快到慢的顺序排查

建议严格按下面顺序走一遍，每步之间不要混着改，否则无法定位。

1. 换模型 + 新开会话（30 秒）。不要在原会话里继续追问，直接新建对话，并切换到另一个可用模型。如果新会话正常，问题基本锁定在上下文或单个模型上。
2. 清空长会话。上下文特别长、或某个 Codex / agent 会话里积累了上百轮交互时，容易持续触发失败。把任务拆小、重新开一个干净会话再跑一次。
3. 换网络。断开代理或 VPN，改用手机热点，再试同一操作。如果热点下恢复正常，说明是出口 IP 的问题，而不是账号。
4. 换客户端。网页版、官方桌面端、手机 App 分别试一次。有时是某一个客户端的会话状态坏了，退出登录再登入能解决。
5. 做账号侧的自检。访问官方帮助中心，用右下角的聊天入口描述你遇到的报错。如果回复大意是「即使付费订阅有效，某些模型或功能的访问也可能被临时限制」，说明账号侧确实存在限制；如果回复强调「只是所选模型临时过载，请切换模型或稍后重试」，则更偏向容量问题。
6. 观察时间窗口。记录第一次出现的时间，之后每半天试一次即可。短时间内反复重试没有任何好处，反而可能加重限流。

需要说明的是，第 5 步的机器回复是一段模板话术，判断力有限，也不断在调整。有人反馈同一个号前后两次问到的结论并不一致，所以它只能作为参考，不能当作判决书。

几种恢复做法的适用场景与取舍

全设备退出登录，静置一天

成本最低、副作用最小的一种做法：在所有设备上退出登录，24 小时内不登录、不发起请求，之后再登入。不少人用这个方式恢复过。但它属于经验做法，官方并没有承诺，也不保证恢复后能维持多久——使用强度一上去，限流可能再次出现。适合不着急、可以等的情况。

降低并发与使用强度

同时开多个会话、多个 agent 并行跑长任务，是很容易被忽略的触发点。把并行改成串行，把长任务拆成若干小段，间隔几分钟发起，往往比任何「偏方」都管用。如果主要用途是批量处理，更适合走官方 API 按量计费，而不是让订阅账号承担自动化负载。

固定网络出口

出口 IP 频繁变化、或与他人共用同一批代理节点，都会让账号更容易被风控盯上。条件允许时，尽量使用稳定、独享的网络出口，并避免在使用过程中反复切换节点。这一条对长期在线跑自动化任务的场景尤其重要。

关于升级更高档订阅

有人第一反应是升级套餐来解决。需要注意的是，限流和容量问题通常不是靠提高订阅档位就能绕开的，而且升级涉及计费与退款，具体规则请以官方最新的订阅说明为准。建议先完成前面的排查，确认是账号侧限制还是容量问题，再决定要不要动订阅。

关于共享账号与来路不明的中转服务

把账号借给他人、购买共享号、或使用第三方中转服务，看似能立刻绕过报错，但风险很实在：账号可能因异常登录被批量封禁，对话内容会经过陌生中间层，付费后服务随时可能消失，也基本不符合平台的服务条款。不建议把工作和重要数据放在这类通道上。更稳妥的替代是：日常交互用官方订阅，批量任务用官方 API，团队场景考虑官方的团队或企业方案。

几个容易踩的坑

• 不要把客服机器人的回复当成定论。模板话术会随官方调整而变化，今天能用来「检测」的方法，过一段时间可能就失效了。
• 不要用非官方客户端来「验证」账号状态。用订阅账号登录第三方客户端，可能触发额外的合规检查并返回与订阅共享相关的报错。这类报错说明的是该客户端的使用方式不被认可，不能直接推导出账号被降级，而且这种做法本身有违反服务条款的风险。
• 不要为了测试而疯狂重试。短时间内的高频失败请求本身就是异常信号。
• 区分「账号问题」和「模型问题」。聊天正常但某个功能不通，往往只是那个模型或那条链路容量紧张，等一段时间就会缓解。

长期在线的场景可以怎么安排

如果你主要是在本地机器上长时间跑命令行 AI 工具（例如 Claude Code 之类），会发现另一类干扰：机器休眠、断网、切换 Wi-Fi、出口 IP 变动，都会让长任务中断，重连后状态还得重来。这种情况下，把运行环境挪到一台长期在线的机器上是可选的思路之一——例如整台 Mac mini 托管在新加坡机房、按月租用、远程连接的独享远程 Mac，网络出口相对固定，也不用担心本地断电和休眠。它解决的是「在线时长与网络稳定性」，并不能解决账号本身的限流，两者要分开看。

小结

「Selected model is at capacity」既可能是平台真的挤，也可能是你的账号被单独限流，还可能是长会话或出口 IP 造成的假象。处理顺序建议是：先换模型和新会话，再换网络和客户端，然后用帮助中心做一次粗筛，最后才是退出登录静置、降低使用强度这类慢办法。共享账号和第三方中转虽然见效快，但代价是账号安全和数据隐私，不建议作为长期方案。至于各种「检测降智」的技巧，官方随时会调整，遇到结论冲突时，以官方最新说明和自己账号的实际表现为准。