“The model is overloaded” is the one Gemini error that isn't about you: the serving pool for that model has no capacity right now. Nothing in your project settings can prevent it — what you control is how gracefully you ride it out, and which fallback you reach for when it doesn't pass.
The error
{
"error": {
"code": 503,
"message": "The model is overloaded. Please try again later.",
"status": "UNAVAILABLE"
}
}Causes and fixes at a glance
| Cause | Fix |
|---|---|
| Demand spike on that model's serving pool | Exponential backoff with jitter; the spike usually passes in seconds to a few minutes. |
| Preview / experimental model variants | -exp and preview builds run on small pools and overload first. Pin the stable alias for production. |
| Heavy requests during peak hours | Huge contexts and max output caps are likelier to be shed under load — trim what you don't need, stream the response. |
Confirm it's 503 UNAVAILABLE, not 429
429 RESOURCE_EXHAUSTED is your quota; 503 UNAVAILABLE is Google's capacity. The distinction decides everything downstream: quota errors need billing or limit changes, capacity errors need retries and fallbacks. Don't debug your project settings for a 503 — there's nothing there to find.
Retry with backoff — but with a budget
503 is retryable by definition. Use the same jittered exponential backoff as any 429 (the snippet in our Claude 429 guide works unchanged — it already retries 500-class statuses), but cap the total wait at what your caller can absorb; an overload that outlives ~5 attempts over a minute isn't going to pass quickly.
When retries exhaust: change the model, not the loop
Have a fallback chain ready before you need it: the stable alias if you were on a preview build, gemini-2-5-flash if 2.5 Pro is the one struggling (or vice versa), or a different provider entirely for the request that must not fail. Fallbacks turn an outage into a quality downgrade.
If you’re calling through Kunavo
This failure mode is why Kunavo retries inside the request: when a model has more than one upstream channel configured, a failed attempt fails over to the other channel before you ever see the error — a transient upstream failure becomes a slower success instead of your 503. Failed requests are never billed, and because one key covers Gemini, Claude and GPT, the cross-provider fallback in step 3 is a model-string change rather than a second integration. Weighing a fallback model? Per-token rates for the whole Gemini family, next to Google's list prices, are on the Gemini API price list.
FAQ
Am I charged for requests that return 503?
No — the request is rejected before inference, so Google doesn't bill it, and on Kunavo failed requests are never billed either. The cost of a 503 is latency and retries, not tokens.
How long do Gemini overloads last?
Usually seconds to a few minutes; launch-day spikes on a new model can run longer. That's why the sane policy is a handful of backoff retries, then a fallback model — not an unbounded retry loop.
Does upgrading to paid tier stop 503s?
No. Paid tiers raise your quotas (the 429 family), but 503 UNAVAILABLE is shared serving capacity — free and paid traffic both see it when a pool is saturated. Fallbacks are the mitigation, not billing.
Related guides
- Google Gemini API pricing September 2026 — official list & per-token rates 2026
- Gemini 3 API — pricing, availability, and the live way to call Gemini today
More error semantics live in the error reference; getting a key takes a minute via sign up and the authentication docs.