Codex CLI 429 限流错误的 5 种原因与修复
Codex CLI 出现 429 Too Many Requests，常见原因是单次请求过大、并行子代理超限或套餐额度耗尽，本文按真实案例逐一说明排查和修复方法。
429 错误到底是什么意思？
Codex CLI 报"exceeded retry limit, last status: 429 Too Many Requests"，本质是触发了 TPM（tokens per minute，每分钟令牌数）限流，或者账号/套餐层面的额度已经用完[1]。这两类原因表现出来的报错文案很接近，但修复方式完全不同，先分清楚是哪一类，再往下排查。
原因一：单次请求本身太大
如果你一次提交的 apply_patch 补丁块接近或超过 3 万 token，即使当前用量还没到账号总配额，也会因为单次请求瞬间占满 TPM 桶而触发 429[2]。这种情况通常伴随"CLI 重试一次后立刻收到第二个 429，进程直接退出"的现象。
修复思路很直接：把大改动拆成几个较小的 patch 分批提交，避免一次性推满 TPM 上限。
原因二：并行子代理数量超过默认上限
Codex 的实验性多代理（subagent/collab）功能默认把并行代理数量限制在 6 个，如果你的配置或任务同时拉起了 20 多个子代理，请求量会在短时间内暴增，看起来像对后端发起了密集请求，从而触发限流[3]。
如果最近改过 config.toml 里和多代理相关的配置，或者任务描述里显式要求"并行处理多个文件"，可以先把并行数降到默认值附近，观察是否还会出现 429。
原因三：套餐每日/每月额度已耗尽
有开发者反馈在 Plus 套餐下，正常使用节奏三小时就耗尽了当日限额，切换到 Pro 套餐后短期内依然遇到 429，说明这不只是并发问题，也可能是套餐层的用量上限被打满[4]。
这种情况下，继续调整并行数或拆分请求都没用，需要确认当前套餐的额度上限和已用量，等额度重置或升级套餐才能恢复。
原因四：Azure 或企业部署的 TPM 配置过低
如果通过 Azure OpenAI 部署使用 Codex CLI，429 往往是因为 Azure 侧给这个部署分配的 TPM 额度太低，需要管理员在 Azure 后台调高，而不是 Codex CLI 本身的问题[5]。有反馈显示，仅仅是 CLI 版本升级后请求节奏变快，也会在同样的 TPM 配置下更容易撞到限流上限。
原因五：CLI 版本过旧，缺少退避重试逻辑
早期版本的 Codex CLI 遇到 429 会直接崩溃退出，没有自动退避重试机制；这个问题在 0.1.2504251709 及之后的版本中已经修复[2]。如果你还在用较旧的版本，同样的限流场景下报错会更频繁、更容易直接中断当前任务。
修复步骤清单
按顺序排查，能覆盖上面五种情况：
- 运行
codex --version确认版本不低于 0.1.2504251709 - 把体积过大的改动拆成多个较小的 patch
- 检查是否开启了多代理/collab 相关配置，暂时调低并行数
- 查看当前套餐的用量面板，确认额度是否已耗尽
- 如果是 Azure 部署，联系管理员确认该部署的 TPM 配置
五步走完仍然频繁 429，大概率是账号或套餐层面的限额问题，调整使用节奏或升级套餐比继续排查配置更有效。
常见问题
429 会不会是账号被限制使用了？
一般不是账号封禁，而是速率限制（TPM）或额度耗尽的正常保护机制，等待窗口期过去或额度重置后就能恢复。
拆分 patch 之后还是 429，该怎么办？
先确认是不是套餐额度已经打满——如果并发和单次请求量都已经优化过还持续出现，问题更可能出在账号总配额，而不是单次请求的大小。
CLI 版本升级后 429 会消失吗？
版本升级能修复"429 后直接崩溃退出"这个体验问题，让 CLI 具备自动重试和退避能力，但不能提升你的 TPM 配额本身——如果根因是配额不够，升级版本只是让报错处理得更优雅，不能根治。