AI Code With
开发教程

Codex 429 Too Many Requests 怎么解决？先分清限流、额度还是使用窗口

Codex 出现 429 不一定只是限流，也可能与额度、使用窗口或第三方网关有关。本文教你根据错误信息判断类型，并选择正确恢复方式。

9 分钟阅读
Codex 429 Too Many Requests 怎么解决？先分清限流、额度还是使用窗口

先对照：429 原因和处理方法

错误文本或 error.code原因正确动作重试有用吗
Rate limit reached for requests请求发得太快降低频率，遵循 Retry-After有用，但要等待
slow_down（rate_limit_error）请求量增长太快遵循 Retry-After，降低速率后逐步提升有用，但要慢慢加量
credit_balance_exhausted预付余额用完补充余额没用
organization_spend_limit_exceeded组织达到支出上限提高或取消组织支出上限没用
project_spend_limit_exceeded项目达到支出上限在项目设置里调整上限没用
organization_usage_limit_exceeded组织达到 OpenAI 分配的使用上限申请更高的使用上限没用
ChatGPT 登录提示"使用限制"订阅套餐的使用额度用完等待重置，或购买额外额度等到重置时间
第三方 Provider 返回 429服务商自己的限流、余额或上游渠道状态按服务商文档和后台状态处理视情况

先执行这几条，确认你属于哪一类：

bash
# 1. 确认认证方式：ChatGPT 登录还是 API Key
codex login status

# 2. 在 Codex 会话里查看剩余额度（ChatGPT 登录）
/status

前六行来自 OpenAI 错误码文档。最关键的一点：余额、支出和使用上限类的 429，不会靠不停重试恢复。OpenAI 官方文档原话是，重试账单、支出或配额类错误不会恢复 API 访问，需要先更新余额或上限。下面是详细的排查方法。

为什么"等一会儿再试"只对一部分情况有用

看到 429，很多人的第一反应是等几十秒再点一次。这招只对"请求太快"这一类有用。OpenAI API 的 429 至少要分成两大类：

  • 速率类：请求或 token 发得太快，等一等、降低频率就能恢复；
  • 账户类：余额耗尽、支出上限、使用上限，你等半小时也不会自己好。

官方还特别说明，对于账单相关的错误，要看 error.code 来确定具体原因，因为更宽泛的 error.type 可能都显示为 insufficient_quota。所以排查 429 的第一步，永远是拿到完整的错误信息。

拿到完整错误信息：按系统打开日志

很多时候，Codex 界面上只显示一句简短的提示，看不到完整的 error.code。这时可以借助日志。官方 Configuration Reference 说明，Codex 默认把日志写在 $CODEX_HOME/log 下，CODEX_HOME 默认是 ~/.codex。如果你显式设置了 log_dir，Codex 还会在那个目录里额外写一份明文的 TUI 日志 codex-tui.log。

临时为一次运行指定日志目录，官方给出的写法是：

bash
codex -c log_dir=./.codex-log

各系统查看默认日志目录：

macOS / Linux：

bash
ls -la ~/.codex/log

Windows PowerShell：

powershell
Get-ChildItem "$env:USERPROFILE\.codex\log"

在日志里搜索 429，通常就能找到完整的错误内容和 code。注意日志里可能包含你的提示词和项目信息，分享给别人排查之前，先检查并删掉敏感内容，尤其不要把 Key 一起发出去。

先确认你走的是哪条路线

运行：

bash
codex login status

然后按结果走下面三条路线中的一条：

  1. ChatGPT 登录：429 通常和订阅套餐的使用额度有关；
  2. OpenAI API Key：429 的含义以 OpenAI 错误码文档为准；
  3. 第三方 Provider：429 的含义由服务商决定。

三条路线的处理方法完全不同，不要把一条路线的经验套到另一条上。

路线一：ChatGPT 登录的使用额度

如果你用 ChatGPT 账号登录 Codex，看到"使用限制""稍后恢复"之类的提示，就按产品给出的额度窗口处理。不要因为它也叫"额度"或"限制"，就强行换算成 API 的 RPM、TPM，两套机制不是同一张表。

