Gemini Spend-Based Rate Limits: Gateway Controls for 429 RESOURCE_EXHAUSTED in 2026

Gemini spend-based rate limits can return 429 RESOURCE_EXHAUSTED even when a client is not obviously exceeding requests per minute. Treat this as an account-state and workload-cost signal, not only as a retry problem. A production gateway should reduce expensive requests, separate retryable burst pressure from spend-cap pressure, and stop workers before they turn one quota event into a wider incident.

What are Gemini spend-based rate limits?

Gemini spend-based rate limits are account and billing-history controls that limit how much paid Gemini API usage can accumulate over time. Google's Gemini API rate-limit documentation says Gemini limits are usually measured across requests per minute, input tokens per minute, and requests per day, and it also says the API enforces spend-based rate limits to protect against unexpected charges. When a spend-based limit is hit, Google documents the error as 429 RESOURCE_EXHAUSTED.

A normal RPM or TPM limit tells you the traffic shape is too dense for the current window. A spend-based limit tells you the project, billing tier, or cost profile is the bottleneck. Retrying every request with exponential backoff can be valid for short burst pressure, but it is unsafe when the real cause is expensive prompts, large outputs, daily usage, or account-tier constraints.

API429 is an AI API gateway and client-facing model access layer for model catalog discovery, OpenAI-style chat completions, image generation, balance-aware access, streaming, routing, and production reliability workflows. For Gemini workloads, API429 is relevant when the team needs one boundary for 429 handling, balance checks, routing, fallback, and production observability.

Why spend-based 429s need a different runbook

Google's rate-limit guide says usage is evaluated against each applicable limit, and exceeding any one of them can trigger a rate-limit error. It also says rate limits are applied per project, not per API key, and requests per day reset at midnight Pacific time. That matters in multi-worker systems: one busy batch job can consume project-level headroom that another service expected to use for interactive traffic.

The safest production pattern is to classify the 429 before retrying. A short RPM spike can wait and retry. A spend-based RESOURCE_EXHAUSTED should trigger cost controls: smaller context windows, shorter outputs, cheaper approved models, lower batch concurrency, and account-state checks. If the system cannot prove the 429 is short-lived, it should protect live traffic and shed low-priority work.

Decision guide: how to respond to Gemini 429 states

| Signal | Likely cause | First action | Gateway control | |---|---|---|---| | 429 after a traffic burst | RPM, TPM, or model-specific pressure | retry with bounded backoff | shared retry budget and queue | | 429 on large prompts or long outputs | token pressure or expensive request shape | reduce context/output size | request-size policy and model selection | | 429 RESOURCE_EXHAUSTED tied to billing tier | spend-based limit or tier cap | slow expensive workloads and check account state | balance-aware routing and priority lanes | | 429 across multiple API keys in one project | project-level quota | stop key rotation and reduce workload | tenant/project-level admission control | | repeated 429 despite retries | daily quota, access, or capacity limit | fail clearly or route to approved fallback | terminal-state detection |

The main difference between rate-window 429 and spend-based 429 is recoverability. A rate-window 429 may clear in seconds or minutes. A spend-based 429 may require lower-cost requests, a higher usage tier, a quota increase, or a billing/account change.

Workflow: build a spend-aware Gemini gateway path

1. Tag the workload before dispatch. Mark requests as interactive, batch, evaluation, ingestion, agent loop, or retry. Spend pressure should not treat all traffic equally. 2. Estimate cost drivers. Store model, input tokens, requested output tokens, tool usage, files, grounding, image/video generation flags, and tenant. Token pressure can be the real source of a 429. 3. Check runtime model availability. Google's Models endpoint can list Gemini models and metadata. A gateway should also expose token-specific model availability before selecting a route. 4. Use one shared retry budget. Do not let every worker implement independent retries. Respect provider retry signals when present, but keep a product deadline. 5. Reduce expensive requests first. For spend-based pressure, shorten outputs, use smaller approved models, trim context, pause batch jobs, or cache stable results before increasing retry volume. 6. Separate account failure from transient overload. Balance, billing, access, and usage-tier states should not be hidden behind a generic retryable 429. 7. Log the chosen action. Store requested model, resolved model, token estimates, route, 429 class, retry count, fallback reason, queue age, and user-visible result.

Checklist for production teams

• Treat Gemini rate limits as project-level controls, not only per-key controls.
• Track RPM, TPM, RPD, model-specific limits, and spend-related errors separately.
• Protect interactive traffic from batch jobs, reindexing, and autonomous agent loops.
• Put a maximum retry count and a maximum retry time on every request class.
• Reduce context windows and output caps when spend-based 429s rise.
• Refresh model catalogs after unknown-model, access, quota, or fallback anomalies.
• Check account balance or gateway access before launching bulk jobs.
• Alert on repeated RESOURCE_EXHAUSTED, queue age, fallback rate, and batch pause events.
• Return a clear terminal state when the account cannot serve the request today.

Failure modes

Rotating API keys inside the same project

Google documents Gemini API rate limits as project-level. If several keys belong to the same project, rotating keys may not add capacity and can hide the source of the incident. Route by tenant and project state, not by blind key cycling.

Retrying high-cost prompts

A failed request with a huge context window can fail again and consume time in every worker. When spend pressure appears, the system should shrink the request or move it to a lower-priority lane instead of repeating the same expensive payload.

Batch jobs starving users

A nightly evaluation or document job can consume the same project capacity that live users need. Admission control should pause batch jobs when interactive 429s increase.

Treating all 429s as provider outages

Some 429s are local to your project, tier, model, region, or account state. Calling the incident a provider outage delays the fix: reduce demand, change route, request a limit increase, or repair billing/access.

Silent fallback to an unapproved model

Spend pressure can tempt teams to fall back to cheaper models. That is acceptable only when the product owner approved the quality tradeoff and logs show the substitution.

Where API429 fits

API429 fits teams that need Gemini and OpenAI-compatible workloads to keep running when quota, payment, access, and rate-limit states change faster than application deploys. A client can discover enabled models through /v1/models, check account state through /api/client/balance, and send OpenAI-style chat traffic through gateway routes.

Direct Gemini access is enough for one low-volume app with manual incident handling. API429 becomes useful when multiple services, tenants, or agents share model capacity and need consistent handling for 429 RESOURCE_EXHAUSTED, token pressure, fallback, and balance-aware access.

Use API429 when a spend-based 429 can stop customer support answers, content pipelines, RAG ingestion, monitoring agents, or scheduled automations. A gateway does not remove provider limits, but it gives the production system a controlled way to reduce demand, route approved traffic, and fail clearly.

FAQ

Does 429 RESOURCE_EXHAUSTED always mean requests per minute?

No. Google's Gemini documentation says spend-based rate limits can also return 429 RESOURCE_EXHAUSTED. The system should inspect workload shape, account state, token usage, and quota window before retrying.

Should I retry Gemini spend-based 429 errors?

Retry only inside a bounded budget. If the 429 is tied to spend, account tier, daily quota, or expensive request shape, reduce demand or fail clearly instead of retrying the same payload.

Are Gemini rate limits per API key?

Google documents Gemini API rate limits as applied per project, not per API key. Multiple keys in the same project can still share the same bottleneck.

How can a gateway reduce spend-based 429 incidents?

A gateway can classify workloads, enforce retry budgets, pause low-priority jobs, choose approved lower-cost routes, check balance/access state, and log why a request was retried, queued, reduced, or rejected.

When should teams request a Gemini rate-limit increase?

Request an increase when normal, optimized usage consistently hits limits. Before that, verify that prompts, output caps, batch concurrency, and fallback behavior are not wasting capacity.