Codex 报错 429 且重试耗尽：按账户与上游定位问题

Codex 停在下面这行错误时，先暂停重复发送同一个任务：

text
exceeded retry limit, last status: 429 Too Many Requests

这行信息只确认了两个结果：客户端已经用完这一轮重试机会，最后收到的 HTTP 状态是 429。它没有指出是谁拒绝了请求，因此不能单凭这一行就认定是 ChatGPT 套餐额度、OpenAI API 速率限制或服务故障。

有效的恢复路径不是猜一个等待时长，而是先确认三件事：问题发生在 Codex App 还是 CLI；当前使用 ChatGPT 登录还是 API key；模型请求实际发往 OpenAI，还是经过自定义提供商或网关。确定这条链路后，再查看与它对应的用量和错误证据。

先保留现场，再做一次受控复现

立即记录失败时间和时区、Codex 版本、App 或 CLI、操作系统、认证方式、模型名称，以及界面或响应中出现的 request ID。如果还能安全地复现，只做一次较小请求，并观察它是成功、立即返回 429，还是等待多次重试后失败。

不要为了取证公开 API key、访问令牌、完整账户标识、未脱敏的配置文件或包含业务内容的整份日志。错误响应中如果有错误 code、type、message、Retry-After 或请求 ID，只保留判断所需的字段。

一次受控复现还应回答这些问题：

• 只有当前会话失败，还是新会话也失败？
• 只有某个模型失败，还是可用模型都失败？
• 单个短请求能否成功，并发任务是否更容易失败？
• 同一认证路径下的其他请求，在相近时间是否成功？
• 问题是偶发一次，还是持续跨越多个重试周期？

这些现象只能帮助缩小范围，不能单独判定根因。例如，所有会话同时失败更像账户级或上游级问题，但本地配置、网络出口和共享网关也可能造成同样表现。

先找出请求实际走哪条路径

同一个 Codex 界面背后可能对应不同的账户与上游。核对错误时，必须使用与实际请求路径匹配的证据；检查错账户或错平台，得到的“还有额度”没有诊断价值。

如果无法确认认证方式，可先查看当前 Codex 的登录状态和配置，但分享截图或配置前必须脱敏。自定义模型提供商可以拥有独立的 base_url、密钥以及请求重试设置；这意味着“Codex 显示 429”并不等于“OpenAI 返回 429”。Codex 当前支持这些配置项，详见官方配置参考。

配置参考中的默认 HTTP 请求重试次数和 SSE 流重试次数分别是 4 和 5，但这只是当前文档给出的默认配置，不代表你的有效配置，也不能据此反推出 429 的来源。先确认请求发往哪里，再检查那个上游。

ChatGPT 登录路径：核对 Codex 账户用量

当前 Codex CLI 提供 /usage，可查看日、周或累计的账户 token 活动；未使用 Codex service account auth 时，该命令会要求登录。命令的适用方式以官方 /usage 文档为准。

/usage 是账户侧信号，不是某次请求的完整诊断报告。它能帮助判断当前 ChatGPT 认证路径是否接近或触及用量边界，但不能说明第三方 provider 或 Platform API 组织的限制，也不能独自证明某一个 429 的根因。

不要用“已经发送了多少条消息”估算剩余量。Codex 的消耗会随模型、任务大小与复杂度、本地或云端执行、上下文、推理、工具、检索和缓存而变化；适用的 ChatGPT 计划中，本地消息与云端聊天共享五小时窗口，并可能有额外周限制。具体规则会变化，应以当前 Codex 计划与用量说明和账户内显示为准。

如果账户界面明确显示用量已用尽，停止无边界重试，按账户显示的恢复条件处理。如果用量看起来仍可用，则保留该截图的时间点，并继续核对失败范围、模型和服务状态；“看起来未超限”只是排查证据，不足以证明服务端一定没有账户级限制。

API key 路径：先读 429 的具体类别

OpenAI Platform API 的 429 不是单一原因。官方错误文档将它区分为请求速率、余额耗尽、组织或项目支出限额，以及组织用量限额等类别。应优先读取错误 payload 中更具体的 code 和 message，并对照OpenAI API 错误分类。

只有临时速率限制适合通过控制并发、降低请求频率，并在响应带有 Retry-After 时至少等待相应时长后再重试；没有该响应头时，可使用带随机抖动的指数退避。无论采用哪种方式，都应限制最大尝试次数和总等待时间。余额耗尽、支出上限或组织用量限制需要处理相应账户问题，持续重试不会让它自行恢复，反而可能制造更多失败请求和噪声。具体退避边界见官方速率限制说明。

可以按下面的证据选择动作。每种情况都先看可观察信号，再决定何时停止：

