Codex 提示 Selected model is at capacity，如何恢复工作

本文目录

Codex 出现 “Selected model is at capacity. Please try a different model.” 时，所选模型无法处理当前请求。先保存工作、检查服务状态与剩余额度，再尝试账户中可用的其他模型，或隔一段时间重试。仅凭这句话，无法认定套餐额度已经耗尽，也无法认定账户受到限制。

本文面向桌面 App、交互式 CLI、IDE 集成与脚本运行中断的情况，也说明所有模型都失败、状态页正常、以及 Codex 已提交外部任务时如何处理。

如果 Grok 或其他产品显示的原句是 “This model is temporarily unavailable”，先阅读按产品区分的模型不可用指南。相似措辞不能证明故障原因或恢复步骤相同。

核验日期为 2026 年 10 月 3 日。 客户端行为与账户权限会变化。命令按当前 OpenAI Docs核对，实际操作以当前版本的命令菜单和模型列表为准。

报错后先做这几步

保存错误与进度。 记录完整错误、模型、客户端版本、带时区的时间，以及最后完成的动作。保留原会话。
检查 OpenAI 服务状态。 阅读受影响组件和事件更新。以前已解决的故障不能说明今天的情况。
查看账户用量。 如果显示重置时间或明确的用量上限提示，应走额度排查。参照官方价格与用量说明，其中也说明 CLI 的 /status 可查看剩余限制。付费用户仍可能遇到容量错误。
有重试倒计时就按倒计时处理。 没有倒计时时，隔一段时间尝试一次，或选择当前账户可用的其他模型。不要同时启动多个相同任务。
只继续未完成的部分。 恢复前检查文件、运行中的命令和外部任务 ID。回复失败不代表此前动作都失败。

没有对所有账户都有效的“必须等十分钟”规则。连续返回相同错误时，停止反复发送，参考客户端计时、服务更新，或安排稍后再试。工作紧急时，先整理当前文件和剩余步骤，方便交接。

分清容量、额度、API 错误与连接失败

屏幕上的错误是排查起点。同一会话可能先后遇到多个问题，下一次错误也要完整阅读。

看到的情况	能说明什么	下一步
Selected model is at capacity	该模型未能处理本次请求，不能据此确定个人额度何时重置	查看状态与用量，尝试可用模型，保留会话
明确的用量上限提示或重置时间	账户可用额度需要处理	按当前账户的限制和重置信息操作
API HTTP 429	可能是请求频率、消费、用量或余额限制	先读响应正文和 code，再决定重试或处理账单
API HTTP 503 且 code 为 server_is_overloaded	所请求的 API 模型暂时过载	有 Retry-After 时遵守它，限制重试次数
凭据无效、权限不足、模型不存在	身份或访问范围需要排查	核对登录方式、工作区、API 组织与项目、客户端支持
连接失败、证书错误、超时	某次连接或请求失败，原因可能不同	检查网络与代理配置，同时确认操作结果
reviewer model 或 remote compaction 容量错误	某个辅助操作失败	记录具体操作，修改主模型未必能解决

OpenAI 在错误代码文档中解释了 API 的区别。表中的 HTTP 状态适用于 API 客户端，不能推断 Codex 横幅一定会展示同样的 HTTP 代码。

上下文百分比不等于账户余额。 上下文用量说明当前模型还能容纳多少对话信息；账户剩余额度回答另一件事。若两项都显示，保留各自的名称和数值。

订阅登录和 API 密钥登录也需要分开看。官方认证说明介绍了这两种访问方式。购买 ChatGPT 订阅不会自动改变某个 API 密钥所属组织的权限或余额。

恢复中断的代码任务，先确认已经做了什么

重新发送原指令之前，检查实际工作。Git 项目可以在受影响的 checkout 中执行以下只读命令。

git status --short
git diff --stat
git diff

需要时用 git diff --cached 查看已暂存的修改，同时检查新文件。普通 git diff 不包含未跟踪文件的内容。保存编辑器里尚未落盘的文本，并按项目习惯建立私人备份或检查点。不要为了清除容量错误而重置或清理仓库。

举个例子。 Codex 正在修改两个文件的校验逻辑，并运行相关测试。最终回复之前出现容量错误。第一个文件可能已经改完，第二个只完成一半，测试也可能仍在执行。直接再发“实现校验”会让下一轮从一个含糊的状态开始。

查看实际状态后，可以这样继续。

在当前会话继续刚才中断的校验任务。
先检查当前 diff 和最近一次测试输出。
保留我自己的修改，以及其他 agent 的修改。
只完成缺失的校验逻辑和相关验证。
已经启动的命令或外部任务，先查状态，不要重复提交。

