Codex 429 Too Many Requests 完整排查指南：三类根因与六种解法

Codex报出"exceeded retry limit, last status: 429 Too Many Requests"是2026年开发者社区反馈最集中的问题之一，相关GitHub Issue（#9135、#9748、#11508等）累计数百条讨论，r/codex版块多次出现置顶帖。这条错误本质上只有三种根因：配额耗尽（5小时窗口或周限制触及上限）、并发子Agent意外瞬间压榨配额、以及短暂的服务端限速（配额显示正常但仍429）。三种情况的处理方式完全不同，混淆后会浪费大量时间。本文从错误日志的区分、根因的定位，到六种经验证的解法逐步拆解，并附BYOK模式下接入自定义API端点绕过订阅配额的完整配置方法。

错误长什么样：四种形态

Codex产生429相关错误时，日志和UI里会出现以下几种形态：

形态一：exceeded retry limit（最常见）

ERROR: exceeded retry limit, last status: 429 Too Many Requests, request id: 9bd33f31fd269bb1-HNL

输出，意味着Codex已内部重试多次（默认指数退避），全部失败后放弃本次请求。

形态二：API层直接429

error=http 429 Too Many Requests: Some("{
  \"error\": {
    \"message\": \"You've exceeded the rate limit, please slow down and try again after 60.616292 seconds.\",
    \"type\": \"invalid_request_error\",
    \"code\": \"rate_limit_exceeded\"
  }
}")

错误响应体里的 message 字段包含等待时间，这是最有用的诊断信息。

形态三：配额耗尽提示

ERROR: exceeded retry limit, last status: 429 Too Many Requests
Usage: 5h limit [████████████████████] 100% (resets in 4h 32m)

UI显示5小时窗口已满，这是配额耗尽，而非服务端限速。

形态四：配额显示正常但仍429

5h limit:   [███████████████████░] 96% left (resets 17:16)
Weekly limit: [███████████████████░] 95% left (resets 11:33)

这是最令人困惑的情况——用量显示充裕，却仍然429。这对应的是服务端短暂限速（见下文根因三）。

三类根因的区分

根因一：5小时窗口或周配额耗尽（最常见）

Codex的限速体系在2026年4月9日更新后改为按推理时间计费，不再按消息数计。不同套餐每5小时窗口内的可用推理时间：

（数据来源：OpenAI社区帖子 "Understanding the New Codex Limit System After the April 9 Update"，2026年4月10日）

关键点：Business套餐描述为"比Plus少60%"，实际推理时间约为Plus的31%，每分钟消耗速度是Plus的3.2倍。

在5小时窗口之外，还有周限制（Weekly Cap）。多次触发5小时窗口可以累计耗尽周配额——有用户报告Pro账户周配额在一天内从67%跌至45%，背后原因是并发子Agent（见根因二）。

判断方法：运行 /status 命令，查看5h limit和Weekly limit的百分比；或访问 chat.openai.com 的用量页面确认实际消耗。

根因二：并发子Agent瞬间压榨配额

GitHub Issue #9748（2026年1月23日，31条评论）记录了一个极端情况：

同时启动约6个并发子Agent（用于并行代码库探索），整个Pro套餐的5小时配额立即被清空至100%。

这与按实际token计费的预期完全不符。当时的行为是：每个子Agent在启动时以推理时间方式预留配额，而不是根据实际完成量计费，导致6个并发Agent相当于同时"占坐"了6份推理时间配额。

相关问题在2026年初陆续报告（#9748、#11508），OpenAI在此后的更新中对子Agent的配额扣减逻辑进行了调整，但激进使用并发子Agent仍是触发快速配额耗尽的主要路径之一。

判断方法：在429发生前是否有多个子Agent并行运行？单次任务是否显式使用了 spawn_agent 或类似工具？

根因三：服务端短暂限速（配额充裕但仍429）

Issue #9135（2026年1月13日）描述了另一种模式：

