Gemini API rate limits: what a 429 RESOURCE_EXHAUSTED means and how to detect it

Failure facts checked on the vendor’s docs on Nov 8, 2026.

The Gemini API has several ways to refuse a request, and three of them look alike from your client: a per-minute limit, a daily quota and a spend-based limit. All can arrive as a 429. Which one you hit decides whether waiting ten seconds, waiting until midnight or changing your billing is the fix.

What Google measures

Gemini limits are usually stated in three dimensions: requests per minute (RPM), input tokens per minute (TPM) and requests per day (RPD). Exceeding any one triggers an error. With an RPM limit of 20, the 21st request in a minute fails even if tokens are plentiful.

Three facts shape the rest of this page:

• Scope. Limits apply per project, not per API key. Several keys in a project share one budget, so a second key does not give you a second budget.
• Daily reset. RPD quotas reset at midnight Pacific time, not on a rolling 24 hours.
• Model differences. Limits vary by model. Image models can have images-per-minute limits, some models have daily token limits, and built-in tools have their own: Google Search grounding on newer models defaults to 1,500 RPD per project. Experimental and preview models are more restricted. Google also says stated limits are not guaranteed and capacity can vary.

The actual numbers for your project are in AI Studio, because they depend on tier and account standing. The docs do not publish one universal table.

Tiers and the spend-based limit

Projects sit in Free, Tier 1, Tier 2 or Tier 3. Tier 1 needs an active linked billing account. Tier 2 needs $100 paid plus 3 days from first payment, and Tier 3 needs $1,000 plus 30 days. Upgrades are automatic once you qualify: Free to Tier 1 is usually instant, later ones take up to 10 minutes.

Beyond RPM and TPM there is a spend-based limit, evaluated on a rolling 10-minute window: $10 for Tier 1, $200 for Tiers 2 and 3, and not applicable on Free. Google says whether it applies depends on billing history and account standing. Hit it and you get 429 RESOURCE_EXHAUSTED. Large contexts and long outputs reach it faster than request counts suggest, so a job with few but huge requests can trip it while RPM looks fine.

Batch jobs have separate limits, including 100 concurrent batch requests and a cap on enqueued tokens per model. Priority inference has its own limits, set at 0.3 times the standard limit by default.

429, 402 and the others

The code names in the middle rows come from the Interactions API error reference, which uses snake_case codes. Check which API your calls use. Google's retry advice: exponential backoff (1 second, 2, 4, 8), random jitter, retries only for transient errors such as 429, 408 and 5xx, and a hard cap on attempts. The Python SDK already retries up to four times starting near one second, so wrapping it in a second retry loop multiplies attempts.

Google's rate limit pages do not describe a Retry-After or x-ratelimit header, so there is no remaining-quota header to record. Your visibility has to come from your own counters.

import json, time
from google import genai
from google.genai import errors

client = genai.Client()

def generate(model, contents, attempt=1):
    t0 = time.time()
    try:
        r = client.models.generate_content(model=model, contents=contents)
        usage = r.usage_metadata
        print(json.dumps({"msg": "vendor call", "vendor": "gemini", "model": model, "status": 200,
            "attempt": attempt, "prompt_tokens": usage.prompt_token_count,
            "duration_ms": int((time.time() - t0) * 1000)}))
        return r
    except errors.APIError as e:
        print(json.dumps({"msg": "vendor call", "vendor": "gemini", "model": model,
            "status": e.code, "error_status": e.status, "attempt": attempt,
            "message": str(e.message)[:200]}))
        raise

What to alert on

• Share of calls with status 429, by model, against that model's recent level. Count RESOURCE_EXHAUSTED separately from 503.
• Local request counts per minute and per day, compared with the limits in AI Studio, because no header tells you.
• Tokens per request. A growing prompt raises both TPM use and spend per 10 minutes.
• Any 402. It needs a person, and retrying cannot fix it.
• Calls per day against RPD as midnight Pacific approaches.

Their limit or your bug

If one model 429s and the others do not, check that model's limits and whether it is a preview model. If every model 429s together, think project-wide: spend-based limit, a shared key used by another service, or a billing change. A daily-quota failure clustered shortly before midnight Pacific points at your total volume. Check that no second service shares the project.

Example: a batch of long prompts and a spend limit

This is an example, not output from a real project. A made-up contract-review service sends 30 long documents in a minute.

11:02:10Z msg="vendor call" vendor=gemini model=example-pro status=200 prompt_tokens=412000
11:02:19Z msg="vendor call" vendor=gemini model=example-pro status=200 prompt_tokens=398000
11:02:31Z msg="vendor call" vendor=gemini model=example-pro status=429 error_status=RESOURCE_EXHAUSTED attempt=1
11:02:33Z msg="vendor call" vendor=gemini model=example-pro status=429 error_status=RESOURCE_EXHAUSTED attempt=2

Request count is low, so RPM is not the cause. Prompts are very large, which points at TPM or the 10-minute spend limit. The fix is to spread the work out, not to retry harder.

Checklist

1. Log status, error_status, model, prompt tokens and attempt number on every call.
2. Retry only 429, 408 and 5xx, with exponential backoff, jitter and a cap.
3. Do not retry 402.
4. Keep your own per-minute and per-day counters.
5. Treat preview models as less reliable for capacity.
6. Use the Batch API for work that can wait.

Related: third-party dependency monitoring, LLM spend spikes and vendor degradation. If these calls reach Sazabi, the agent can watch the 429 share.