这段指令能明确恢复范围，“continue” 本身不会增加模型容量。请求再次失败时，保留已保存的状态，按下一项排查处理。

OpenAI 的 agent 恢复文档也说明，失败的一轮可能已经修改文件或调用外部工具。这里借用的是先检查动作结果的原则，不能据此认为所有 Codex 客户端都会暴露该 API 的会话状态。

多人或多个 agent 共用 checkout 时，确认每个改动由谁负责。尽量在原 worktree 中恢复。新打开的目录即使名字相似，也可能处在另一分支，缺少被忽略的配置文件，或者依赖状态不同。

桌面 App 怎么恢复

保留出错会话，阅读最近的工具结果和审阅面板。如果当前会话支持切换模型，选择列表中提供的其他模型，再发送聚焦的继续指令。任务必须使用原模型的能力时，保存恢复笔记后稍后再试。

不要因为一个会话失败就强制重启仍有其他任务在工作的 App。如果界面无响应，先保存文本并确认运行中的工作。官方桌面排障指南建议先检查是否在等待批准，用基本终端命令确认环境，再考虑较小的聚焦会话；对于卡住的 App，重启前应等待活跃会话完成。

审阅面板可能包含 Codex 以外的人或工具产生的修改。看到 diff 只说明仓库有变化，不能说明每一行都是刚才失败的那轮写的。让 agent 继续编辑之前，先确认哪些文件属于当前任务。

只有一个会话失败时，先整理交接笔记，再尝试新会话。写清目标、checkout 路径、分支、已完成修改、跑过的测试和剩余工作。新会话可帮助排查，它不能保证修复容量，也不会自动接收全部旧上下文。

交互式 Codex CLI 怎么恢复

在交互式 CLI 中，/status 查看会话信息，/model 打开可用模型选择。选择列表中的替代模型，确认后再继续。这些是 CLI 输入框中的命令，直接输入普通 shell 或 ChatGPT 网页聊天并不是同一种操作。

如果终端会话已关闭，可以重新打开保存过的交互会话。

codex resume

从列表中选择受影响的会话。知道 session ID 时，可以明确指定。

codex resume SESSION_ID

SESSION_ID 是占位值。同一仓库有多个并行会话时，明确选择会话比假设“最近一个就是我的”更稳妥。官方命令说明也支持 codex resume --last，默认按当前工作目录选择最近会话，并支持在恢复时覆盖模型。参照 Codex CLI和恢复命令说明。

在恢复运行时切换模型，应使用当前身份和客户端可用的标识。保留原批准策略和 sandbox 设置，除非工作本身需要单独审查后调整。扩大文件访问权限不会提供推理容量。

IDE 集成和脚本运行

IDE 中先保存文本、检查 diff，再尽量从原会话继续。使用该集成提供的模型控制或命令菜单。VS Code 兼容扩展、JetBrains 与 Xcode 的原生集成有不同界面，CLI 命令不一定是 IDE 命令。官方 IDE 指南介绍了这些路径。

只有扩展无响应时，先记录版本和恢复笔记，再考虑重启这一界面。切换到 CLI 可以帮助识别客户端差异，不能证明同一个模型就会恢复可用。交接前核对目录、分支、身份以及旧会话是否能找到。

对中断的非交互运行，当前命令文档支持以下形式。

codex exec resume SESSION_ID

使用对应运行保存的 ID，先检查日志和已经产生的动作。不要把整个业务流程套进“直到成功就一直重跑”的循环。模型停止时，可能已经写过文件、开始导出，或提交任务。

自建 OpenAI API 客户端应区分可重试的过载或临时限流，以及凭据、账单错误。遵守有效的 Retry-After；自己实现退避时加入随机延迟，并同时限制尝试次数和总耗时。已有 SDK 的重试行为取决于版本和配置。参照官方限流说明。

所有模型失败，或者状态页正常时

做小规模的对照检查，每次只改变一个条件。

对照检查	有助于区分什么
同一客户端、同一账户，尝试列表中的一个替代模型	是否只影响原模型
保存交接笔记后，在同一客户端测试一个小的新会话	是否跟随原会话发生
使用另一支持的客户端，保持预期身份一致	是否与某个客户端或版本有关
查看账户用量和工作区权限	是否有独立的额度或访问问题

短请求成功，只能说明这一条请求成功，不能说明长任务或其他模型恢复了。对照失败也不能透露 OpenAI 内部路由，或者说明两个账户表现不同的具体原因。

