“Selected model is at capacity”是 Codex 归类为服务器过载的错误。我们核对了该消息与 OpenAI 公开代码的对应关系，并在这台电脑的执行历史中找到相同的完整消息及 serverOverloaded。应将它与用量额度耗尽或电脑故障区分开。不过，公开资料和电脑上的记录都未能确定过载的根本原因。
Selected model is at capacity. Please try a different model.工作停止时，先检查什么
01 保存请求，稍等再试
保留提示词和最后一次完成报告。先等待一会儿再重试，避免不断重复发送。
02 分别检查故障和用量
分别查看 OpenAI Status 和自己的用量。即使还有额度，也可能遇到服务故障。
03 紧急时考虑其他模型
自行选择另一个可用模型。如果故障涉及多个模型，切换也可能无效。
目录
发生了什么：官方故障记录说明了什么
这条消息表示所选模型已达到容量上限，并要求尝试其他模型。没有依据将这里的“capacity”理解为电脑的内存或磁盘空间。OpenAI 官方状态页记录过出现这条消息的服务故障。
2026年6月16日：Codex 容量错误
OpenAI Status 将桌面应用、网页、API、CLI 和 VS Code 扩展列为受影响对象。记录称已采取缓解措施，并已解决故障（官方故障记录）。
2026年7月9日：多个模型出现相同消息
OpenAI Status 的记录包含本文开头所示的完整错误消息，明确说明多个模型受到影响，随后报告已恢复（官方故障记录）。
这两条记录证明，同一消息可能在服务故障期间出现，切换模型也并非总是有效。公开的故障记录数量无法确定错误发生频率，也不能证明你的错误与过去的故障有相同原因。日期沿用官方页面的写法；我们没有把其中的时间转换为日本标准时间。
这两条记录都未公布具体硬件短缺或账号切换缺陷等根本原因。“GPU 不够用”或“Pro 身份验证出了问题”等说法，超出了已核实资料的范围。我们于2026年10月1日核对了官方原始资料，并将已确认事实与本文建议分开说明。
与用量限制、401 和 thread not found 的区别
这些问题都可能表现为工作停滞，但需要检查的事项不同。遇到容量错误，先同时确认屏幕上的完整错误消息和用量状态。同一账号也可能遇到不同类型的问题。
| 消息或情况 | 主要检查事项 | 如何理解 |
|---|---|---|
| Selected model is at capacity | 官方故障记录、发生时间和所选模型 | 仅凭这条消息，不能判断自己的用量额度已耗尽。 |
| 提示达到用量限制或等待额度重置 | 用量页面上的剩余额度和重置时间 | 先确认剩余额度，再决定等待还是如何继续。 |
| 401 Unauthorized Incorrect API key provided | 登录方式和当前账号 | 身份验证问题的处理方法与容量错误不同。 |
| thread not found | 受影响的聊天能否加载或继续 | 这表示找不到聊天，不应将它等同于模型拥堵。 |
在专门的用量页面检查剩余额度
OpenAI 的价格与用量指南引导用户通过用量仪表板检查当前限制。在 Codex CLI 会话中，也可以使用 /status。在错误发生后立即检查，更容易对照当时的剩余额度。
官方指南还说明，即使处理过程中达到用量限制，已经进行中的工作仍可能在公平使用约束下继续。因此，错误之后又出现完成报告，本身并不能确定是否达到了限制。反过来，即使剩余额度充足，也可能发生服务故障。套餐内额度和额外点数可参阅本站的ChatGPT Pro 套餐比较。
遇到 401 错误，先检查登录方式
在Codex 身份验证指南中，通过 ChatGPT 登录与使用 API 密钥登录是两种不同方式。桌面应用的个人资料菜单会显示当前账号或 API 密钥状态。CLI 中可使用 codex login status。
即使通过 ChatGPT 登录时出现“Incorrect API key”，也不能仅凭屏幕判断是用户设置了错误的密钥。要确定被拒绝的是哪一组凭证，还需进一步调查。容量错误并不是立即退出登录或删除身份验证文件的理由。使用 API 密钥会按标准 API 价格单独收费，与 ChatGPT 订阅分开计算。
如果消息是 thread not found，可参阅本站对 Codex“thread not found”错误的调查与处理指南。同一台电脑之前出现过身份验证或聊天错误，并不能证明它们与当前容量错误存在因果关系。
区分 API 的 HTTP 503 与应用中的消息
在OpenAI API 错误代码指南中，HTTP 503、service_unavailable_error 和 server_is_overloaded 表示模型暂时过载。HTTP 429 包括请求频率或用量限制相关错误，而 HTTP 401 与身份验证有关。
不要根据应用中的文字推断 HTTP 状态码
API 文档有助于区分错误类型，但不能证明 Codex 的“at capacity”消息一定对应 HTTP 503。我们对这台电脑的调查也未取得相关请求的 HTTP 状态码。
继续工作的处理步骤
以下建议依据官方故障记录、用量指南和一般故障排查文档整理。它们并不是官方针对这一错误公布的保证有效的修复方法。
1. 保存提示词和最后完成的工作
如果尚未发送的提示词仍在屏幕上，先复制下来，并保留最后一次完成报告或已修改文件的状态。在关闭或更换聊天之前，记录自己提出了什么要求、完成到了哪一步，方便继续工作。
单凭错误消息，不能证明文件未被修改或命令未被执行。使用 Git 开发时，在重复提出同一修改要求前，先查看差异或执行 git status。涉及发布、发送消息或购买的工作，应先确认结果，再决定是否重复指令。
2. 稍等一会儿，查看官方状态页
打开 OpenAI Status，检查是否有影响 Codex 或模型选择的故障。应将错误发生时间与故障时间范围对照，而不是只看故障当前的状态。过去有过同名故障，不代表现在仍在发生。
对于 API 过载，官方建议：如果响应提供了 Retry-After，至少等待其中指定的时间；若没有，则逐步增加重试间隔。对于未显示等待时间的应用用户，我们未能确认必须等待多少秒。本文建议先稍等一会儿再重试，避免短时间内反复发送请求。遇到已公布的故障，应关注官方恢复进展。
状态页提供的是汇总信息，可能无法完整反映某个账号或模型的情况。没有列出故障，并不能证明电脑出了问题。
3. 检查用量，紧急时考虑其他模型
检查剩余额度和重置时间。如果明确提示达到用量限制，应根据该提示决定下一步。若只有容量错误，不应把购买额外点数或付费重置当作恢复方法。恢复自己的额度，与模型能否接受请求是两回事。
优先保证质量和连续性
如果希望继续使用同一模型，就等待恢复。利用这段时间检查需求、修改内容和待完成的验证。
优先立即推进工作
选择另一个可用模型，从小任务继续。如果故障影响多个模型，切换之后工作仍可能停止。
在官方模型选择指南中，桌面应用的模型和推理强度控件位于提示词输入框下方。交互式 CLI 中可使用 /model。可用模型因账号、客户端等因素而不同，不应假定界面未显示的模型也可使用。
切换模型可能改变回答风格和额度消耗。没有依据认为，为避免容量错误就应始终选择最高档模型。移交复杂实现或设计任务时，应通过差异和测试检查新输出。本站的GPT Sol 代际比较与选择指南也可作为参考。
4. 如果应用本身卡死，应单独排查响应问题
应将容量错误与输入框、终端或应用界面无响应区分开。对于看似卡住的聊天，官方故障排查指南建议检查是否有待批准操作，用简单命令测试终端，并在新聊天中尝试一个小请求。
如果终端仍卡住，指南建议等待活跃聊天结束后再重启应用。这是针对一般无响应状态的建议；它并没有说重启能解决服务器端容量不足。先确认其他仍在运行的聊天状态。
如果在新聊天中继续，简要说明目标、工作文件夹、已完成修改和剩余任务。不要只发送“继续”，并假设新聊天能看到之前的完整对话。新聊天使用的是同一服务，因此无法保证避开容量错误。
再次发生时应该记录什么
如果错误反复出现，保留便于后续调查的证据。在反复更改设置之前先做记录，更容易厘清失败时的条件。
联系支持与记录重复错误的检查清单
- 错误发生的日期、时间和时区
- 使用 Codex 的位置：应用、CLI 或 IDE，以及版本
- 所选模型、推理强度和速度设置
- 完整错误消息及紧接着发生错误前的操作
- 当时的剩余额度、重置时间和官方故障信息
- 等待重试后的结果，以及其他模型是否也出现相同错误
根据现有记录，可能无法确定设置中所选模型就是失败请求实际使用的模型。如果只记录了可见设置，就只描述这一证据。同样，切换模型后立即恢复也不能证明切换解决了问题：服务可能恰好同时恢复。
官方指南说明，可在消息输入框中输入 / 来提交反馈。从现有聊天提交时，可以选择是否共享对话。在发送日志或截图前，应移除 API 密钥、电子邮件地址、私人对话和公司内部信息。无需公开密钥值或身份验证文件本身。
包含日期、模型、准确消息和显示剩余额度的报告，比只说“总是出错”更有帮助。如果取得了 HTTP 状态码或请求 ID，也可帮助支持人员调查，但不要用猜测填补缺失信息。
这台电脑上的调查结果与未知事项
用户通过截图报告多次出现错误后，AI Arte 让这台电脑上的 Codex 于2026年10月1日对用量和本地日志进行只读调查。Windows 应用包版本为 26.928.3736.0。我们未确认错误发生时是否安装了同一版本。
已核实
执行历史保存了相同的完整消息及 serverOverloaded。公开代码也将其归类为服务器过载。
未能确定
过载的原因、当时的剩余额度、HTTP 状态码，以及失败请求实际使用的模型。
最初搜索未在常规日志数据库的32,737条记录、15个桌面日志文件或143个已更新的会话记录文件中找到该错误。读者质疑结果后，我们检查了其他存储位置，并在独立的执行历史数据库中找到了失败记录。最初的搜索范围不足。
在追加调查时，执行历史中的6,781轮对话有35轮失败。整个记录期间，有13轮包含相同完整错误消息及 codexErrorInfo: serverOverloaded。其中，12次发生于2026年9月30日22:10:01至10月1日00:24:55（JST）之间，涉及5个聊天。用户附上错误截图的聊天中，也有9月30日22:15:06、22:57:58、23:12:31和23:24:38的4条失败记录，消息与分类一致。这些时间是失败对话轮次记录的完成时间，不是截图时间。数据反映的是这台电脑的记录，并非所有用户的错误率。
应用内附带的 Codex CLI 版本为 0.159.2。在对应公开标签的错误定义中，完整消息对应 ServerOverloaded，与额度耗尽分属不同分类。流处理代码将 server_is_overloaded 转换为过载错误，而显示转换代码将其连接到本文开头的完整消息。也存在将带有同一错误代码的 HTTP 503 响应转换为此错误的路径，但错误也可能在流内部到达。因此，显示的消息不能证明响应一定是 HTTP 503。
已确定的是，这些失败被归类并保存为服务器过载。记录并未说明是否涉及实际 GPU 短缺、请求路由或容量控制问题。4条失败记录的附加详情为空，没有保存 HTTP 状态码。最初调查时，周额度剩余31%，且允许正常使用。但这并非错误发生时的剩余额度，也未能确定这些失败请求实际使用的模型。
对于身份验证错误，9月25日另一场故障的官方根因报告说明，误判并撤销内部服务凭证，导致通过 ChatGPT 登录的 Codex 出现401和502错误。这并不能证明本文调查的过载错误原因。不要将官方已解释的内部身份验证故障，与当前过载错误混为一谈。
本次调查没有更改模型或订阅，没有使用付费重置，也没有删除凭证。我们还未刻意通过快速重复请求复现问题，因此没有关于哪些操作能恢复服务的实验比较。本文将官方已核实的故障案例与单台电脑上的观察分开处理。
总结：先分清错误，再决定处理方式
出现“Selected model is at capacity”时，先保存提示词、稍等一会儿，再检查故障信息和用量。紧急工作可以考虑其他可用模型，但某些故障会影响多个模型。仅凭容量错误，没有依据要求额外花钱、购买付费重置或删除凭证。
401 应检查身份验证，thread not found 应检查聊天状态，额度提示则应检查用量。再次发生时记录时间、完整消息、模型和剩余额度，比在原因不明时更改设置更有助于后续调查。
常见问题
Pro 订阅也会遇到吗？
本文用户报告，在 Pro 订阅下也出现了相同消息。不过，单个报告无法确定不同套餐的故障发生率。官方故障记录没有表示 Pro 不受影响。应将订阅剩余额度，与模型当时能否接受工作分别检查。
额外点数或付费重置能解决吗？
我们未找到官方证据证明这些操作能解决这一容量错误。额外点数等机制针对的是自己的用量额度。先检查是否真的达到限制，不要将恢复额度与容量错误恢复混为一谈。
为什么切换模型后还会出现？
官方故障记录描述过多个模型出现相同消息。换一个模型仍出错，本身不能证明电脑或账号故障。检查故障信息与剩余额度，并记录重试结果。公开文档未指出任何保证避开该错误的模型。
应该重启应用或打开新聊天吗？
我们未能确定哪一项是必要操作。这些方法可以帮助排查应用或终端无响应，但不能保证解决服务端容量问题。先检查其他进行中的工作，保存提示词、修改内容和剩余任务，再作决定。
