如果 OpenAI Platform API 显示额度不足、insufficient_quota 或返回 429，不要先把重试次数调大。先读错误正文：可重试的速率压力需要 backoff、限流、排队或缩小请求；额度、账单、项目范围、模型权限、状态事件和 wrapper 限制则需要完全不同的检查，继续循环只会让日志更乱。
| 错误线索 | 可能归属 | 先查什么 | 重试还是停止 |
|---|---|---|---|
rate limit reached、too many requests，或 remaining headers 接近 0 | 请求或 token 速率限制 | 响应 headers、Limits 页面、模型家族、reset window | 可以带 jitter 退避，然后限流或排队 |
You exceeded your current quota 或 insufficient_quota | 额度、账单或月度 spend cap | Billing、Usage、Limits、月度支出、账户状态 | 停止重试，直到账户状态改变 |
| 新 key 仍失败，或只有某个项目/模型失败 | 项目、组织、模型或 key 范围 | 当前 project、organization、模型权限、共享模型家族限制 | 先修范围，不要直接改流量 |
| 多个调用失败，同时 Status 显示相关事件 | 平台状态或容量事件 | OpenAI Status、时间戳、request id、受影响 endpoint | 等待、保存证据、避免反复改账号 |
| 错误来自 ChatGPT、Codex、Sora、Azure OpenAI 或 wrapper | 错误调用面或供应商自有限制 | 产品面、供应商文档、API route、headers | 先转到对应合同，再用 API 修复动作 |
停止规则很简单：只有当归属是请求或 token 压力，并且你有 reset 信号时，才进入重试。只要正文指向 quota、billing、错误项目、错误模型、错误调用面或状态事件，同一个请求的重复发送都不是修复动作；先保存错误正文、request id、headers、project、organization、model、Limits 页面状态和 Status 状态。
先读 429 错误正文，再改代码
OpenAI 的错误码文档把 429 明确拆成至少两类：请求太快触发的 rate limit，以及 current quota 已耗尽。中文排障里最常见的问题，是把这两类都叫「429 报错」然后直接套一个重试模板。这样会把可恢复的限速问题和必须处理账户状态的问题混在一起。
正确的第一步是保留原始错误正文。不要只记录 HTTP 429，也不要只把 SDK 异常写成 RateLimitError。你需要 error message、error code、error type、endpoint、model、project、organization 和时间戳。如果日志里看不到 insufficient_quota、rate limit reached 或 reset headers，先补日志再修代码。
一个保守的程序判断可以这样做：如果 code 或 type 是 insufficient_quota，直接进入 quota/billing stop；如果 message 出现 current quota，也停止；只有明确出现 rate limit、too many requests，或者 headers 显示 remaining 接近 0 时，才进入 retryable rate limit 分支。未知 429 不应该靠猜测处理，而应该收集证据。
10 分钟内完成的恢复路线
前 10 分钟不要做五件事：不要连续新建 key、不要同时换模型、不要改 billing、不要增加重试、不要把所有请求都切到另一个 provider。保持同一条请求路径，按顺序确认归属，才能知道哪一步真的影响了结果。
| 时间 | 动作 | 你会得到什么 |
|---|---|---|
| 0-1 分钟 | 复制完整错误正文和 headers | 区分 rate limit、quota、billing 或未知 429 |
| 1-3 分钟 | 打开同一个 project/org 的 Limits、Usage、Billing | 判断当前账户是否有容量或账单阻塞 |
| 3-5 分钟 | 核对 model、endpoint、模型家族 | 找到更严格或共享的模型限制 |
| 5-7 分钟 | 查看 OpenAI Status | 区分公共事件和账号局部问题 |
| 7-10 分钟 | 发一次更小的控制请求 | 判断是否是 token 大小、并发或账户状态 |
如果小请求成功，说明更可能是并发、token、图片吞吐或同步 fan-out 造成的压力。如果小请求仍然返回 quota wording，就不要再排队重试，应该进入账户和范围检查。如果多个 endpoint 同时失败且 Status 有相关事件，最有价值的是保留证据，而不是来回迁移账号。
什么时候重试和退避才正确
retry 正确的前提是证据指向短期速率压力。典型信号包括 rate-limit wording、remaining request/token 变低、reset 时间存在、请求突发超过当前项目和模型限制。这里的目标不是「更努力地发送」，而是更慢、更稳、更可观测地发送。
实践上，backoff 应该带 jitter，并且有最大次数。每个 worker 自己 sleep 并不等于全局限流；如果十几个 worker 都认为自己很克制，合在一起仍然可能超过项目限制。生产系统应当有项目和模型家族级别的集中限流器、队列长度指标、token 预算和失败计数。
还要记住一个容易被忽略的事实：失败请求也可能计入每分钟限制。紧密 retry 会让系统把一个 429 放大成几十个 429。正确的 retry 会降低并发、排队、缩小请求或把非实时任务转入 Batch，而不是在 reset window 内制造更大的尖峰。
什么时候继续重试是错的
出现 insufficient_quota、current quota、billing、monthly spend、账户状态等线索时，继续 retry 是错的。短暂停顿不会补额度，指数退避也不会改变 billing state。此时应该检查 Billing、Usage、Limits、月度 spend cap、项目选择、组织选择以及模型访问权限。
「我有余额但仍然 429」通常不是一句话能解释的问题。余额可能在另一个组织里，请求可能来自另一个 project，月度 spend cap 可能已经触顶，模型可能对当前 project 没有访问权限，或者 wrapper 使用的是自己的池。用同一个最小请求逐项确认，不要在一次排查中同时换 key、换模型、换 project 和改 retry 代码。
为什么换一个 API key 不一定有用
API key 不是独立的容量池。新 key 只有在旧 key 被撤销、泄露、权限不对或绑定错项目时才是关键修复；如果组织、项目、模型家族和 billing owner 仍然相同，新 key 很可能返回同一个 429。
| 范围层 | 要确认什么 | 常见失败 |
|---|---|---|
| Organization | 请求是否进了预期组织 | 个人 org 和团队 org 的 billing/limits 不同 |
| Project | key 是否属于你正在查看的 project | 在 A project 查 Limits，却用 B project key 调用 |
| Model family | 模型是否有权限和余量 | 严格模型或共享 family 限制已耗尽 |
| Team workload | 是否有其他服务共享容量 | 批任务或另一个 app 抢占了池 |
只有某个模型失败时，先用同一 project 调一个你确认可用的小模型。所有模型都带 quota wording 失败时，先查 Billing/Usage/Limits。只有一个服务失败而同 key 在别处正常时，再查该服务的并发、prompt 大小和请求形态。
把 headers 和 Limits 当作实时证据
live evidence 来自两个地方：响应和账户。响应正文告诉你分支，headers 可能告诉你 limit、remaining 和 reset，Limits 页面告诉你当前组织、项目和模型的真实上限。任何旧文章里的 RPM/TPM 表，都不应该压过你自己的实时证据。
| 证据 | 作用 |
|---|---|
| HTTP status 与错误正文 | 区分可重试限速和 quota/billing |
| request id | 让支持团队能定位具体请求 |
| rate-limit headers | 显示 limit、remaining、reset timing |
| project/org | 确认谁拥有这次请求 |
| model/endpoint | 找到更严格模型或错误 endpoint |
| Limits/Usage 截图 | 保留故障时账户状态 |
| OpenAI Status | 区分公共状态事件和局部问题 |
2026-04-29 的公开 Status 检查没有显示广泛 active incident，但这不是永久结论。真正排障时要重新查 Status：相关组件降级就等待并保存证据，Status 正常就继续查账户范围、headers 和 workload。
让生产系统少遇到下一次 429
事故缓解以后，把经验沉到生产控制里。应用应当在请求发出前知道自己的预算：项目/模型级限流、tenant 预算、token 预估、队列长度、失败率告警和 reset window 观察。不要让 OpenAI API 成为第一个告诉你流量超限的地方。
同步用户请求要保护延迟，后台任务要接受排队。能异步的任务不要和用户请求争同一个瞬时窗口；能缩小 prompt 的任务不要默认发送最大上下文；能按租户隔离的系统不要让一个 noisy tenant 抢走全项目余量。Batch 对非实时任务更合适，但前提是业务能接受延迟。
先排除错误调用面
OpenAI API 429 只应指你的代码调用 OpenAI Platform API 时返回的错误。ChatGPT 网页或手机端限制、Codex 产品限制、Sora 视频容量、Azure OpenAI quota、OpenAI-compatible wrapper 的池，都可能显示类似限制，但归属不同。
| 调用面 | 不要假设 | 应该检查 |
|---|---|---|
| ChatGPT | Plus 会员会增加 API quota | ChatGPT 产品限制和账号状态 |
| Codex | coding-agent 限制等于 API RPM/TPM | Codex 当前合同和状态 |
| Sora | 视频容量等于文本 API 限制 | Sora route、plan、queue、status |
| Azure OpenAI | OpenAI Platform Limits 拥有部署限制 | Azure quota、deployment、region、subscription |
| Wrapper/gateway | OpenAI headers 一定原样透传 | provider dashboard、docs、route id、upstream headers |
如果你不是直接调用 api.openai.com，先识别 provider 边界。wrapper 可能是自己的池满了，也可能把 upstream 429 包装成自己的错误，还可能是你在该 provider 的 plan cap。边界不清，修复动作就很容易跑偏。
带着证据升级处理
升级处理要短、可复现、无敏感信息。最有用的支持包包括：日期时间和时区、request id、endpoint、model、SDK 版本、organization、project、billing owner、错误正文、安全 headers、Limits/Usage 状态、Status 状态、retry 次数、并发、prompt 规模、队列深度和最近变更。
不要公开 API key、bearer token、完整私有 prompt、银行卡信息或用户数据。如果必须提交 payload，也要走支持方给出的安全渠道。清晰证据会比「一直 429」更快定位问题。
常见问题
OpenAI API 429 都能重试吗？
不能。只有错误正文和 headers 指向短期请求或 token 压力时，retry 才是合理动作。看到 insufficient_quota 或 current quota exceeded，就先查 Billing、Usage、Limits、project、organization 和模型权限。
insufficient_quota 是什么意思？
它说明阻塞来自 quota、billing、spend 或账户状态，而不是几秒钟后自然恢复的请求突发。具体归属要回到发出请求的同一个组织和项目去查。
为什么我有余额还会 429？
请求可能用了另一个 organization 或 project，月度 spend cap 可能触顶，billing 状态可能尚未生效，模型可能有自己的访问限制，或者 wrapper 有自己的池。
多建几个 API key 能提高限制吗？
不能把同一个 project/org 的容量变大。新 key 能修复撤销、泄露、权限或项目绑定问题，但不能凭空制造新 quota。
应该看哪些 headers？
有返回时，看 limit、remaining、reset 相关 headers，并把它们和当前 Limits 页面一起解释。headers 是故障时刻的证据，Limits 是账户当前合同。
要不要查 OpenAI Status？
要。Status 有相关事件时，等待并保存证据；Status 正常时，继续查错误正文、headers、Limits、Billing、project、organization、model 和 provider surface。
ChatGPT Plus 和 OpenAI API quota 是同一个东西吗？
不是。ChatGPT 消费者订阅和 OpenAI Platform API billing 是两条不同路线，不能用 Plus 会员解释或修复代码里的 API 429。
给支持团队发什么？
发时间、时区、request id、endpoint、model、project、organization、错误正文、安全 headers、Limits/Usage 状态、Status 状态、retry 次数、workload 形态和最近变更，同时删掉密钥和敏感数据。
本地排查记录模板
把每次 429 记录成一个固定模板：时间、时区、endpoint、model、project、organization、错误正文、headers、Limits、Usage、Billing、Status、retry 次数、并发、prompt 规模、队列长度和最近部署。模板的价值在于让下一次事故不用重新猜归属，也能让支持团队直接看到同一个请求路径的证据。
复盘时只问三个问题：第一，哪个分支最先给出了明确信号；第二，我们有没有在信号出现前就改了太多变量；第三，哪一个生产控制可以让相同流量在 API 拒绝前被应用自己消化。这样处理，429 不再只是报错，而会变成限流、账单、范围和状态治理的一次校准。
中文团队还应该把“谁拥有修复”写进同一张记录里。请求速率压力通常由应用侧的 limiter、队列、token 预算和租户配额负责；insufficient_quota 或 current quota 则通常需要 billing owner、project admin 或组织管理员处理；status incident 归平台状态；wrapper 返回的 429 要回到 provider route 和供应商面板。把 owner 写清楚，可以避免值班同学在错误的控制面里反复切 key、换模型或调整 retry。
最后再写一条关闭条件。对于 retryable pressure，关闭条件可以是 controlled request 成功、remaining headers 恢复、队列延迟回落；对于 quota/billing，关闭条件应该是 Usage、Billing 或 Limits 页面状态改变；对于 wrong project 或 wrong organization，关闭条件是同一条最小请求在正确范围内成功；对于 provider route，关闭条件是供应商确认池容量、上游映射或本地账号限制。没有关闭条件的排障记录，只是日志，不是可复用的事故经验。
如果这次事故来自生产系统，还要把用户影响和限流策略分开写。用户影响记录哪些功能失败、失败持续多久、是否有自动降级；限流策略记录应用是否主动排队、是否按租户隔离、是否在到达 OpenAI 前就估算 token、是否把非交互任务切到异步队列。这样下一次看到 quota exceeded 或 429 时，团队可以先保护用户路径，再处理账单、范围或供应商边界，而不是让所有调用继续撞同一个限制。
这份记录还应该进入告警规则：同一 project 连续出现 quota wording 时直接提醒账单和范围 owner；remaining headers 快速归零时提醒应用侧限流 owner；Status 事件出现时提醒值班人员暂停无效重试。