OpenAI 的 Codex 定价页说明了几点：

  • 能发多少条消息，取决于使用的模型、任务的规模和复杂度，以及在本地还是云端运行；看起来相似的任务，消耗也可能不同；
  • 页面给出的是 Plus 和标准 Business 套餐每五小时本地消息数的估算，这些只是估算，不是固定上限；Pro 套餐目前没有五小时限制；
  • 当前额度和重置时间可以在使用情况页面查看，在 Codex CLI 会话里也可以用 /status 查看剩余额度；
  • 如果在一轮任务进行中达到上限，Codex 可以继续完成这一轮（受公平使用限制）；
  • Plus 和 Pro 用户达到上限后，可以购买额外的 credits 继续使用，不需要升级套餐。

所以这条路线下的处理顺序是：先用 /status 看剩余额度和重置时间；急用就购买额外额度；不急就等重置。想减少消耗，可以把大任务拆小、减少不必要的长上下文。Codex 不同计费方式的区别，见《Codex 怎么收费》。

路线二：OpenAI API Key

真的是 rate limit 时怎么处理

如果错误明确是请求或 token 的速率限制，先把并发降下来。官方给出的处理原则是：

  • 有 Retry-After 响应头时，至少等到它给出的时间再重试；
  • 没有 Retry-After 时，用指数退避，并加一点随机抖动（jitter），同时限制最大重试次数。

别写这种死循环：

text
失败 → 立即重试 → 失败 → 立即重试 → ...

这会让原本的限流更难恢复。更稳妥的思路是：

text
失败 → 读取 Retry-After → 降低并发 → 等待 → 只重试一个最小请求

slow_down 是另一种速率限制

官方文档单独列出了 slow_down 这个 code。它表示你的请求量增长得太快，即使总量还在每分钟请求数和 token 数的限额以内，也可能出现。官方给的经验值是：当流量达到每分钟 100 万输入 token 后，每 15 分钟的增幅不要超过 50%。具体触发点会因模型和流量情况不同。

所以如果你刚刚把 codex exec 的并发从几个一下子提到几十个，遇到 slow_down 就很正常，解决方法是逐步加量，而不是一次性拉满。

余额、支出和使用上限

这几类 429 必须去账户后台处理：

  • credit_balance_exhausted：预付余额用完了，补充余额；
  • organization_spend_limit_exceeded：组织达到了每月支出上限，这个上限对组织内所有项目生效，需要提高或取消；
  • project_spend_limit_exceeded：某个项目达到了自己的支出上限，其他项目可以继续使用，除非它们也达到上限；
  • organization_usage_limit_exceeded：组织达到了 OpenAI 分配的每月使用上限，这和你自己设置的支出上限是两回事，需要申请更高的额度。

处理完之后，只发一个最小请求验证，不要一恢复就马上把所有任务重新跑起来。

路线三：第三方 Provider

如果请求经过第三方 Base URL，429 的含义由该服务商决定。这时要同时检查：

  • 服务商账户的余额；
  • 上游渠道状态；
  • 并发限制；
  • 当前模型是否受限；
  • 是否存在自动重试把问题放大。

AICodeWith 上的两种 429 报错

如果你通过 AICodeWith 调用，返回 429 时错误信息里常见下面两种文本，它们都来自上游，不是你的 Key 或配置写错了：

错误文本含义怎么处理
gateway_queue_full上游请求队列已满，暂时排不进去稍等几秒到几十秒再重试，不要立刻连续重发
Upstream rate limit exceeded上游模型服务触发了速率限制降低并发，减少同时运行的任务数，间隔一段时间再重试

两种情况都是临时性的。处理原则一样：等一小会儿再试，同时把并发降下来，并且只保留一层重试（见下文“Codex 自己的重试设置”）。如果持续出现，可以在渠道页查看当前渠道状态。

如果使用 AI Code With，可以在这里查看：

