# Codex 报 429 并停止重试：先找限流归属，再恢复任务

> 遇到 exceeded retry limit, last status: 429 Too Many Requests 时，先区分 Codex 用量窗口、OpenAI API 项目限制与第三方网关，再执行匹配的恢复动作。

- Source: https://www.aifreeapi.com/zh/posts/codex-rate-limits
- Language: zh
- Published: 2026-08-21
- Updated: 2026-08-31
- Publisher: AI Free API (https://www.aifreeapi.com)

`exceeded retry limit, last status: 429 Too Many Requests` 包含两个不同层次的信息：Codex 客户端已经多次尝试，最后一次服务端响应仍是 429，于是客户端停止了；它没有告诉你究竟是哪一种额度、哪个时间窗口或哪一家 provider 拒绝了请求。

因此，继续点重试通常不是第一步。先暂停新的并发任务，保留当前文件和 working tree，再记录错误原文、出现时间与时区、request ID（如果界面提供）以及当前使用的 Codex 入口。你需要先找到“这次请求算在谁的账上”，才能知道该等待、降并发、补额度，还是查第三方网关。

## 先读懂错误，而不是把两个 limit 当成一个

`retry limit` 是客户端的自动重试次数上限。它描述 Codex 已经做过什么，不是一种新的账户配额。`last status: 429` 才是最后一次请求得到的 HTTP 状态，但 429 也不是唯一根因标签。

OpenAI 当前的 [API 错误代码说明](https://developers.openai.com/api/docs/guides/error-codes#api-errors)至少区分这些 429：短时间请求过快、预付 credit 余额耗尽、organization 或 project 的 spend limit、organization usage limit。错误 body 中的 `error.code` 比宽泛的 `error.type` 更能说明计费类原因。只看状态码就断言“并发太高”或“钱用完了”，证据都不够。

还有一个经常被忽略的边界：429 可能不是由 OpenAI 直接返回。如果 Codex 配置了自定义 `base_url`、模型路由器、企业网关或其他 provider，最后的 429 可能由中间层产生，也可能被中间层改写。此时 OpenAI 账户还有余额，并不能证明这条路由仍有容量。

## 用一分钟确认请求属于哪条路线

不要同时登出、换模型、换网络、切账号和改配置。一次改变五个变量，即使问题消失，也无法知道是哪一个动作生效。先按当前状态完成归属检查。

| 当前请求路线 | 最有用的现场证据 | 不应混用的结论 |
|---|---|---|
| ChatGPT 登录的 Codex app、CLI 或 IDE | 当前账户/工作区、Codex Usage Dashboard、可见 5 小时与周窗口、reset、credits、CLI 的 `/status` | API Dashboard 的余额不能解释 ChatGPT 方案窗口 |
| OpenAI API key 直连 | API error body、`error.code`、`Retry-After`、organization/project、Limits 与 Billing | ChatGPT Plus/Pro 剩余量不能给 API 项目增加容量 |
| 自定义 provider 或 gateway | 实际 `base_url`、provider 日志、响应 headers、provider 余额与状态页 | OpenAI 官方 reset 时间不能替代第三方合同 |
| 受管工作区 | workspace 名称、管理员可见 credits/限制、当前 seat 与策略 | 个人账户订阅不一定改变工作区拥有的请求 |

OpenAI 当前的 [Codex pricing 与用量说明](https://learn.chatgpt.com/docs/pricing#where-can-i-see-my-current-usage-limits)把 Usage Dashboard 作为账户当前限额的主要入口，并说明 Codex CLI 可用 `/status` 查看剩余限额。客户端版本、认证方式、计划与 rollout 不同，字段可能不同；看不到某个字段不等于对应限制不存在。

如果你的问题是“切到 B 账号仍看到 A 的限制”，请改走[跨账号 Codex 限额排查](/zh/posts/codex-limits-shared-across-accounts)。那是身份、工作区、API organization 或本地旧登录态的归属问题，不应靠连续重试验证。

![不同 429 的匹配恢复表：从请求归属、错误详情和时间窗口选择等待、调整额度、遵循 provider 指示或查看服务事件，并用小任务验证结果](https://www.aifreeapi.com/posts/zh/codex-rate-limits/img/recovery-by-limit.webp)

## “明明有额度”先问是哪一种额度

“有额度”可能指周用量还有百分比、5 小时窗口已恢复、还有 ChatGPT credits、API 账户有余额、project spend limit 未满，或第三方 provider 钱包还有金额。这些不是同一只表。

OpenAI 的[token 与 credits 说明](https://learn.chatgpt.com/docs/pricing#what-are-tokens-and-credits)指出，credits 消耗会随模型、上下文、推理和工具变化；在适用的计划中，included limits 用完后，可用 credits 可以继续工作。当前说明还明确：ChatGPT 计划上的本地消息与云端任务共用 5 小时窗口，并可能另有周限制。这说明两个外观看似相同的任务可能消耗不同，也说明“周用量还有”不能自动排除更短窗口、工作区规则或另一条计费路线。

最小的对账记录不需要截图整张账单。记录以下项目就够用：

- 当前入口：桌面端、CLI、IDE 或其他客户端；
- ChatGPT 登录、API key，还是自定义 provider；
- 账户或工作区标签，敏感标识打码；
- 模型、推理强度、Fast 状态与是否启用 subagents；
- 可见 usage、reset 或 credits 状态；
- 同时运行的本地、云端、定时和后台任务；
- 错误原文、时间、时区与 request ID。

不要把 API key、access token、OTP、完整邮箱、完整 workspace/project ID、私有仓库内容或完整账单截图放进支持工单。

## 不同 429，需要不同恢复动作

### 短时间请求速率或临时节流

对 OpenAI API 的 request-rate 429，官方建议降低请求速度；若响应包含 `Retry-After`，至少等待该时长。没有该 header 时，自定义 HTTP client 应使用带随机抖动的指数退避，并同时限制尝试次数和总重试时间。OpenAI 官方 SDK 已会自动重试符合条件的 rate-limit 错误并在存在时遵守 `Retry-After`，因此不要再无条件套一层重试循环。失败请求本身也可能计入分钟限额。

Codex 已经显示 `exceeded retry limit` 时，客户端自己的有界重试已经结束。此时不要在多个窗口同时手动重发同一个大任务。先停止并发或 subagents，等待可见 cooldown/reset 或 provider 指示，再用一个范围明确的小动作验证恢复。若小动作成功，再逐步恢复负载；不要立刻把所有后台任务一起放开。

### ChatGPT/Codex 使用窗口或 credits

如果当前是 ChatGPT 登录，优先看同一账户或工作区的 Usage 状态，而不是 API Billing。记录 5 小时与周窗口分别显示什么、reset 时间是否可见、是否存在可用 credits，以及是否有其他 eligible agentic 工作正在消耗同一池。

窗口已经明确触顶时，安全选择是等实际显示的 reset，或在账户确实提供且你愿意付费时使用合法 credits。换成较低消耗模型、缩短上下文、减少工具和拆小任务可以改善恢复后的可预测性，但不能让一个已经触顶的窗口凭空恢复。

### API 余额、spend limit 或 usage limit

直连 OpenAI API 时，必须读取错误 body 的 `error.code`。`credit_balance_exhausted`、`organization_spend_limit_exceeded`、`project_spend_limit_exceeded` 与 `organization_usage_limit_exceeded` 都可能是 429，但它们不是靠多等几秒就能修好的同一种问题。

OpenAI 官方明确说明：对 credit、spend 或 usage quota 错误继续重试不会恢复 API 访问。你需要等待相应周期重置，或由有权限的 owner 调整 credits/limit；具体动作取决于错误 code 与 organization/project 归属。不要通过轮换 key 来掩盖同一项目的限制。

### 第三方 gateway、router 或 provider

只要 `base_url` 不是 OpenAI 官方地址，就先检查该 provider 的响应与合同。它可能有独立 RPM/TPM、余额、模型池、并发限制、上游故障映射或自己的 request ID。把第三方 429 拿到 OpenAI Usage 页面解释，通常只会得到互相矛盾的数字。

验证时只改一项：暂时降低并发，或按 provider 的 `Retry-After` 等待，然后用同一认证和一个小请求复测。若 provider 日志把另一种上游状态改写成 429，应以它能提供的原始 upstream 证据为准；没有原始证据时，只能报告“该路由返回 429”，不能替它写根因。

### 可能的服务事件

查看 [OpenAI Status](https://status.openai.com/) 是否有与当前产品、时间和地区重合的已确认 incident。状态页存在匹配事件时，按官方时间线等待并保留 request ID；没有公开事件，只能说明“目前没有匹配的公开确认”，不能证明你的账户、地区、provider 或单条路由都健康。

## 让下一次尝试具有诊断价值

![小任务验证闭环：停止重复进程，固定账户、路由和模型，记录前后用量与请求 ID，再按成功或继续 429 决定逐步恢复或返回排查](https://www.aifreeapi.com/posts/zh/codex-rate-limits/img/bounded-recovery-test.webp)

恢复条件发生变化后，不要直接重跑原来的长任务。先把当前修改保存在工作区，确认没有遗留进程或重复云任务，然后选择一个几分钟内能结束、输入和输出边界清楚的动作。开始前记一次 usage/provider 状态，完成或失败后再记一次。

这次验证应保持账户、工作区、provider、模型与模式不变。若小任务成功而大任务再次 429，问题更可能与负载、并发、上下文或短窗口有关；若小任务立即得到相同 429，继续提交大任务不会增加信息，应回到 quota/provider/status 分支。

如果相同条件下仍能稳定复现，提交一个小而完整的证据包：客户端与版本、认证路线、provider、模型与模式、错误原文、时间戳与时区、request ID、可见 reset/usage、并发活动、最短复现步骤，以及已排除的共享工作。对 API 请求再加脱敏后的 `error.code` 和相关 rate-limit headers；不要上传 Authorization header 或请求正文中的私密数据。

最重要的顺序不是“多试几次”，而是：先停住，确认谁拥有这次请求，读取它真正提供的错误细节，再让一次小复测回答一个问题。这样即使仍需等待或联系支持，你也不会用错误的额度表解释故障，更不会让重试风暴把一个短暂 429 变成更长的中断。