响应明确提示临时速率限制

如果响应带有 Retry-After，故障层更接近 API 请求速率。降低并发，至少按响应头给出的时间等待，再做有限次数的重试；达到最大重试次数或总等待上限就停止。

响应明确提示余额、支出或组织用量限制

这类信号指向 API 账户或项目。核对发起请求的组织、项目、账单与限制设置；账户条件没有变化前不要继续重试。

并发任务失败，但单个短请求稳定成功

这更像请求形态或上游并发边界，但仍不是根因证明。先降低并发并记录成功与失败的阈值；如果降低并发后仍无规律失败，就停止试探并转查实际上游。

只有 Codex 最终错误行，没有详细响应

此时证据不足。保存失败时间、request ID 和最小复现结果，并确认认证方式与提供商；在拿到更具体的响应前，不要把裸 429 归因于某一种账户限制。

注意组织与项目归属。OpenAI API 的速率限制按组织、项目和模型等边界区分，核对时要确认执行请求的组织、项目与当前查看的限制页面一致；否则“控制台还有额度”可能只是看错了对象。以当前 API 限制说明为准。

自定义提供商或网关：沿真实上游继续查

如果配置了自定义 base_url，排查重点应转移到该提供商或网关。先确认运行时真正采用的提供商，而不是只看某份可能未生效的配置。然后核对：

1. 上游账户是否有独立余额、速率或并发限制；
2. 网关是否把上游错误转换成自己的 429；
3. 同一上游凭据的最小请求能否在 Codex 之外复现；
4. 网关日志是否能用请求 ID 对应到真实上游状态；
5. 客户端、网关和最终模型服务是否各自执行了重试。

多层重试会放大一次失败：客户端重试，网关再次重试，上游仍然限流，最后 Codex 只显示重试耗尽。此时盲目提高 Codex 的重试次数，可能只是延长失败并增加请求量。只有确认错误是短暂速率限制、且上游给出明确恢复信号后，才值得调整退避；账户、余额、权限或策略限制应先修正对应条件。

服务状态只能回答“是否有已知的聚合异常”

检查 OpenAI Status 时，要把失败时间与状态历史对齐，并查看 Codex 类别。2026 年 8 月 22 日核验时，页面显示 fully operational；但状态页同时说明，可用性指标汇总了不同套餐、模型和错误类型，个人可用性可能不同。

因此，当前绿色状态不能证明你此前没有遇到事故，也不能排除特定账户、区域、模型或请求路径的问题。反过来，社区中有人报告同样的错误，也只能证明表面症状相似。没有匹配的时间、认证路径、provider 和请求证据，就不能把个案当成当前故障公告。

如果状态页在失败时点明确记录相关事件，可以等待官方更新并减少重复请求。如果状态正常而问题持续，则回到自己的账户、上游和请求证据，不要仅靠刷新状态页等待。

什么时候可以恢复，什么时候应该升级

恢复动作应与已经确认的故障层一致：

• ChatGPT 账户明确触及用量边界：按账户显示的条件处理，并在恢复后用一个短请求验证。
• API 临时速率限制：降低并发或请求频率，遵守 Retry-After，用有限重试验证。
• API 余额、支出或组织限制：修正账户或项目条件后再验证。
• 自定义提供商：按该上游的限制、账单和状态处理，并确认网关没有改写错误含义。
• 已确认的服务事件：减少重复操作，关注与失败时点匹配的官方状态更新。

满足以下任一条件，就应停止猜测并准备升级：问题持续存在；所有新会话都失败；账户与限制页面没有给出解释；错误响应缺失或相互矛盾；状态页正常但最小请求仍稳定失败；或者问题只在某个版本、模型、操作系统或提供商组合中复现。

一份可用的升级材料应包含：

• Codex 版本、App 或 CLI、操作系统；
• 认证方式，以及模型和提供商；
• 首次与最近失败时间，包含时区；
• 单会话或全会话、单模型或全模型、串行或并发的复现范围；
• 已核对的账户用量、API 限制或提供商状态；
• request ID，以及脱敏后的最小错误片段；
• 可重复的最短操作步骤和预期结果。

官方故障排查资料列出了反馈入口、GitHub issue 渠道和日志位置，也提醒分享日志前检查敏感信息。提交前请按Codex 故障排查说明找到与你的版本和系统匹配的位置，只附上解释问题所需的最少内容。

最后再做一次验证：原认证路径、原提供商上的单个短请求是否恢复成功。如果只有切换账户、模型或上游后成功，应记录为“绕过了故障路径”，而不是已经证明原问题消失。只有原路径恢复且证据与原因相符，才能结束这次排查。