模型缺失或不可访问时，官方工作区模型权限说明建议核对产品入口、登录方式、身份边界、访问控制与客户端支持。在配置中填写模型名称不会授予当前身份本来没有的访问权限。

如果错误明确写着 reviewer 或 compaction，把这一细节放进报告。不能推断降低主模型推理强度就能控制另一个辅助模型。

容易误导的“修复方法”

没看用量就充值。 额外 credits 可以延长符合条件的已耗尽额度，但这不能证明它能修复单独的容量故障。按账户实际显示的状态处理。
保证有效的 VPN 国家或非高峰时间。 改网络后请求成功，不能证明恢复由地区变化造成。有连接问题证据时，再调查网络配置。
删除认证、缓存、会话或项目文件。 可能丢失证据，也可能打断其他窗口。先明确本地或登录问题，再考虑针对性的修复。
为了清除容量报错改密码、关闭安全功能。 账户安全操作需要独立证据，容量横幅本身不足以支持这些动作。
没有停止条件的自动 continue 机器人。 可能重复已完成动作，掩盖持续失败。限制重试并检查实际进度。

如果 Codex 在运行 OwnerClue 线索流程

模型恢复和线索任务恢复需要分别处理。OwnerClue 搜索是异步任务。成功创建返回 HTTP 202 和 data.id，此时还没有完成的线索列表。

保存过 ID，就用有 leads:read 权限的密钥读取 GET /api/v1/leads/searches/{id}。queued 或 running 在 API 限制内继续轮询；completed 后读取结果或导出；failed 查看任务错误。不要因为 Codex 停止解释结果就再提交一次搜索。

如果创建响应丢失，先查看任务列表和原提交记录。未改变的请求重试时复用原 Idempotency-Key，不要生成新键。在恢复笔记中一起保存请求正文和键。这样可以减少重复提交，不能据此承诺每个失败请求都需要退款或取消。

参照 OwnerClue API 文档核对权限、分页、幂等与请求限制，也可在工作台查看已有任务。API 任务的生命周期可能长于控制它的 agent 会话。

持续失败时，准备一份可调查的报告

出错会话还在时，使用客户端反馈入口。OpenAI Docs 说明可选的会话分享与诊断提交方式。共享日志前先检查内容，不要包含 API 密钥、access token 或 auth.json 内容。

完整错误：
首次和最近发生时间，含时区：
客户端与版本，操作系统，相关 IDE：
所选模型与推理设置：
登录方式，预期工作区或 API 项目：
界面显示的剩余用量及各项名称：
可获取的 session、request 或 feedback ID：
失败的操作，是消息、review、compaction、工具还是导出：
一次替代模型或客户端对照检查的结果：
最后完成的动作与已保存工作：
实际影响与最小复现：

简洁、完整的证据比反复发同一提示词或直接认定原因更方便调查。按官方排障与反馈说明找到对应报告渠道。

常见问题

这是不是 Codex 额度用完了？

单独的容量横幅不能确认额度耗尽。查看真实账户用量和明确的限制提示。剩余上下文、消耗的 token、剩余套餐额度是不同概念。

应该等多久？

有重试计时或服务更新时按它们处理。没有适用于所有账户和模型的固定恢复时间。连续失败后，可以延后工作，或带证据报告。

切模型一定能解决吗？

不一定。列表中有合适替代模型时值得尝试。多个模型或辅助操作可能同时失败，访问范围也因客户端和身份而异。替代模型不能满足要求时，在交接中保留原模型需求。

Codex 会自动重试吗？

观察当前客户端。有倒计时可以按倒计时处理；已结束并显示错误的一轮，需要选择相应的新动作。本文不假设所有 App、版本和错误类别都具有相同重试行为。

新会话会恢复我的代码吗？

文件保存在 checkout 或任务环境。新会话不会重建丢失文件，也不会自动获得旧对话。先检查已保存工作，再提供交接信息。

这个错误能证明账户被标记了吗？

不能。多个账户持续表现不同，值得交由支持调查，但错误文字无法确定内部账户限制。报告可观察事实，避免假设原因。

来源与核验方法

恢复命令、身份与额度区别、API 重试原则按文中链接的 OpenAI Docs 在 2026 年 10 月 3 日核对。代码恢复与任务恢复示例是说明操作方法的情景，不代表已复现某次具体故障。我们比较了竞品指南和搜索结果中的讨论，吸收有效的诊断结构，排除没有充分依据的固定等待时间、路由解释和统一重试承诺。本文用于恢复工作，不提供实时服务状态。