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 错误代码说明至少区分这些 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 与用量说明把 Usage Dashboard 作为账户当前限额的主要入口，并说明 Codex CLI 可用 /status 查看剩余限额。客户端版本、认证方式、计划与 rollout 不同，字段可能不同；看不到某个字段不等于对应限制不存在。
如果你的问题是“切到 B 账号仍看到 A 的限制”，请改走跨账号 Codex 限额排查。那是身份、工作区、API organization 或本地旧登录态的归属问题，不应靠连续重试验证。
“明明有额度”先问是哪一种额度
“有额度”可能指周用量还有百分比、5 小时窗口已恢复、还有 ChatGPT credits、API 账户有余额、project spend limit 未满，或第三方 provider 钱包还有金额。这些不是同一只表。
OpenAI 的token 与 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 是否有与当前产品、时间和地区重合的已确认 incident。状态页存在匹配事件时，按官方时间线等待并保留 request ID；没有公开事件，只能说明“目前没有匹配的公开确认”，不能证明你的账户、地区、provider 或单条路由都健康。
让下一次尝试具有诊断价值
恢复条件发生变化后，不要直接重跑原来的长任务。先把当前修改保存在工作区，确认没有遗留进程或重复云任务，然后选择一个几分钟内能结束、输入和输出边界清楚的动作。开始前记一次 usage/provider 状态，完成或失败后再记一次。
这次验证应保持账户、工作区、provider、模型与模式不变。若小任务成功而大任务再次 429，问题更可能与负载、并发、上下文或短窗口有关；若小任务立即得到相同 429，继续提交大任务不会增加信息，应回到 quota/provider/status 分支。
如果相同条件下仍能稳定复现，提交一个小而完整的证据包：客户端与版本、认证路线、provider、模型与模式、错误原文、时间戳与时区、request ID、可见 reset/usage、并发活动、最短复现步骤，以及已排除的共享工作。对 API 请求再加脱敏后的 error.code 和相关 rate-limit headers；不要上传 Authorization header 或请求正文中的私密数据。
最重要的顺序不是“多试几次”，而是：先停住，确认谁拥有这次请求，读取它真正提供的错误细节，再让一次小复测回答一个问题。这样即使仍需等待或联系支持，你也不会用错误的额度表解释故障，更不会让重试风暴把一个短暂 429 变成更长的中断。