在5小时窗口快结束时，Codex突然开始429——但用量显示还有约61%剩余，每次重试等待约60秒。持续约15分钟，直到5小时窗口重置后恢复正常。

多位用户在评论中确认相同现象：配额显示95%-96%剩余，仍然429。OpenAI方面最终回复"已处理底层原因"，但类似情况在此后仍有零散报告。

这类429的特点：错误持续时间短（通常10-30分钟）、等待时间固定（60-90秒/次）、配额显示正常、重置窗口后自动恢复。通常是服务端在高峰期主动限速，与用户配额无关。

六种解法

解法一：等待5小时窗口重置（配额耗尽时）

最直接的方案。/status 输出会显示窗口重置时间：

# 在Codex 内运行
/status

输出样例：

5h limit:   [████████████████████] 100% (resets in 4h 32m)
Weekly limit: [████████████████░░░░] 78% left (resets Thu 08:00)

如果周配额也已接近耗尽，则需要等到周重置时间（通常为账户注册时间的周滚动窗口）。

解法二：降低推理级别（减少每次请求消耗）

推理级别直接影响每次请求消耗的推理时间。在 ~/.codex/config.toml 里设置：

model = "gpt-5.4-codex"
reasoning_effort = "low"   # 可选值: low / medium / high / xhigh

可选值：low / medium / high / xhigh。从 xhigh 降到 medium 在大多数日常编码任务中质量差异有限，但配额消耗可降低约60-70%。

或者在单次调用时临时覆盖：

codex --reasoning-effort low "重构这个函数"

解法三：限制并发子Agent数量

如果任务设计里有多个并发子Agent，将并发数限制在2-3个以下，或改用顺序执行：

# 不推荐（触发大量并发）
"并行分析这10个模块，每个模块一个子Agent"

# 推荐（顺序处理）
"逐一分析这10个模块，每次只处理一个，完成后再进行下一个"

如果必须并发，在任务描述里明确限制：

"使用最多2个并发子Agent完成以下任务..."

解法四：等待服务端限速自动恢复（配额显示充裕时）

如果 /status 显示配额充裕但仍然429，通常不需要任何操作，等待10-30分钟即可：

# 确认是服务端限速，不是配额问题
/status
# → 5h limit 和 Weekly limit 均显示 >50% 剩余
# → 则等待，不要反复重试（重试会加剧限速）

反复重试在服务端限速期间适得其反——Codex内部已有指数退避逻辑，额外手动重试只会让服务端更快触发更长时间的限速。

解法五：BYOK模式接入自定义API端点

Codex支持"Bring Your Own Key"模式，绕过OpenAI订阅配额，直接使用其他API端点。配置方式：

# ~/.codex/config.toml（BYOK模式，具体字段名以官方文档为准）
model = "deepseek/deepseek-v4-pro"
provider = "custom"

[providers.custom]
name = "自定义提供方"
base_url = "https://api.your-provider.com/v1"
api_key_env_var = "CUSTOM_API_KEY"

启动时传入API Key：

export CUSTOM_API_KEY=sk-your-key
codex

对于需要同时使用多个国产大模型（DeepSeek、Kimi、GLM、MiniMax等）作为备选的团队，七牛云Token Plan（qiniu.com/ai/plan）提供4家厂商25个模型的统一订阅接入，一个API Key覆盖多个模型端点，在Codex频繁遭遇OpenAI订阅限速时可作为直接可用的备选提供方。

解法六：拆分长任务，避免单次长会话

Codex的用量按会话内实际推理时间累积。一个运行4小时的单次会话和4个各运行1小时的独立会话消耗相同的配额，但后者每次任务结束后可以根据剩余配额决定是否继续，而不是在单次会话里耗尽后才发现。

实操建议：

# 长任务前先检查配额
/status

# 将大任务拆分为阶段性检查点
"完成第一步后停下来，等我确认结果再继续"

