Figures on this page were verified 31 August 2026 against the providers' own documentation. Pricing, context windows and rate limits change without notice, so confirm any number against the provider before you rely on it. Tell us if something here is out of date.
An insufficient_quota error is a billing problem wearing a rate-limit costume. It arrives as HTTP 429, the same status as an ordinary rate limit, but it means your account has no usable credit or has hit a spending cap. Backoff and retry will never clear it. The fix is on the billing page, not in your code.
What the error looks like
OpenAI returns a 429 with an error.type of insufficient_quota:
{
"error": {
"message": "You exceeded your current quota, please check your plan and billing details.",
"type": "insufficient_quota",
"param": null,
"code": "insufficient_quota"
}
}Anthropic expresses the same condition differently. A depleted balance usually surfaces as a 400 invalid_request_error mentioning credit, while genuine pacing limits come back as 429 rate_limit_error. The practical consequence is identical: one of these you retry, the other you pay.
Why a billing failure uses the rate-limit status code
HTTP 429 means “too many requests” in a broad sense: you have asked for more than you are currently entitled to. Providers fold quota exhaustion into that definition because, from the API’s perspective, your entitlement is zero. It is defensible as protocol design and miserable in practice, because the single most common retry rule in production code is “retry on 429”, and that rule turns a billing problem into an infinite loop that burns your rate limit and logs thousands of identical failures.
Tell the two apart before you retry
Branch on the error body, never on the status code alone.
| Signal | Pacing limit | Quota exhausted |
|---|---|---|
| HTTP status | 429 | 429 (OpenAI), often 400 (Anthropic) |
| Error type | rate_limit_exceeded, rate_limit_error | insufficient_quota |
Retry-After header | Usually present | Absent |
| Clears on its own | Yes, in seconds | Never |
| Correct response | Exponential backoff | Stop, alert a human |
class QuotaExhausted(Exception):
"""Not retryable. A person has to add credit."""
def classify_429(response):
body = response.json().get("error", {})
kind = body.get("type") or body.get("code") or ""
if kind == "insufficient_quota":
raise QuotaExhausted(body.get("message", "billing quota exhausted"))
return "retry" # ordinary pacing limitRaising a distinct exception matters more than it looks. It lets your retry decorator ignore this failure entirely, and it gives your alerting something specific to page on. A billing outage that is logged as “rate limited” will be diagnosed hours late.
The four things that actually cause it
- The prepaid balance is zero. Most common on OpenAI, where API credit is bought up front and does not auto-refill unless you enable it.
- A monthly budget or hard limit was reached. The account has credit but you configured a ceiling and the month’s usage met it. This is the one that surprises teams, because nothing was wrong until a traffic spike.
- The payment method failed. An expired card silently stops auto-recharge, and the first symptom is a 429 in production.
- You are calling the wrong project or organisation. Credit sits on one project and the key belongs to another. The key authenticates fine, which is why this looks like a quota bug rather than a configuration one.
How to stop it happening in production
Quota exhaustion is fully predictable, which makes it one of the few API failures you can engineer away rather than merely handle.
- Enable auto-recharge with a threshold well above one day of peak spend, and keep a second payment method on file.
- Alert on balance, not on errors. Poll your usage endpoint on a schedule and warn when the remaining balance drops below a week of typical burn. By the time a 429 appears you are already down.
- Set the hard limit above your alert threshold, not at it. A hard limit is a circuit breaker for runaway spend, not a budget target.
- Forecast before you scale. Our API cost calculator prices a workload across every major model, which is the number your limit should be set against.
- Degrade rather than fail. If a cheaper model or a cached answer is acceptable, fall back to it and keep serving users while somebody tops up the account.
Related errors
If your 429 is not a quota problem, it is a pacing one: see 429 rate limits and how to back off correctly. If authentication itself is being rejected, that is a 401 invalid_api_key, which has entirely different causes. The full map is in the LLM API error reference.
Frequently asked questions
Why does a billing problem return a 429?
HTTP 429 means you have asked for more than you are currently entitled to, and when your quota is exhausted that entitlement is zero. It is defensible protocol design, but it collides with the most common retry rule in production code, retry on 429, which turns a billing failure into an infinite loop.
Will waiting fix insufficient_quota?
No. Unlike a pacing limit it never clears on its own. Someone has to add credit, raise the spending cap, or fix a failed payment method. Your code should stop and alert a human rather than back off and retry.
My account has credit but I still get this error. Why?
Usually a monthly hard limit that has been reached, or a key belonging to a different project or organisation than the one holding the credit. The key authenticates perfectly well, which is why this reads as a quota bug rather than the configuration mistake it is.