渠道切换能降低"单一渠道故障"带来的影响，但它不能保证绕过真正的上游限流、账户额度或组织限制。

别把"自动切渠道"当万能修复

AI Code With 的渠道页适合用来确认第三方路径里的渠道状态和模型成本，但"下一个渠道可用"不等于"所有 429 都能被绕过去"。如果错误来自上游真实的速率限制、余额不足或组织、项目限制，仍然要按错误 code 处理。把渠道切换当作可用性手段，把 429 分类当作排错手段，两件事不要混在一起。

还没有账号的话，可以先注册 AI Code With，在控制台里查看渠道和用量。

创建 API Key →

429 和 503 别搞混

有些"太忙了"的错误其实不是 429。OpenAI 错误码文档里还有一个 503，code 是 server_is_overloaded，表示请求的模型暂时过载。它和 429 的区别在于：429 是你这边的请求超出了限制，503 是服务端那边暂时忙不过来。

两者的处理方法有相似之处：有 Retry-After 时都要至少等到它给出的时间。但 503 如果持续出现，官方建议去 OpenAI 状态页查看是否有正在发生的故障，而不是去调整你的账户上限。

如果你自己写脚本调用 API，还要注意官方提到的一点：Python SDK 对 429 抛出 RateLimitError，对 503 抛出 InternalServerError。如果你的代码只捕获其中一种，另一种错误就会漏掉。官方建议两种都处理，并检查 error.code。

另一种报错：Selected model is at capacity

如果你看到的不是 429，而是「Selected model is at capacity. Please try a different model.」，那是模型服务端满载（HTTP 503），不是限流，也不是额度用完，处理方法也不一样：等它自动续跑或换个模型。详见《Codex 报错 Selected model is at capacity 怎么办》。

Codex 自己的重试设置

很多人不知道，Codex 本身对自定义 Provider 就有自动重试。官方 Configuration Reference 里有两个相关字段：

  • request_max_retries：对 Provider 的 HTTP 请求重试次数，默认 4 次；
  • stream_max_retries：流式响应中断时的重试次数，默认 5 次。

如果你在脚本里又包了一层重试，一次失败就可能被放大成十几次请求，在限流时尤其糟糕。批量运行 codex exec 时，建议只保留一层重试，并让它遵循 Retry-After。这两个字段写在 [model_providers.<id>] 下，写法见《Codex config.toml 配置指南》。

一个推荐的排查顺序

  1. 保存完整的 429 错误信息；
  2. 用 codex login status 确认是 ChatGPT 登录还是 API Key；
  3. 确认是否经过第三方 Provider；
  4. 看 error.code；
  5. 如果是速率限制，看 Retry-After、并发和请求频率；
  6. 如果是余额、支出或使用上限，直接处理账户限制，不要重试；
  7. 只用一个最小请求验证恢复。

如果只有某一个模型失败，而其他模型正常，问题可能已经从"限流"转到模型或路由层，继续查模型 ID 和 Provider。

恢复之后怎么确认真的好了

处理完 429 之后，不要马上把所有任务重新跑起来。建议按这几步确认：

  1. 只发一条最短的请求，确认能正常返回；
  2. API Key 路线下，到后台确认余额、支出上限和用量都已经更新；
  3. ChatGPT 登录路线下，用 /status 确认剩余额度已经恢复；
  4. 第三方 Provider 路线下，在调用记录里确认请求成功，并看一眼当前走的是哪个渠道；
  5. 最后再逐步恢复原来的并发，观察一段时间没有新的 429 再完全放开。

这样即使问题没有完全解决，也只会损失一两个请求，而不是让整批任务再失败一次。

批量任务怎么避免 429

如果你用 codex exec 跑批量任务或定时任务，可以提前做几件事：

  • 控制并发：从很小的并发开始，确认稳定后再逐步增加，避免触发 slow_down；
  • 错开时间：多个定时任务不要都设在整点同时启动；
  • 只保留一层重试：要么依赖 Codex 自带的重试，要么在脚本里重试，不要两层叠加；
  • 设置预算告警：API Key 路线下，提前在后台设置支出上限和提醒，比任务跑到一半突然 429 更可控；
  • 记录错误码：脚本里把 error.code 写进日志，出问题时一眼就能分清是哪一类。

