最近在用 OpenAI Codex 做一个自动化代码审查工具，跑着跑着突然开始疯狂报错：

exceeded retry limit, last status: 429 Too Many Requests

第一反应是 API 配额用完了，去控制台看了一眼，余额充足，用量也没超。然后以为是网络问题，换了节点，重启了服务，还是一样。折腾了将近一个小时，最后发现问题出在配置文件里，而且解决方案就是加一行字。

这种事情说出来有点尴尬，但我觉得有必要记录下来，因为这个坑踩起来真的很隐蔽，报错信息完全不指向真正的原因。

先说 429 到底是怎么来的

很多人看到 429 的第一反应是"请求太频繁了"，这没错，429 的标准含义确实是 Too Many Requests。但在 Codex 这个场景里，问题不是你发的请求太多，而是请求根本没被服务端正确处理。

具体来说，Codex 在调用外部 model provider 的时候，需要在请求头里带上正确的认证信息。如果配置里没有明确告诉它"这个接口需要 OpenAI 标准认证"，它就会用一套默认的方式去构造请求，认证头要么格式不对，要么根本没带上。服务端收到这种请求，直接判定为无效请求，返回 429 拒掉。

Codex 内部有重试机制，它会反复尝试，每次都失败，最终触发 exceeded retry limit，把这个错误抛出来。所以你看到的是"重试次数超限"，但根本原因是"每次请求都因为认证问题被拒了"。

这就是为什么换网络、清缓存、重启服务都没用，因为问题从来不在这些地方。

解决方法：加一行配置

找到你的 Codex 配置文件，在 model_providers 部分加上下面这段：

[model_providers.api111]
name = "api111"
base_url = "wellapi.ai/v1"
wire_api = "responses"
requires_openai_auth = true

核心就是最后这一行：

requires_openai_auth = true

加上这行之后，Codex 在构造请求的时候会切换到 OpenAI 标准认证模式，按照 Authorization: Bearer YOUR_API_KEY 的格式把认证信息带进请求头。服务端能正确识别这个格式，鉴权通过，请求正常处理，429 就不再出现了。

把每个字段都说清楚

趁这个机会把这段配置里每个字段的作用解释一下，方便以后遇到类似问题的时候能快速定位。

[model_providers.api111] — 这是这个 provider 配置块的标识，方括号里的 api111 是你给这个 provider 起的名字，可以随便改，只要在整个配置文件里保持唯一就行。如果你有多个 provider，就用不同的名字区分，比如 model_providers.openai_official、model_providers.my_proxy 之类的。

name — provider 的显示名称，主要用于日志和调试输出，方便你在日志里快速认出是哪个 provider 在工作。

base_url — API 的基础地址，Codex 发出的所有请求都会以这个地址为根路径。这里填的是 https://wellapi.ai/v1，如果你用的是其他中转服务或者自建的兼容接口，把这个地址换成对应的就行。

wire_api — 这个字段指定用哪种接口协议格式来构造请求。填 responses 表示使用 OpenAI 的 Responses API 格式，这是目前 Codex 推荐的接口格式。如果你用的是旧版的 Chat Completions 格式，这里填 chat_completions。两种格式的请求结构不一样，填错了也会导致请求失败。

requires_openai_auth — 这就是今天的主角。这个字段告诉 Codex，这个 provider 需要使用 OpenAI 标准的认证方式。设成 true 之后，Codex 会在每次请求里自动带上格式正确的 Bearer Token 认证头。如果不加这行，或者设成 false，Codex 就不会主动处理认证，请求发出去之后服务端直接拒掉。

改完之后怎么验证

配置文件改好之后，重启 Codex，重新发一个简单的请求，比如让它生成一段 Hello World 代码。如果不再出现 429，说明配置已经生效了。

如果想更直观地确认认证信息有没有正确带上，可以在终端里用 curl 模拟一个请求，手动加上 Authorization 头，看服务端的响应是不是正常的：

curl wellapi.ai/v1/responses \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "your-model-id", "input": "hello"}'

如果 curl 能正常返回，说明 API Key 和接口地址都没问题，Codex 加上配置之后也应该能正常工作。

另外建议在 Codex 的日志输出里确认一下请求状态，看看有没有从 429 变成 200，这样心里更踏实。

什么情况下需要加这行

所有走 OpenAI 兼容协议的第三方服务，基本上都需要加 requires_openai_auth = true。这类服务的认证方式和 OpenAI 官方完全一样，都是 Bearer Token，但 Codex 默认不会自动识别第三方服务需要这种认证，必须手动声明。

常见的场景包括：

使用各种 OpenAI 中转 API 服务的时候，这类服务通常提供兼容接口，但需要你用自己的 API Key 去认证，不加这行 Codex 不会自动带上 Key。

自建了兼容 OpenAI 接口的本地服务或者私有部署的模型服务，同样需要这行配置来触发正确的认证逻辑。

接入国内或者第三方的大模型 API 平台，只要对方走的是 OpenAI 兼容格式，这行配置就是必须的。

一个排查 429 的思路

以后再碰到 Codex 报 429，可以按这个顺序排查：

第一步，先确认 API Key 本身是不是有效的，去对应平台的控制台检查一下 Key 的状态和余额。

第二步，检查配置文件里有没有 requires_openai_auth = true，这是最容易漏掉的一行。

第三步，确认 base_url 填的地址是不是正确的，有没有多了或者少了斜杠，路径有没有写对。

第四步，确认 wire_api 填的格式和你的服务端支持的格式是不是匹配的。

按这个顺序走下来，大部分 429 的问题都能找到原因。

最后说一句

这种配置类的问题最让人崩溃的地方在于，报错信息和真正的原因之间隔了好几层，光看错误提示完全找不到方向。希望这篇文章能帮你少走一点弯路，下次再碰到类似的问题，先翻配置文件，往往一行就能搞定。