Codex 突然报错？教你几招应对“模型已达上限”问题

最近在用 Codex 玩代码生成的朋友，估计有不少人跟我一样碰了一鼻子灰。

明明打开界面的时候还显示我有好几个小时的免费额度没用完，结果刚问了一半问题，或者正准备让 AI 帮我完善一段代码时，它突然毫无征兆地给弹出一个红框报错：

常见的“Selected model is at capacity”报错提示

Selected model is at capacity. Please try a different model.

（指定模型已达容量，请尝试其他模型。）

这搞得人一脸懵逼。我的额度还在，怎么就“容量”不够了？这到底是系统抽风，还是我的账号有问题？

后端服务器资源满载示意

为什么会报这个错？

首先先给大家吃个颗定心丸，这大概率不是你账号的问题，也不是你的额度被偷了。

这里的“at capacity”，指的其实不是你的使用次数上限，而是 OpenAI 后端服务器的并发承载能力。简单来说，就是用这玩意儿的人实在太多了，服务器那一侧的计算资源暂时排队排满了，或者某个特定模型的路由负载过高，系统为了防止彻底崩溃，就会暂时拒绝新的请求，提示你去换个模型试试。

尤其是在晚间高峰期，或者是某个新功能刚上线那会儿，这种报错出现的频率会直线飙升。

几个实用的解决/绕过方案

既然知道了原因，咱们总不能干等着。这里整理了几个经过实测（或者社区反馈有效）的解决办法，按顺序试一试，通常能解决问题。

1. 最简单粗暴：刷新页面重试

这听起来像是“关机再重启”的废话文学，但在 Web 端应用里确实管用。有时候是因为你的会话连接僵死在了某个过载的节点上。直接刷新浏览器，或者关闭当前 Tab 重新打开，这会让你重新建立连接，运气好就能连到负载较低的节点上。

2. 切换模型（如果有的选）

报错信息已经明示了“Please try a different model”。如果你当前使用的是 GPT-4 Turbo 或者 Codex 的高配版，可以尝试切换回 GPT-3.5 或者其他轻量级模型。

虽然代码生成能力可能稍微弱一点，但轻量级模型的服务器集群通常规模更大，更容易挤进去。应急处理一些简单的脚本重构、Bug 查询足矣。

3. 剥离 Context，开启“新对话”

很多人习惯在一个长对话里一直聊下去，上下文堆得非常长，不仅消耗 Token，也会增加服务器处理单个请求的负担。

遇到报错时，建议直接点“New Chat”（新对话），把刚才的背景信息简单概括一下重新发过去。短上下文的请求处理速度更快，成功率也更高。

4. 错峰出行，避开晚间高峰

如果以上技术手段都无效，那可能就是单纯的洪峰流量了。根据观察，北美时间的白天或者国内的工作日白天，服务相对稳定。到了晚上大家都下班了开始搞业余项目，服务器压力就上来了。

如果不是十万火急，先把需求记在备忘录里，睡一觉或者过两个小时再来，通常就能丝滑进入了。

5. 检查网络环境

少部分情况下，可能是你的网络代理节点出现了波动，导致连接到了错误的 API 网关。尝试切换一个代理节点，或者如果你有 API Key 的话，试着通过第三方客户端（如 Po, Chatbox 等）直连 API，看看是否能复现问题。如果第三方客户端正常，那就说明是官方网页端的临时故障。

总结

Codex 以及相关的大模型服务在快速发展期，基础设施偶尔“吃不消”是在所难免的。遇到“Selected model is at capacity”报错，先别急着焦虑，按照上面的步骤排查一下，大部分时候只是暂时的拥堵。

当然，这也提醒我们在做关键项目依赖时，最好多准备一个备选方案（比如同时测试其他家的 Coder 模型），免得关键时刻掉链子。

你最近有遇到类似的 AI 故障吗？欢迎在评论区分享你的遭遇和解决妙招！