常见问题

Codex 429 要等多久？

取决于原因。速率限制类按 Retry-After 等待，通常很快恢复；ChatGPT 登录的使用额度要等到重置时间，可以用 /status 查看；余额或上限类不会自己恢复，必须去后台处理。

怎么知道是限流还是余额不足？

看完整错误里的 error.code。credit_balance_exhausted 是余额问题，带 spend_limit 或 usage_limit 的是上限问题，Rate limit reached 和 slow_down 才是速率问题。

ChatGPT Plus 用户遇到使用限制怎么办？

OpenAI 定价页说明，Plus 和 Pro 用户达到上限后可以购买额外的 credits 继续使用，不需要升级套餐；也可以等待额度重置。

换成 API Key 能解决 429 吗？

换成 API Key 后，计费和限制改为按 API 规则，不再受订阅额度影响，但会有 API 自己的速率限制和支出上限。是否划算，取决于你的用量。

为什么只是偶尔用一下也会 429？

如果你用的是 API Key，可能是余额或项目支出上限的问题，而不是用得太频繁。看 error.code 就能分清。

第三方服务的 429 怎么判断？

以服务商的文档和后台状态为准。先看账户余额和渠道状态，再确认是不是只有某个模型受限。

AICodeWith 返回 gateway_queue_full 是什么意思？

表示上游排队已满，属于临时拥堵。等几秒到几十秒后重试，并降低并发即可。

免费注册，在控制台查看渠道状态和用量 →

相关阅读

参考资料

相关文章

Claude Code 和 Codex 怎么一起用？claudex-loop 让两家模型互审计划和代码（一个 Key 跑两端）

Claude Code 和 Codex 怎么一起用？claudex-loop 让两家模型互审计划和代码（一个 Key 跑两端）

想让 Claude Code 和 Codex 一起用，一个写计划、一个挑毛病？开源技能包 claudex-loop 把这件事做成了固定流程：一边出计划，另一边评审，通过后再写代码，最后换对方检查。我们用同一个 AICodeWith Key 把两端都接好，在真实 git 仓库里跑了两遍完整流程：一遍 125 秒，一遍 314 秒，Codex 在计划阶段指出了「导出文件会覆盖数据库」这样的问题。

Codex 桌面版怎么编辑之前的消息？改完提示词代码会不会回滚（附 CLI 双击 Esc 回退与 git 兜底）

Codex 桌面版怎么编辑之前的消息？改完提示词代码会不会回滚（附 CLI 双击 Esc 回退与 git 兜底）

Codex 编辑之前的消息、回退到某一轮重新来，是很多人改需求时最常用的操作，但它到底会不会把代码一起撤销？我们在 Codex CLI 0.163.0 里实测：连改三轮后双击 Esc 回退到第一条消息再重发，提示直接写着「File changes are unchanged」，第二、三轮的文件改动全部还在。本文讲清 CLI 怎么回退、桌面版官方说了什么，以及用 git 兜底撤销代码的做法。

Claude Code 怎么控制 Unreal Engine？Epic 官方插件安装、MCP 连接与安全设置（UE5 实操）

Claude Code 怎么控制 Unreal Engine？Epic 官方插件安装、MCP 连接与安全设置（UE5 实操）

Epic Games 在 Anthropic 官方插件市场提供了 Claude Code Unreal Engine 插件 unreal-engine-skills-for-claude-code，配合编辑器里的 Unreal MCP，就能让 Claude Code 直接操作 UE5 编辑器。本文讲清编辑器端要开哪两个插件、怎么启动 MCP 服务、Claude Code 端怎么装插件和验证连接，以及 execute_tool_script 等安全设置。我们用 AICodeWith 的 Key 实测：插件 2.5 秒装好，全程不需要登录 Anthropic 账号。