OpenAI Platform APIが429を返したら、まずretry回数を増やさず、エラー本文を読みます。rate limitならbackoff、throttling、queueが候補です。しかしquota、billing、project scope、model access、status incident、wrapper limitなら確認先が変わります。
| 手がかり | 主な原因 | 最初に見るもの | retryかstopか |
|---|---|---|---|
rate limit reached、too many requests、remaining headersが低い | request/token rate limit | headers、Limits、model family、reset window | backoffとjitter、その後throttleまたはqueue |
You exceeded your current quota、insufficient_quota | quota、billing、spend cap | Billing、Usage、Limits、account state | account stateが変わるまでstop |
| 新しいkeyでも同じ、または一部project/modelだけ失敗 | project、organization、model、key scope | project、organization、model access | scopeを直してからtrafficを変える |
| 多くのcallが失敗しStatusにincident | platform status/capacity | OpenAI Status、timestamp、request id | 待つ、証跡を残す |
| ChatGPT、Codex、Sora、Azure、wrapperからのエラー | wrong surface | product surface、provider docs、route、headers | その契約へ切り分ける |
停止ルールは単純です。request/token pressureでreset signalがある場合だけretryします。quota、billing、wrong project、wrong model、wrong surface、status incidentなら同じリクエストの反復は修復になりません。
429本文を読んでからコードを変える
OpenAI official docs distinguish at least two 429 families: traffic arriving too fast and current quota exhausted. In local developer searches these usually collapse into one phrase, so the body of the error must own the first decision. Record message, code, type, endpoint, model, project, organization, timestamp, and request id before changing retry policy.
The safe classification is conservative. If insufficient_quota or current quota wording appears, treat it as a quota or billing stop. If the body says rate limit or too many requests and the headers show remaining/reset information, treat it as retryable pressure. If neither branch is clear, hold the route steady and collect evidence instead of changing five variables at once.
This matters in real operations because an ambiguous 429 can tempt teams into the wrong repair. A tight retry loop can consume more minute capacity. A new key can hide the fact that the same project is still blocked. A billing change in the wrong organization can leave the production request untouched.
10分で復旧ルートを決める
Use the first ten minutes to classify the owner, not to experiment randomly. Copy the raw body and headers, open Limits, Billing and Usage for the same project and organization, confirm the model family, check OpenAI Status, then send one smaller controlled request. That sequence keeps the evidence readable.
| Time | Action | What it proves |
|---|---|---|
| 0-1 | Save body and headers | whether the branch is rate, quota, billing or unknown |
| 1-3 | Check Limits, Usage and Billing | whether the account has capacity or billing state problems |
| 3-5 | Compare model and endpoint | whether a stricter or shared model family is involved |
| 5-7 | Check OpenAI Status | whether a public incident changes the response |
| 7-10 | Send one smaller controlled request | whether workload size or account state is likely |
If the smaller request works, investigate concurrency, token size, image throughput or fan-out. If it fails with quota wording, stop retrying. If unrelated endpoints fail during a declared incident, preserve evidence and wait rather than rotating accounts.
retryとbackoffが正しい場合
Retry and backoff are correct only for temporary request or token pressure. The useful signals are rate-limit wording, low remaining values, reset timing, and a traffic pattern that exceeds the current project/model budget. Retry is not a magic repair; it is a pacing tool.
Use exponential backoff with jitter, cap retry count, and add a central limiter per project and model family. A limiter inside each worker is not enough if workers do not share state. Estimate token size before dispatch, because reducing prompt size or max output can remove TPM pressure before the API rejects the request.
Failed requests can still count toward minute limits. A fleet that retries every second can keep itself inside the failure window. A good system slows down, queues, sheds non-urgent work, or uses Batch for async work.
retryしてはいけない場合
Retry is wrong when the error points to insufficient_quota, current quota, billing, monthly spend or account state. Waiting a few seconds does not add quota. The correct path is Billing, Usage, Limits, spend cap, organization, project and model access.
Many "I have credits but still get 429" cases are scope problems. The credit can be in another organization. The request can use another project. A monthly spend cap can be active. A model can be unavailable to that project. A wrapper can be applying its own pool. Keep one minimal request stable while checking each scope.
新しいAPI keyで直らない理由
An API key is not a separate capacity bucket. A new key helps when the old key is revoked, leaked, restricted or attached to the wrong project. It does not create capacity if organization, project, model family and billing owner remain the same.
| Scope | Check | Failure pattern |
|---|---|---|
| Organization | request uses the intended org | personal and team orgs have different billing or limits |
| Project | key belongs to the inspected project | Limits checked in one project, traffic sent from another |
| Model family | selected model has access and headroom | stricter or shared family limit is exhausted |
| Team workload | other services share capacity | batch job or another app consumes the pool |
If one model fails, test a small request to a model the project can access. If every model fails with quota wording, inspect account state first. If the key works elsewhere, inspect concurrency and request shape in the failing service.
headersとLimitsをライブ証拠にする
The live evidence is the response plus the account. The body gives the branch. Headers can show limit, remaining and reset timing. The Limits page gives the current project, organization and model context. Any static table is weaker than the reader's own live evidence.
| Evidence | Why it matters |
|---|---|
| status and body | separates retryable rate pressure from quota or billing |
| request id | gives support a lookup handle |
| rate-limit headers | shows limit, remaining and reset timing |
| project and organization | confirms who owns the request |
| model and endpoint | exposes stricter model or wrong endpoint |
| Limits and Usage state | records account state during failure |
| Status snapshot | separates incident from account-local failure |
On 2026-04-29 the public OpenAI Status check did not show a broad active incident. That does not guarantee future health. During an incident, check Status live; if it is green, continue through account scope, headers and workload shape.
productionで次の429を減らす
After the immediate recovery, move the lesson into production controls. The application should know its budget before OpenAI rejects it: project/model limiters, tenant budgets, token estimates, queue alerts, retry counters and reset-window observations.
Interactive traffic and background jobs should not compete blindly. Queue non-urgent jobs. Split tenants. Reduce prompt size when possible. Route simpler work to cheaper or lower-pressure models when that is an approved product decision. Use Batch when latency is not urgent and the workload fits.
別surfaceを先に切り分ける
"OpenAI API 429" should mean a Platform API call made by code. ChatGPT, Codex, Sora, Azure OpenAI and wrappers can show limit messages too, but the owner and fix are different.
| Surface | Do not assume | Check instead |
|---|---|---|
| ChatGPT | consumer plan changes API quota | ChatGPT product limits and account state |
| Codex | coding-agent limits equal API RPM/TPM | Codex product contract and status |
| Sora | video capacity equals text API limits | Sora route, queue, plan and video status |
| Azure OpenAI | OpenAI Platform Limits owns deployment | Azure quota, deployment, region and subscription |
| Wrapper | OpenAI headers always pass through | provider dashboard, docs, route id and upstream evidence |
If the request is not sent directly to api.openai.com, identify the provider boundary first. The wrapper may be full, may translate an upstream 429, or may enforce its own account cap.
証拠をそろえてエスカレーションする
Escalate only after the branch is stable and secrets are removed. A compact packet should include timestamp, timezone, request id, endpoint, model, SDK version, organization, project, billing owner, safe body, safe headers, Limits and Usage state, Status state, retry count, concurrency, prompt size, queue depth and recent changes.
Do not post API keys, bearer tokens, card details, private prompts or user data in public places. Clean evidence is faster for support and safer for users.
よくある質問
OpenAI API 429は全部retryできますか？
できません。本文とheadersが一時的なrequest/token pressureを示すときだけretryします。insufficient_quotaはBilling、Usage、Limits、project、organization、model accessを見ます。
insufficient_quotaとは？
quota、billing、spend cap、account stateの問題です。短い待機では解決しないため、同じproject/orgで確認します。
クレジットがあるのに429が出る理由は？
別organization/project、monthly spend cap、billing反映待ち、model access、shared family limit、wrapper poolなどがあります。
API keyを増やすと制限は増えますか？
同じproject/orgなら増えません。keyはcredential問題を直せてもquota poolは作りません。
どのheadersを見るべきですか？
limit、remaining、resetを示すrate-limit headersです。必ずLimitsページと合わせて読みます。
OpenAI Statusは見るべきですか？
はい。incidentがあれば待機と証跡保存、greenならaccount、headers、Limits、workloadの確認へ進みます。
ChatGPT PlusはAPI quotaと同じですか？
違います。ChatGPTのconsumer planとOpenAI Platform API billingは別です。
supportには何を送りますか？
timestamp、timezone、request id、endpoint、model、project、organization、error body、safe headers、Limits/Usage、Status、retry count、workload、recent changesです。