自查流程：发生429后30秒定位根因

1. 运行 /status
   ├─ 5h limit 100% → 等待窗口重置（根因一）
   ├─ Weekly limit 100% → 等待周重置（根因一）
   ├─ 两者均充裕（>50%）→ 继续步骤2
   └─ 接近耗尽（<10%）→ 等待或降低reasoning_effort

2. 回顾刚才的操作
   ├─ 刚启动了多个并发子Agent → 等待+限制并发数（根因二）
   └─ 单个任务常规使用 → 服务端短暂限速（根因三），等10-30分钟

3. 看错误消息里的 retry-after 时间
   ├─ retry-after 60-90秒，持续出现 → 根因三，等待即可
   └─ retry-after >1小时 → 配额问题，检查用量面板

FAQ

429错误会自动重试吗，还是需要手动重新运行？

Codex 内置了指数退避重试逻辑，每次429后会自动等待再重试，直到超过最大重试次数后才报"exceeded retry limit"。也就是说，你看到的"exceeded retry limit"已经是多次重试全部失败的结果，手动立即重试通常无效——应先等待至少retry-after指定的时间（通常60秒），或直接等待限速周期结束。

Pro用户也会碰到429吗？

会。Pro套餐的5小时窗口更大（约400分钟推理时间，为Plus的10倍），但高强度使用（特别是xhigh推理级别的长时间任务，或并发子Agent）同样可以在短时间内耗尽。Issue #11508记录的就是Pro用户在约1.5小时内耗尽全部5小时窗口配额的案例。

配额显示还有剩余为什么还会429？

这是根因三：服务端在高负载时对所有用户触发短暂限速，与个人配额无关。OpenAI的限速系统分为两层：用户级别的配额（5h窗口/周限制）和服务端全局的QPM/RPM限制。后者在高峰期可能临时限制配额仍充裕的用户。这类情况通常在10-30分钟内自动解除。

更换模型（比如用GPT-5.3代替GPT-5.4）能缓解429吗？

一定程度上有效。GPT-5.3在Plus套餐下的推理时间是GPT-5.4的1.5倍（60分钟 vs 40分钟），意味着相同任务消耗更少配额比例。但注意：GPT-5.3的每次推理如果更慢，绝对时间未必减少，只是"配额消耗率"降低。对于简单任务可以尝试；复杂推理任务降级模型可能需要更多轮次完成，最终消耗反而相近。

总结

Codex的429 Too Many Requests对应三种完全不同的情况：配额耗尽需要等待重置，并发子Agent压榨配额需要限制并发数，服务端短暂限速只需等待10-30分钟。三种情况处理方式不同，关键诊断工具是 /status 命令和错误消息里的 retry-after 值。长期解法是降低 reasoning_effort、拆分长任务、在订阅配额不足时接入BYOK自定义API端点。2026年4月9日的计费模式更新将配额体系从消息数改为推理时间，这是当前大量429报告的直接背景——理解这一机制才能准确预测配额消耗，而不是在任务进行中遭遇意外中断。

本文数据来源：GitHub Issues #9135、#9748、#11508（openai/codex，2026年1-2月）、OpenAI社区帖"Understanding the New Codex Limit System After the April 9 Update"（2026年4月10日）、r/codex版块用户报告（2026年6-7月）、OpenAI官方错误代码文档（developers.openai.com，2026年）。

延伸阅读

• GitHub Issue #9748（并发子Agent压榨配额）：https://github.com/openai/codex/issues/9748

• GitHub Issue #9135（配额显示充裕仍429）：https://github.com/openai/codex/issues/9135

• OpenAI Codex用量与限速说明：https://developers.openai.com/codex/usage-limits

• OpenAI社区：April 9限速系统更新说明：https://community.openai.com/t/understanding-the-new-codex-limit-system-after-the-april-9-update/1378768

• 七牛云AI编程工具接入配置