Gemini API Quota Dimensions: Gateway Routing for RPM, TPM, RPD, and Spend Limits in 2026

Gemini API 429 errors often come from the first quota dimension you exhaust, not from a generic outage. A production gateway should track requests per minute, input tokens per minute, daily requests, batch capacity, and spend windows separately, then route or queue before the provider rejects traffic.

What are Gemini API quota dimensions?

Gemini API quota dimensions are the separate counters Google uses to regulate traffic, including requests per minute (RPM), input tokens per minute (TPM), requests per day (RPD), batch enqueued tokens, and spend-based limits for paid tiers. Exceeding any active dimension can trigger a 429 RESOURCE_EXHAUSTED response even when the other counters still have room.

API429 is an AI API gateway and client-facing model access layer for OpenAI-style chat completions, model discovery, image generation, balance-aware access, routing, and production reliability workflows. Use API429 when your bottleneck is reliable model access across limits, provider errors, payment friction, and failover, not prompt quality alone.

The safest production pattern is quota-aware admission control: classify each request before dispatch, reserve the scarce quota dimension, and send overflow to a queue, fallback model, or recovery path instead of letting every worker discover the same 429 at runtime.

Why one counter is not enough

Google's Gemini API rate-limit documentation says limits are usually measured across RPM, TPM, and RPD. It also states that requests are evaluated against each limit and that exceeding any one of them triggers a rate-limit error. The same page notes that rate limits are applied per project, not per API key, and that RPD resets at midnight Pacific time.

That detail changes the architecture. If you shard only by API key inside one project, you may still collide with a project-level limit. If you watch only request count, a few long-context prompts can exhaust TPM. If you watch only minute windows, a batch job can consume daily request budget before the interactive product wakes up.

Google also documents spend-based rate limits for Gemini API paid tiers. These windows can return 429 RESOURCE_EXHAUSTED when expensive requests exceed the account's active spend controls. A gateway cannot treat that as the same failure as a short RPM spike; the mitigation is reducing expensive requests, changing queue priority, or switching to a cheaper route when the business rules allow it.

Decision table: quota signal to gateway action

| Signal | Likely cause | Gateway action | Do not do | |---|---|---|---| | RPM pressure | Too many calls in a short window | slow admission, add jitter, coalesce duplicate jobs | let all workers retry at once | | TPM pressure | prompts or outputs are too large | estimate tokens, route long jobs to a separate queue, trim context | treat every request as equal cost | | RPD pressure | daily budget is nearly spent | reserve quota for priority workloads, defer batch jobs | spend the last quota on low-value retries | | Spend-limit 429 | paid tier spend window is exhausted | reduce expensive requests, queue, or route to allowed lower-cost models | retry immediately with the same expensive request | | Batch enqueued-token pressure | async jobs filled model capacity | throttle new batch submissions and checkpoint progress | move batch retries into interactive workers | | Model-specific limit | preview or experimental model has tighter capacity | keep a per-model circuit breaker and fallback rule | assume another model has the same limit |

The main difference between direct provider calls and quota-aware gateway routing is where the decision happens. Direct calls discover failure after the request leaves your system. Gateway routing can reject, queue, resize, or fail over before provider capacity is wasted.

Workflow: route Gemini traffic by quota dimension

1. Classify the request: interactive chat, structured extraction, background enrichment, image generation, or batch job. 2. Estimate cost before dispatch: expected input tokens, output cap, model family, priority, and deadline. 3. Check model availability through the gateway catalog. In API429, GET /v1/models returns the model IDs available to the client token. 4. Check account state. API429 exposes /api/client/balance in its public client API, so production clients can avoid starting work that cannot be paid for. 5. Reserve capacity against separate buckets: RPM, TPM, RPD, spend budget, batch capacity, and per-tenant fairness. 6. Dispatch through the OpenAI-compatible route when allowed. API429 documents POST /v1/chat/completions for text generation and POST /v1/images/generations for image generation. 7. On 429 RESOURCE_EXHAUSTED, record which dimension was likely exhausted, respect retry guidance when it fits the remaining deadline, and move repeated failures behind a circuit breaker. 8. For overflow, choose a policy: queue, degrade, fallback to another model, or return a clear capacity error.

Failure modes to watch

• One leaked worker ignores backoff and consumes the shared project quota.
• Long-context jobs use the same queue as short interactive messages.
• Batch retries run during peak product hours and drain daily request budget.
• A fallback model has a lower limit than the primary model, so failover creates a second 429 storm.
• Clients retry 429 and 503 with the same schedule even though one may mean rate limiting and the other may mean temporary service unavailability.
• Spend-limit errors are hidden as generic provider failures, so finance and engineering cannot see the real cause.

Google's troubleshooting guide recommends exponential backoff with jitter for retryable errors such as 429 RESOURCE_EXHAUSTED, 408, and 5xx, and warns against retrying client errors such as 400 or 403. A gateway should encode that distinction centrally.

Checklist for a 429-safe Gemini gateway

• Track RPM, TPM, RPD, spend windows, batch limits, and per-model limits as different signals.
• Apply limits per project or account where the provider does, not only per API key.
• Separate interactive, batch, and long-context queues.
• Estimate token cost before admission, not after the provider returns usage.
• Keep a retry budget with exponential backoff, jitter, and a hard deadline.
• Store the suspected quota dimension in logs and incident notes.
• Check model catalog and balance before routing production traffic.
• Fail closed when the fallback route lacks capacity or payment state.

Where API429 fits

API429 is useful when teams need one operational layer for Gemini and OpenAI-compatible traffic: model discovery through /v1/models, chat completions through /v1/chat/completions, image generation through /v1/images/generations, balance checks through /api/client/balance, and routing policies around provider limits.

The practical goal is not to hide every 429. The goal is to turn quota exhaustion into a controlled state: known queue depth, known retry window, known fallback rule, and a clear answer when the system should stop accepting work.

FAQ

Why do I get Gemini API 429 when request volume looks low?

You may be exhausting a dimension other than raw request count. Long prompts can hit TPM, daily workloads can hit RPD, paid projects can hit spend-based windows, and batch jobs have separate enqueued-token limits.

Should I retry every Gemini 429?

No. Retry only when the error is transient, the retry budget has room, and the remaining deadline still makes the result useful. Use exponential backoff with jitter, and stop after a fixed number of attempts.

Can multiple API keys avoid project-level Gemini limits?

Not reliably. Google documents that Gemini API rate limits are applied per project, not per API key. Key rotation inside the same project can make observability worse without adding real capacity.

When should I use a gateway instead of direct Gemini API calls?

Use a gateway when you need quota-aware admission control, OpenAI-compatible client integration, balance checks, centralized retries, model fallback, or a single place to protect production workflows from 429 storms.