OpenAI API 返回 "You exceeded your current quota" 或 insufficient_quota 时，先不要把它当成普通 429 速率限制。这个错误更常见的含义是：当前组织、项目、月度预算、预付余额、付款状态或模型路径没有可用 API 额度。它可能和 rate limit 一样使用 429，但归属不同，修复动作也完全不同。
最稳妥的第一屏答案是：打开 OpenAI Platform 的 Billing 和 Limits，确认 API key 所在组织和项目，检查预付余额、月度预算、approved usage limit、付款状态和模型权限，然后用同一个项目跑一个最小请求。只有额度确实可用之后，才进入 RPM、TPM、并发、响应头和退避重试的分支。
截至 2026 年 4 月 29 日，OpenAI 官方 rate-limit 文档把实时账户上限放在 Platform Limits 页面，生产最佳实践文档把 billing limits 和 approved usage limits 当作账户控制项。更可靠的做法不是把易变数字写成永久表格，而是保留一个能在事故现场执行的检查顺序。
快速判断
| 问题 | 直接答案 |
|---|---|
| 这个错误通常代表什么？ | 当前 API 路径没有可用额度、余额、预算、付款状态、项目范围或模型权限。 |
| 它等于 rate limit 吗？ | 不等于。insufficient_quota 是额度/计费分支，RPM/TPM 是另一个分支。 |
| 第一件事检查什么？ | Platform Billing、Limits、月度预算、组织、项目、key 和模型权限。 |
| ChatGPT Plus 或 Pro 能修吗？ | 不能自动修。ChatGPT 订阅不等于 Platform API 余额。 |
| 该换 key 吗？ | 不该。相同项目里的新 key 不会凭空产生额度。 |
| 什么时候看响应头？ | 额度可用后，或错误证据明确指向请求数/Token 压力时。 |
先确认错误归属，而不是先改代码
quota exceeded 的核心是可用性，而不是吞吐。吞吐问题表示这条 API 路可以调用，只是你在请求数、Token、并发或窗口上压得太猛。额度可用性问题表示这条路目前没有可用余额、预算、付款许可、项目权限或模型权限。
如果错误体里出现 insufficient_quota，或者提示 "You exceeded your current quota, please check your plan and billing details"，指数退避只能让程序安静一点，不能创造额度。继续盲目重试甚至会让日志更乱，因为你还没有修复真正的账户状态。
当证据是 RPM、TPM、remaining headers、reset window、burst traffic 或并发时，转到 OpenAI API rate limits。当证据是 billing details、trial、prepaid credits、月度预算、组织、项目或模型权限时，留在额度分支。
官方边界也支持这种拆法。OpenAI 的 rate-limit guide 要求开发者用 Limits 页面确认实时账户上限，用响应头判断 request/token 窗口；production best practices 则把 billing limits 和 approved usage limits 放在账户治理里。真正的页面应该告诉读者看哪里，而不是复制一张很快过期的额度表。
按顺序做五项检查
| 检查项 | 要确认什么 | 为什么重要 |
|---|---|---|
| 计费路径 | Platform 账号已经启用 API 计费，付款状态健康。 | API 使用通过 Platform 计费，不由 ChatGPT 订阅直接支付。 |
| 预付余额或 credit | 余额存在、未过期，并挂在当前使用的账户上。 | 代码正确也会因为没有可用余额失败。 |
| 月度预算或 approved usage limit | 项目或账户没有触碰自设预算或批准额度。 | 很多团队补了余额，却忘记预算 cap 仍然挡着。 |
| 组织和项目 | API key 属于你刚刚检查过 Billing 和 Limits 的同一组织与项目。 | 查错组织会让一个有钱账户看起来像坏了。 |
| 模型路径 | 请求的模型对这个项目和账户等级可用。 | 账户有余额，不代表每个模型路径都可用。 |
不要把这五项压缩成一句“计费没问题”。一张有效卡可能没有预付余额；有余额可能还有很低的月度预算；组织有钱但应用用了另一个项目的 key；便宜模型能跑不代表受限模型也能跑。每一种状态都要走不同修复路线。
最干净的复测，是用同一个 key、同一个组织、同一个项目、同一个 endpoint family 和模型，发一个最小请求。如果成功，再回到应用路径检查环境变量、wrapper 配置或部署变量漂移。如果仍然 insufficient_quota，错误归属还在账户额度或模型访问权。
恢复顺序
修复顺序要和诊断顺序一致。
- 确认你在正确的 Platform 组织和项目里。
- 打开 Billing，检查余额、付款方式、credit 状态和 invoice 状态。
- 打开 Limits，检查 approved usage limit、月度预算、模型可用性和项目范围。
- 如果刚刚添加 prepaid credits，等待传播后再判断失败。
- 用同一项目跑最小 API 请求，再重启队列或生产 worker。
- 最后才处理 RPM、TPM、并发、Token 预算和响应头退避。
这个顺序看起来保守，但能避免两个昂贵错误：把钱充到错误账户，以及为账户状态问题上线一套重试逻辑。它也把易变事实放在正确位置。如果你需要确切的最低充值金额、credit 有效期或 usage tier，事故现场应该看 OpenAI 当前 Billing 和 Help Center，而不是引用旧文章。
新 key、试用状态或组织配置不清楚时，可以看 OpenAI API key free trial。项目和组织归属不清楚时，再用组织 ID/项目配置文档把环境变量拆出来。
wrapper 和集成工具场景
Zapier、Make、n8n、内部网关和 OpenAI-compatible provider 可能把 OpenAI 风格的 quota message 展示给你，但真正的计费归属未必一眼可见。关键问题是：最终发给 OpenAI 的 credential 属于谁。
如果集成使用你自己的 OpenAI API key，先诊断你的 Platform 账户。如果集成使用托管 provider 账号，先诊断 wrapper 的套餐、connector quota 或 workspace budget。如果两种模式都支持，就用你的 key 直接向 OpenAI Platform 发一个最小请求，把 wrapper 从链路里拿掉。
不要假设用户前台、后台 worker、本地脚本和 CI 用的是同一个预算。生产环境可能是另一个项目、旧 key、不同组织，或带有自有 cap 的 gateway。直接 API 复测的价值在于，它能证明 Platform quota 本身是否可用。
停止规则
当错误体已经指向 quota 或 billing 时，停止这些动作：
- 不要在同一个无额度项目里轮换 key。
- 不要提高 retry count 试图“冲过”额度错误。
- 不要购买 ChatGPT 订阅后期待 Platform API 自动有余额。
- 不要把公开 quota 表当成你账户应该可用的证明。
- 不要在没有可用额度前申请更高 rate limit。
应该改做这些：
- 保存完整错误体、时间、组织、项目、key 来源、endpoint、模型和 dashboard 状态。
- 记录同一项目的最小直接请求是否成功。
- 记录 wrapper 路径和直接 Platform 路径是否表现不同。
- 记录最近一次计费操作以及等待传播的时间。
- 带证据升级处理，而不是只发一张截图。
支持或提额证据包
支持请求和提额请求最怕“我明明有额度但还是不行”这种模糊描述。证据包应该包含 exact error text、error type、HTTP status、model、endpoint family、project、organization、带时区的 timestamp、Billing 页面状态、Limits 页面状态、最近充值或付款动作，以及最小同项目复测结果。
如果真正目标是额度可用后的更高吞吐，就换成吞吐证据：每分钟请求数、每分钟 Token、并发、队列长度、reset headers，以及你已经如何降低 burst 或输出 Token。这是 rate-limit 分支，不是 quota 分支。
常见问题
为什么刚创建 API key 就 quota exceeded？
API key 只是 credential，不证明项目有 Billing、prepaid credits、月度预算或模型访问权。必须检查创建该 key 的同一组织和项目。
添加 credits 后会马上修好吗？
通常要等待短暂传播，并用同一项目复测。如果仍失败，确认 credits 是否挂在应用实际使用的账户、组织和项目上。
insufficient_quota 和 too many requests 一样吗？
不一样。too many requests 是吞吐分支；insufficient_quota 是可用性分支。HTTP 状态可能相似，但修复动作不同。
为什么 dashboard 看起来还有空间，应用仍失败？
应用可能使用不同组织、项目、key、wrapper 账号、模型路径或环境变量。用同一个 key 做最小直接请求，再和应用路径对比。
什么时候申请更高 limit？
只有账户有可用额度，并且证据显示真正瓶颈是吞吐或 approved usage ceiling 时才申请。如果归属是付款、余额、月度预算或项目范围，先修这些。