"You exceeded your current quota" / insufficient_quota: three different limits, one message

Q: Should I retry a 429 quota automatically?

No. Neither quota nor insufficientbalance clears with waiting. Raise the limit, top up, or switch keys — a retry loop just spends your 20 RPM ceiling finding that out repeatedly.

"You exceeded your current quota" is OpenAI's own wording for a billing problem on OpenAI's own platform: no payment method on file, a spend cap reached, or trial credits used up. It has nothing to do with request rate despite the 429 status. On go2llm, the closest-sounding thing you can hit is actually two separate mechanisms — a per-key dollar quota (status 429, type quota) and an empty account balance (status 402, type insufficient_balance) — and they call for different fixes. Reading error.type is what tells the three apart; the word "quota" alone doesn't.

Written 2026-09-30.

What each one looks like

OpenAI's own API, when your OpenAI account itself has no billing headroom:

{
  "error": {
    "message": "You exceeded your current quota, please check your plan and billing details.",
    "type": "insufficient_quota",
    "param": null,
    "code": "insufficient_quota"
  }
}

go2llm, when the *key* you're using has a configured dollar quota and this call would push spend past it:

{
  "error": {
    "type": "quota",
    "code": "quota",
    "message": "quota exceeded",
    "request_id": "gw_2c7e91a3f0b8465db3f01c9a4e7d5b2c"
  }
}

go2llm, when the *account* behind the key is simply out of money — a different status entirely:

{
  "error": {
    "type": "insufficient_balance",
    "message": "not enough spendable balance"
  }
}

Three different meanings, and only one of them — go2llm's 429 quota — shares OpenAI's status code. Don't branch on the status; branch on error.type — on a text completion, go2llm's own 402 insufficient_balance doesn't carry an error.code or request_id at all, just type and message.

What each one actually means, and how to tell them apart

go2llm's `429 quota`: a per-key cap you set yourself

Every go2llm key can carry its own dollar quota, configured in the dashboard when the key is created. It's optional — a key created with no quota set is limited only by the account's balance, not by any separate per-key number. When a quota *is* set, the gateway checks it before every call: if this call's estimated cost would push the key's total spend past its quota, the call is refused with 429 quota even if the account behind it is otherwise well funded. This is the most likely cause if you're seeing this exact code on go2llm — it's a limit you (or whoever issued the key) configured on purpose, usually to cap what one integration, one environment, or one client can spend.

go2llm's `402 insufficient_balance`: the account itself is empty

A different, more fundamental shortage — the account's spendable balance can't cover the estimated cost of this call, independent of any per-key quota. This is the condition closest in spirit to what OpenAI calls insufficient_quota: no money left to spend, full stop.

OpenAI's `insufficient_quota`: your OpenAI account, not go2llm

If you're calling api.openai.com directly and see this, it's specific to your OpenAI billing: no card on file, a spend limit set in the OpenAI dashboard reached, or free trial credits used up. Going through go2llm sidesteps this particular failure mode entirely — go2llm's own balance and quota mechanics replace it, with the two codes above.

A shared key, spent down by someone else's workload

A quota set for one purpose — say, a demo environment — gets consumed by a second workload someone pointed at the same key, and the demo starts failing with 429 quota for a reason that has nothing to do with the demo's own usage. This is a design problem more than a billing one: see the fix below.

Testing which one you're looking at

GET /v1/me answers with the key's own quota and the account's balance in one call, using the same key in x-api-key or Authorization: Bearer:

curl -s https://go2llm.tech/v1/me \
  -H "Authorization: Bearer $GO2LLM_API_KEY"

The response carries key.quota_usd and key.spent_usd (the per-key cap and how much of it is used) alongside balance.spendable_usd and balance.reserved_usd (the account's actual money). If spent_usd is at or near quota_usd, that's the key's own cap — raise it or issue a new key. If spendable_usd is at or near zero, that's the account balance — go top up. The two numbers are independent; a key can be nowhere near its quota while the account behind it is empty, or the reverse.

import httpx

def diagnose(api_key: str) -> str:
    r = httpx.get("https://go2llm.tech/v1/me", headers={"Authorization": f"Bearer {api_key}"})
    me = r.json()
    key, balance = me["key"], me.get("balance")
    if key["quota_usd"] and key["spent_usd"] >= key["quota_usd"] * 0.95:
        return f"key quota nearly spent: {key['spent_usd']}/{key['quota_usd']} USD"
    if balance and balance["spendable_usd"] < 0.05:
        return f"account balance nearly empty: {balance['spendable_usd']} USD spendable"
    return "neither limit looks close"

print(diagnose("YOUR_API_KEY"))

Fixing it

Key quota reached. Raise quota_usd on the key in the dashboard, or issue a fresh key for the workload with a quota sized to what it actually needs. A key created with the quota field left blank has no separate cap of its own — spend on it is bounded only by the account balance.

Account balance reached. Top up — the minimum is $1, paid by card through Platega or in crypto. Registration already credits $1 to a new account, which covers a first request without paying anything.

Hitting OpenAI's own insufficient_quota directly. That's an OpenAI account issue — add a payment method or raise the spend limit in OpenAI's own billing settings. Nothing on the go2llm side changes it, because the request never reaches go2llm in that scenario.

A shared key running dry from someone else's traffic. Give each workload, environment, or client its own key with its own quota. A batch job, a staging environment and a developer's laptop sharing one key share one quota and one balance, and any one of them can exhaust it for the other two.

Avoiding it next time

Size each key's quota to the workload it's actually for, and track spend as you go with usage.cost_usd from every successful response rather than discovering the ceiling from a failed call:

budget_usd, spent = 5.00, 0.0
for doc in documents:
    if spent >= budget_usd * 0.9:
        print(f"90% of budget used after {processed} docs — stopping before the quota does it for you")
        break
    result = call(build_payload(doc), api_key)
    spent += result["usage"]["cost_usd"]

Never retry a 429 quota in a loop — the number doesn't move while you wait, unlike a plain rate limit. Poll GET /v1/me before a large batch run instead of finding out mid-run.

Related errors

402 insufficient_balance — the account itself is out of money, a different code and status from key quota.
429 rate_limit_error — too many requests per minute, unrelated to money.
The full error reference.

FAQ

Is go2llm's 429 quota the same thing as OpenAI's insufficient_quota? Conceptually adjacent — both mean "this key or account can't spend any more right now" — but they track different things. OpenAI's is your OpenAI account's own billing state. go2llm's quota is a per-key dollar cap you configured yourself, separate from the account balance, which is 402 insufficient_balance instead.

Does every go2llm key have a quota? No. The quota field is optional per key. Leaving it blank means the key has no separate cap of its own — spend is limited only by the account's balance.

Should I retry a 429 quota automatically? No. Neither quota nor insufficient_balance clears with waiting. Raise the limit, top up, or switch keys — a retry loop just spends your 20 RPM ceiling finding that out repeatedly.

Does a rejected request count against the quota? No. The estimate is reserved before the call and released if the call doesn't go through, the same reserve-and-settle mechanism used for every other rejection — a 429 quota or 402 response itself never moves spent_usd.

Get a key and make your first request in 3 minutes → go2llm.tech. Registration credits $1 to your balance. Per-model prices are on the pricing page, setup steps are in the docs.