How to Fix Gemini 429 Too Many Requests (Rate Limit) — Practical Checklist (2026)

Seeing 429 Too Many Requests from Gemini? Usually, you’re sending requests too quickly or you’ve used up an allowance. Stop repeatedly pressing retry. If requests are too frequent, slowing down can help. If today’s allowance is used up, waiting a few seconds won’t fix it.

What Gemini 429 means (and what it does NOT mean)

• 429: a usage limit is blocking the request. Check which limit before trying again.
• 503: the service may be overloaded. Follow the Gemini 503 fixes instead.
• 401/403: check your key and permissions. Start with Gemini API key setup.

Quick fix checklist (do these first)

Open your project’s usage limits in AI Studio and compare them with the error message. Then choose the matching fix:

1. Too much activity in a short time? Send requests less often. If you’re sending too much text, shorten the prompts too. For an automatic retry, increase the wait between attempts rather than retrying continuously; the code example below shows how.
2. Today’s allowance used up? Pause the job until the daily limit resets, or check whether a higher allowance is available. A few seconds of waiting will not restore the daily allowance.
3. No allowance for this model? Check that your project can use it and whether it requires a different plan or billing setup. Don’t keep retrying a request that your project cannot currently make.

Not sure which applies? Check the error details before adding retries. To reduce repeat work, run fewer requests at once and reuse previous results when the input is unchanged and the result is still suitable.

Common causes of Gemini 429

AI Studio uses three common labels: requests per minute (RPM), input tokens per minute (TPM), and requests per day (RPD). RPD resets at midnight Pacific time. A zero allocation means checking model access, tier or billing instead of waiting for a short retry. The limits vary by model and project tier, so there is no universal safe number of simultaneous requests.

1) Too many requests per minute (RPM)

Typical trigger: a script loops through rows and calls the API once per row. If you have 1,000 rows, you can hit limits quickly.

2) Too much concurrency

Even if your average rate is OK, sending requests in parallel spikes instantaneous load. Many environments (serverless, queue workers) accidentally do this by default.

3) Shared project usage (multiple apps/users)

If multiple services share the same Google project, they also share quotas. Limits apply per project, not per API key. One noisy job can push everyone into 429; creating another key in that project does not add quota.

A safe retry strategy (exponential backoff + jitter)

Retry only a confirmed transient limit. For daily exhaustion, wait for reset; for unavailable quota, fix access or billing first. If the cause is unclear, inspect it rather than assuming a retry will help. Check your SDK’s automatic retries before adding another retry loop.

// Pseudocode (language-agnostic)
// classifyQuota inspects the error details and active model/project limits.
// It returns "transient", "daily_exhausted", "unavailable", or "unknown".
// callGemini must have a request timeout; do not replay downstream actions.
maxRetries = 6
baseDelayMs = 1000
maxDelayMs = 30000

for attempt in 0..maxRetries:  // inclusive: 1 initial call + at most 6 retries
  res = callGemini()
  if res.ok:
    return res

  if res.status != 429:
    throw res.error
  if classifyQuota(res) != "transient":
    throw res.error  // wait for reset or resolve/inspect the quota issue
  if attempt == maxRetries:
    throw res.error  // no sleep when there is no next attempt

  jitter = random(0, 250)
  delay = min(maxDelayMs, baseDelayMs * (2 ** attempt) + jitter)
  sleep(delay)

Batching: fix the “one row = one request” trap

If you’re classifying or summarizing rows, batch them. Choose a batch size that fits your token limits, request JSON with stable row IDs, then validate and map results back to the sheet. Combining rows is not the separate asynchronous Batch API and does not remove TPM limits.

If you prefer not to manage API keys at all, you can use Gemini in Google Sheets with AI for Sheets formulas (no coding and no API key required).

Monitoring and prevention

• Log 429 rate: track how often it happens and which job causes it.
• Queue work: a simple queue smooths bursts and keeps you under limits.
• Coordinate shared usage: budget requests across apps in the same project. Use the official quota-increase process when needed, not project or key rotation to bypass limits.

FAQ

Is 429 a permanent ban?

Usually no, but it does not always clear after a few seconds. Transient limits can recover with backoff; exhausted daily quota needs a reset, while unavailable allocation needs an access, tier or billing check.

Why do I see 429 in bursts even with a low average rate?

Concurrency spikes are one possible cause. Input TPM or another app sharing the project can also exhaust a limit. Check the failed quota, then pace requests and reduce token volume as appropriate.

Should I switch models when I hit 429?

Limits differ by model and tier, so another supported model may have available quota. Verify its access, price and task suitability first. Switching is not guaranteed to fix the exhausted limit, and another key in the same project does not add quota.

Next step

If you’re unsure whether your error is rate limiting or service capacity, compare this guide with Gemini 503 overload and Gemini API key troubleshooting.

Official guidance checked 10 September 2026: https://ai.google.dev/gemini-api/docs/rate-limits and https://ai.google.dev/gemini-api/docs/troubleshooting.