Codex 报错 "exceeded retry limit, last status: 429 Too Many Requests":原因与解决办法
返回博客
文章codextroubleshootingagente de programaçãodev toolsinteligência artificial

Codex 报错 "exceeded retry limit, last status: 429 Too Many Requests":原因与解决办法

Mafra2026年11月1日阅读约 4 分钟

Codex 正在工作,重试几次后突然停下,并显示 exceeded retry limit, last status: 429 Too Many Requests。面板上明明还有额度,人们很自然地认为是 Codex 坏了。其实不是,这条提示里有一个常被忽略的线索。

这个错误出现在官方仓库 openai/codex 的近期报告中。issue #57084 创建于 2026 年 10 月 26 日,记录了 Linux、VS Code、ChatGPT Pro 套餐下的多次失败,其中一次发生时每周额度还剩 99%。截至 2026 年 11 月 1 日,OpenAI 尚未在该 issue 中公布原因或修复。

"exceeded retry limit, last status: 429" 是什么意思?

意思是服务器返回了 HTTP 429(请求过多),而 Codex 在放弃之前用完了自动重试次数。在 Codex 源码中,这条消息的格式是 exceeded retry limit, last status: <status>,当服务器返回请求标识时,末尾会追加 , request id: <id>。

它与套餐额度提示的区别在 codex-rs/codex-api/src/api_bridge.rs 中。收到 429 时,Codex 会读取响应正文。如果错误类型是 usage_limit_reached,就显示额度提示("You've hit your usage limit...")。其他任何 429 都会变成 exceeded retry limit。也就是说,这条消息并不表示你的额度用完了。

看到的提示含义怎么做
You've hit your usage limit套餐额度用尽等待重置或购买额度
exceeded retry limit, last status: 429 Too Many Requests通用 429,不是套餐额度见下方步骤
Selected model is at capacity. Please try a different model.所选模型当前没有容量用 /model 切换模型
流程图:Codex 出现 429 exceeded retry limit,用 /status 查看额度,用 /model 切换模型,保存 request id,以及 hit your usage limit 提示的分支
从报错到诊断:先判断是套餐额度,还是通用 429。

如何诊断并绕过这个错误?

按顺序操作。前三步只需几秒,可以排除你自己能解决的原因。

  1. 看清提示原文。如果是 "You've hit your usage limit",就是套餐额度问题,对应表格第一行。如果是 exceeded retry limit,继续往下。
  2. 用 /status 查看额度。该命令显示当前会话配置和 token 用量。额度还很充足而错误依旧,说明问题不在你的套餐上限。
  3. 用 /model 切换模型。该命令用于选择模型和推理强度。issue #57084 中的记录都来自同一个模型(gpt-6.1-sol,低强度),而源码里有按模型区分的容量错误。把同一任务放到另一个模型上跑,就能看出被拒绝的是否只是那个模型。
  4. 先等一等再重试。在 issue #57084 中,多个回合的重试提示收敛到同一时刻,误差在 0.7 秒以内,等待时间为几分钟。连续发出相同请求只会重新计时。
  5. 更新 Codex。本文调研时的最新版本是 0.166.0(2026 年 10 月 29 日),通过 gh release list -R openai/codex 查得。
/status
/model

可以增加自动重试次数吗?

只适用于你自己配置的模型提供方。源码中,request_max_retries(默认 4)和 stream_max_retries(默认 5)是模型提供方配置项的字段,上限各为 100。在 ~/.codex/config.toml 中配置自有提供方的示例:

[model_providers.my-gateway]
name = "My gateway"
base_url = "https://gateway.example.com/v1"
request_max_retries = 8
stream_max_retries = 10

有两点需要如实说明。我没有测试这些字段是否适用于默认的 OpenAI 提供方,所以不保证能解决你的问题。另外,增加重试次数改变不了服务器的决定:如果拒绝是因为容量或短时间窗口的用量,你只是在看到同样错误之前多等一会儿。

错误持续出现时应该保存什么?

如果消息末尾有 request id,请复制下来,并记录 UTC 时间、模型、推理强度、Codex 版本和 /status 的输出。issue #57084 的作者指出,日志中缺少 Retry-After 和请求标识,正是分析无法推进的原因,并要求提供这些数据。把它们附到 issue 中,不要包含 token、项目路径或提示词。

如果服务商的限额总是打断你的一天,Verboo Code 的套餐提供无限 token,下一次尝试不再取决于额度窗口。

喜欢这篇文章吗?
把知识分享给你的朋友。
// 继续阅读

相关文章