Codex 提示 429 Too Many Requests，反复重试还是失败；打开用量面板，额度却没有耗尽。这个现象并不矛盾：**429 既可能代表额度限制，也可能来自模型临时容量、请求速率、并发任务或中间网关。**

处理这类报错，需要结合完整错误内容和请求入口判断。仅凭“429”或“exceeded retry limit”，无法确定该充值、等待还是改配置。
![image](https://developer.qcloudimg.com/http-save/yehe-12868122/553912bd56824e98451e420226400066.png)

## 一、报错从哪里来？这几项信息决定排查方向

### 1. 确认当前使用的登录方式

Codex CLI 可以运行：

```bash
codex login status
```

确认当前是 ChatGPT 账号登录，还是使用 API Key。Desktop、IDE 扩展和另一个终端的认证状态，不要直接按当前 CLI 的结果推定。

**ChatGPT 订阅用量与 OpenAI API 余额是两套体系。** 给 API 账户充值不会恢复 ChatGPT 登录方式下的 Codex 额度；购买 ChatGPT 订阅也不等于为 API 账户充值。

配置过自定义 provider 时，还需要核对实际使用的 provider、base_url、配置 profile 和 CODEX_HOME。请求经过第三方服务，429 也可能由第三方返回。

### 2. 保留完整错误，而不只是最后一行

记录以下字段：

- HTTP 状态码以及 error.code、error.type、message。
- Retry-After 响应头，以及提示中的恢复时间。
- 使用的模型、客户端版本、报错时间和时区。
- 请求 ID；提交给支持人员时可用它定位请求。

截图和日志中遮住 API Key、Authorization、Cookie、认证文件内容及带密码的代理地址。不要把整个 auth.json 发给别人。

常见分支可以按下表定位：

| 报错内容或发生位置 | 主要排查方向 | 对应处理 |
| --- | --- | --- |
| usage_limit_reached、明确的额度恢复时间 | 订阅用量限制 | 等待恢复，或查看账户可用的额外用量选项 |
| turn_rate_limit_exceeded，且提示 Codex is at capacity | 模型临时容量 | 遵守重试时间、减少并发、切换可用模型 |
| rate_limit_exceeded，含 requests 或 tokens 限额 | API 请求速率或 token 速率 | 降低总请求速率和单次负载 |
| insufficient_quota、余额或支出限制提示 | API 账单与组织、项目限制 | 检查余额及对应限制 |
| 仅第三方网关报错 | 网关配额、凭据或错误转换 | 对照上游原始错误与网关日志 |
| 仅登录或用量刷新时报错 | 登录、查询接口限流 | 停止循环登录或高频轮询 |

不同入口的错误结构可能不同，以完整返回内容为准。

## 二、订阅额度用尽：核对恢复时间，别充错账户

### 1. 查看当前账户的真实用量

在 Codex CLI 中输入 /status，并查看账户对应的 Usage 页面，确认当前账号、工作区、剩余额度和重置时间。

不同套餐的限制不同，规则也会调整。不要把旧教程里的“五小时限制”套用到所有套餐；截至 2026 年 11 月 10 日的官方定价说明中，Pro 已没有五小时用量限制。账户界面和当期官方说明比旧文章中的固定数字更可靠。

如果错误明确提示 usage_limit_reached，处理方式是等待对应窗口恢复，或查看该套餐、工作区是否支持购买额外用量或使用工作区 credits。具体入口与资格以账户页面为准。

### 2. 降低后续消耗，但不要把它当成额度恢复

额度恢复后，可以缩小单次任务范围、减少重复读取大文件、控制并行任务，并在可选时使用消耗更低的模型或模式。

这些调整能减少之后的消耗，**不能把已经用完的额度补回来**。新建对话、删除历史记录或重装客户端，也不会重置服务端用量。

本地工作流如果支持改用 API Key，需要接受独立的 API 计费与速率限制。这个切换是更换计费路径，不是解除原有订阅限制。

## 三、额度有剩余：检查模型容量和并发任务

### 1. 出现 at capacity，按临时容量限制处理

当错误同时包含下面两项时：

```text
code: turn_rate_limit_exceeded
message: Codex is at capacity, please try again later
```

处理步骤如下：

1. 暂停连续发送和自动重试循环。
2. 返回了 Retry-After 时，至少等待它要求的时间；到期仍失败，需要继续退避，不能保证到点恢复。
3. 客户端允许选择其他模型时，切换一个当前可用的模型，再发起一次简短请求。
4. 查看 [OpenAI 服务状态页](https://status.openai.com/)；没有全局事故，也不能完全排除某个模型或局部服务的容量问题。
5. 持续无法恢复时，保留请求 ID、时间、模型和版本，向对应服务支持渠道提交。

临时容量限制没有统一的固定恢复时长。模型容量是服务端状态，本地配置无法保证修复。

### 2. 多窗口、多 Agent 同时运行，收缩到单任务验证

暂停 Desktop、CLI、IDE 扩展和云端仍在运行的其他任务，仅保留一个简单请求。确认恢复后，再逐步增加任务数量。

如果大量子 Agent 同时工作，可以在支持该配置的 Codex 版本中调整 config.toml：

```toml
[agents]
max_concurrent_threads_per_session = 2
```

已有 [agents] 段落时，在原段落中修改，不要重复创建同名表。保存后按客户端的配置加载方式重新打开会话。

这里的 2 是便于排查的保守设置，并非官方承诺的安全阈值。该项限制的是单个会话生成的并发子线程，不包含主线程，也不能限制其他独立会话的请求。旧配置名 max_threads 属于历史别名，新增配置使用当前文档中的名称更清楚。

**模型容量不足和并发过高可能同时存在。** 降低并发能减轻压力，但不能保证服务端立刻有可用容量。

## 四、API Key 登录报 429：速率与账单分别处理

### 1. RPM、TPM 超限，调整的是整体请求流量

API 的限制可能按组织、项目、模型或共享模型组计算。多个程序共用同一组织或项目时，不能只统计当前 Codex 窗口的请求。

检查返回内容和可用的限流响应头，确认受限的是请求数、token 数，还是其他维度。随后调整：

- 把批量任务放入队列，减少突发同时启动。
- 缩小无关上下文与不必要的输出，降低单次请求负载。
- 按响应头给出的恢复时间安排下一次请求。
- 使用有次数和总时长上限的指数退避，并加入随机抖动。
- 避免网关、SDK 和业务代码同时进行多层重试，导致一次操作被放大成大量请求。

返回 slow_down 时，即使统计值尚未达到已知 RPM、TPM，也可能需要降低流量爬升速度。降低请求速率后，逐步恢复负载。

同一项目下重新生成 API Key，不会凭空增加该项目的限额。增加重试次数也不会增加可用配额，失败重试还可能继续占用速率预算。

对流式输出或带工具执行的请求，重试前需要确认任务是否已产生文件修改、提交或其他副作用，避免重复执行操作。

### 2. insufficient_quota，查看更具体的错误代码

余额不足和速率超限都可能表现为 429，但处理方式不同：

| 错误代码 | 检查与处理 |
| --- | --- |
| credit_balance_exhausted | 检查实际调用组织的 API 余额；需要时在该组织补充余额 |
| organization_spend_limit_exceeded | 检查组织硬支出上限；在预算允许时调整，或等待对应周期恢复 |
| project_spend_limit_exceeded | 检查实际项目的硬支出上限及项目归属 |
| organization_usage_limit_exceeded | 检查组织获批的用量限制，按账户入口申请提高或联系支持 |

只看到较宽泛的 insufficient_quota 时，继续读取 message 和更具体的 code。不要把它直接当成可以靠几秒退避恢复的普通速率限制。

支出提醒与硬限制也要区分：提醒用于通知，硬限制可能直接阻止请求。核对当前组织和项目的实际设置，不要套用“预算永远只是提醒”的旧结论。

修改账单或限额后，确认设置已经生效，再进行一次小请求验证。不要用高并发任务检查充值是否到账。

## 五、经过第三方网关：保留上游错误，检查版本与冷却逻辑

### 1. 对照网关日志和上游返回

自定义 base_url、账户池或 API 转发服务，会增加一层可能产生 429 的位置。检查网关是否具有独立的余额、并发限制或模型配额，并对照同一时间点的上游错误。

排查重点包括：

- 上游的 error.code、message 和 Retry-After 是否被完整保留。
- 某个模型的临时容量限制，是否被错误标记为整个账户额度耗尽。
- 冷却期间是否仍在每隔几秒重复请求。
- 一次调用是否因账户轮换和多层重试，被放大成多次上游请求。

调整网关只能修正错误处理，不能增加上游容量或恢复已耗尽的额度。

### 2. CLIProxyAPI 检查是否包含对应修复

CLIProxyAPI 曾存在对 turn_rate_limit_exceeded 与 Retry-After 处理不当的问题：临时模型容量限制可能被当成额度问题，冷却与重试也可能偏离上游要求。

使用该工具时，可对照官方仓库确认当前构建是否包含[对应修复提交](https://github.com/router-for-me/CLIProxyAPI/commit/9a35fa12b2f388b235afec48736b7dfecfcc4de5)，然后通过其正式更新渠道升级。版本是否包含该修复，可通过发行说明和提交记录确认。

修复后的重点是按受影响模型处理临时容量，并保留上游重试时间。单纯把 request_retry 调高，或把最大重试间隔改大，不等于实现了正确的冷却逻辑。

如果只有某个授权条目持续失败，而其余条目工作正常，可以检查该条目的授权状态，并通过工具的正常授权入口重新授权。不要删除全部凭据，也不要把重新授权当成所有 429 的解决方案。

### 3. 错误显示修复不等于额度恢复

账户池工具可能把“全部账户额度耗尽”压缩成普通 429，掩盖恢复时间。例如 Magpie 的相关版本修复过此类错误显示问题。

这类更新的价值在于恢复准确的用量与重置信息；如果上游额度确实用完，仍然需要等待恢复或按账户规则补充可用用量。

## 六、登录和用量面板报 429：不要误判成模型不可用

### 1. 登录页面或设备授权接口被限流

如果 429 出现在登录、设备授权或令牌流程中，暂停脚本里的 logout/login 循环，关闭重复发起登录的终端与自动任务，并检查是否有多个实例在使用同一套认证资料。

按接口返回的冷却时间等待后，再通过官方正常流程登录一次。反复退出、删除认证文件和重新登录，会增加认证请求，可能让排查更困难。

登录接口恢复与模型推理恢复是两件事。登录成功后，用一个简短任务确认调用是否正常。

### 2. 只有用量查询失败，降低面板轮询频率

额度面板、状态插件或监控程序，也可能对查询接口请求过密。此时面板报 429，不等于发送任务的接口一定不可用。

暂停自动刷新，降低轮询频率，缓存最近一次成功查询结果，并让失败后的刷新遵守 Retry-After。不要通过每秒刷新来等待额度恢复。

如果正常任务可以运行，只是额度查询失败，排查重点放在查询接口和客户端显示上；如果两者同时失败，分别保留完整错误，避免用一个结论解释所有请求。

## 七、这些操作，不能代替对 429 的判断

- **换 IP、开启 TUN、关闭 WebSocket**：它们针对连接路径，不会直接补充额度、提高 API 速率上限或增加模型容量。
- **删除整个 .codex 或重装**：服务端限制不会因此清零，还可能丢失配置与认证状态。
- **不断新建对话**：无法重置账户用量，重复发送还可能增加消耗。
- **无限提高重试次数**：会放大流量，并掩盖余额不足、硬上限和临时容量之间的差别。
- **照搬未发布的配置项**：GitHub 中的功能建议不等于当前版本已经支持的参数，配置键应以对应版本文档为准。

更换模型、重启客户端或重新授权，可以是特定分支的排查动作；是否有效，需要看同一请求路径是否真正恢复，而不只是报错弹窗消失。

## 八、总结：让处理动作对上错误原因

Codex 429 的关键在于完整错误、实际登录方式和受限接口。订阅额度耗尽，核对恢复时间与可用用量；API 报错，分别检查速率、余额及组织和项目限制；额度有剩余却提示 at capacity，则控制并发、遵守冷却时间，并尝试当前可用的其他模型。

请求经过第三方网关时，还要确认它没有改写错误或忽略 Retry-After。把限流发生的位置找准，才能避免在换网络、重装和重复重试上消耗时间。


Codex 提示 429 Too Many Requests，反复重试还是失败；打开用量面板，额度却没有耗尽。这个现象并不矛盾：429 既可能代表额度限制，也可能来自模型临时容量、请求速率、并发任务或中间网关。

Codex 一直报 429 Too Many Requests？6 类原因与解决办法

Codex 报 429 Too Many Requests，不一定是额度用尽。文章按订阅用量、模型容量、并发、API 速率与账单、第三方网关及登录和查询接口，给出错误识别与操作步骤，并说明 Retry-After、配置调整和重试的适用范围。

人工智能

开发工具

运维

Codex 429报错需区分订阅额度、API速率、模型容量及网关限制。先核对登录方式和完整错误信息，订阅耗尽需等待恢复；API报错检查余额与RPM/TPM限额；at capacity则控制并发并遵守冷却时间。第三方网关需保留上游错误，避免盲目充值或重试。

代码解释

WebSocket

ChatGPT

GitHub

Agent

JSON

腾讯云双十一大促

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Codex 一直报 429 Too Many Requests？6 类原因与解决办法-腾讯云开发者社区-腾讯云

Codex 一直报 429 Too Many Requests？6 类原因与解决办法

Codex 一直报 429 Too Many Requests？6 类原因与解决办法

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