Codex 请求返回429，先别急着判断余额不够。相同的 HTTP 状态可能对应请求太密，也可能指向余额或不同层级的限制。
先确认错误来自哪家服务，再看具体错误正文。下面只整理 OpenAI 官方 API 的排查方向。
先拿到具体 code
| 错误依据 | 优先核对 |
|---|---|
请求过快、slow_down 等速率问题 |
请求频率、并发和返回的等待指示 |
credit_balance_exhausted |
组织预付余额 |
project_spend_limit_exceeded |
当前项目支出限制 |
organization_spend_limit_exceeded |
当前组织支出限制 |
organization_usage_limit_exceeded |
服务方分配的组织用量上限 |
error.type 即使笼统写着 insufficient_quota，也应继续检查 error.code，不要只截最后一句提示。OpenAI 错误码文档
请求太密，先降下来
减少并发和请求频率。响应有 Retry-After 时，按它等待，再受控重试。连续手动点“重试”可能继续增加请求量，不能保证恢复得更快。
余额或限制问题，核对对应后台
确认使用的是哪个项目、组织和计费路径，再查看余额、用量与限制。重复请求不会恢复这类额度。是否调整预算或上限，应根据实际需要决定，不要把“调高限制”当成所有429的默认处理。
如果是401，改查认证
检查 Key、所属项目或组织、权限，以及是否存在 IP 允许列表限制。CLI 本地显示已登录，不能替代一次在线请求验证。官方认证说明
求助时保留客户端版本、目标服务与模型、状态码、具体 code、脱敏错误正文、发生时间和时区。有请求 ID 也一起保留，方便关联日志；不要附带真实 Key 或 Authorization。
可直接使用API 报错求助模板。
原笔记发表于2026年10月23日；博客于10月27日复核官方文档后整理。本文是文档速查，没有复现付费请求错误，也不能保证所有429都属于表中某一项。