Gemini API Error 429: Check the Project Before Rotating Keys

A Gemini API 429 RESOURCE_EXHAUSTED response usually means the project has crossed a request, input-token, daily-request or spend-rate limit. Check the project, model and quota evidence before changing credentials: another key in the same project does not provide a new project-level allowance.

The remedy depends on the exhausted dimension. RPM or TPM pressure may clear with controlled retries and lower concurrency; RPD requires waiting for the daily reset; spend-rate pressure calls for slower or less expensive requests. If those quotas appear available, inspect billing and account controls rather than assuming every 429 has the same cause.

Confirm which project made the call

Record the HTTP status, structured error details, model, project identifier and request time. Trace the deployed credential to its Google Cloud project, then inspect that project in Google AI Studio. This catches common configuration mismatches such as a production service using a staging key or an old deployment retaining a previous secret.

Google’s Gemini API rate-limit documentation defines RPM, input TPM and RPD as separate dimensions, says exceeding any one can trigger an error, and applies the limits per project rather than per API key. It also says RPD resets at midnight Pacific time, limits vary by model and tier, spend-based limits use a rolling ten-minute window, and batch requests have limits separate from non-batch calls.

Creating key B beside key A therefore does not reset the project’s RPM, TPM or RPD usage. Switching keys is useful only when correcting a credential or project mismatch; a different credential string inside the same project is not additional capacity.

Identify the exhausted dimension

Do not diagnose from the status code alone. Preserve any quota metric, limit name and retry information returned with the error, then compare them with the failed model and the correct project’s usage views. A generic application message such as “try again later” removes the evidence needed to choose a safe response.

• RPM: too many requests entered the minute window. Bursty parallel workers can exhaust it even when the longer-term average looks modest.
• TPM: too many input tokens entered the minute window. A few large prompts can exhaust TPM while request count remains below RPM.
• RPD: the project has consumed its daily request allowance. Additional retries cannot bring the reset forward.
• Spend-rate limit: paid traffic crossed the applicable rolling spending control. This condition returns 429 RESOURCE_EXHAUSTED and may clear after traffic slows.
• Billing or spend control: depleted prepaid credit, a project spend cap, a billing-account cap or an account-status problem can pause service. These controls require billing diagnosis and should not automatically be labelled as the quota named by a 429.

Usage displays are not necessarily real-time. The Google AI Developers Forum guidance below notes a delay of about 15 minutes for the quota view, while Google’s billing documentation says some cost displays can take substantially longer. Compare the dashboard’s metric, model and time window with the failed call instead of treating a recent low-looking graph as conclusive.

Follow the evidence to the remedy

1. If the credential belongs to the wrong project, correct the deployment configuration and send one controlled test request.
2. If RPM is exhausted, queue calls, reduce concurrency and use bounded exponential backoff with jitter.
3. If TPM is exhausted, reduce simultaneous large prompts, remove unnecessary context and constrain requested output before retrying.
4. If RPD is exhausted, pause nonessential traffic until the documented daily reset. Do not run a rapid retry loop.
5. If the error identifies a spend-rate limit, reduce the rate or cost of requests and retry after the rolling window can clear.
6. If quota usage is below the expected limits, inspect the project’s tier, billing status, prepaid balance, project spend cap and billing-account cap.

The billing branch can affect more than one key or project. Google’s Gemini API billing guide says API keys have no independent billing settings, all keys in a project contribute to its spend cap, and linked projects contribute to the billing account’s total. A zero Prepay balance stops every Gemini API key funded by that account, while reaching a monthly billing-account cap pauses linked projects until the next billing cycle.

Retry only when time can restore capacity

For RPM or TPM pressure, route retries through the same project-wide limiter as first attempts. Increase delays exponentially, add jitter so workers do not wake together, and impose both an attempt limit and an overall deadline. If the response includes a retry delay, use it as an input to that bounded policy.

A local counter in each application instance is insufficient when all instances share one project. Coordinate admission centrally or divide a conservative project-wide budget among workers; otherwise, each worker can appear within its own limit while their combined traffic exceeds the project allowance.

Do not retry an unchanged request continuously after RPD exhaustion or a hard billing stop. Return a typed operational error, suppress background retries and resume only after the relevant reset or billing correction. This prevents one quota failure from multiplying into a retry storm.

Choose batching or more capacity for sustained demand

The Batch API fits asynchronous classification, extraction and bulk-generation jobs. Its requests use separate limits from non-batch calls, but batching is not unlimited: it has its own concurrent-request, file-storage and enqueued-token constraints. Keep latency-sensitive work on the interactive path and move only workloads that can tolerate deferred completion.

A higher tier or rate-limit increase is appropriate when legitimate production demand remains above the available allowance after controlling concurrency, prompt size and duplicate work. Include the correct project, model, observed dimension and expected traffic profile in a request for more capacity; an isolated burst is better handled at the caller.

Keep quota exhaustion separate from service overload

A 503 UNAVAILABLE response indicates temporary service unavailability, not proof that the project exceeded its quota. Key rotation does not diagnose service overload, and a quota dashboard cannot establish whether an overloaded service is ready again.

A February 20, 2026 Google AI Developers Forum troubleshooting post tells developers investigating 429 errors to verify the key’s project and inspect its Quota and Rate Limit tabs. It recommends backoff for RPM or TPM pressure, treats 503 overload as unrelated to quota, and suggests the Batch API for suitable non-real-time jobs.

The reliable sequence is to identify the project, preserve the quota evidence and match the response to the limit’s reset mechanism. Rotate a key for exposure, revocation or a genuine project-assignment problem—not as a substitute for diagnosing shared capacity.

Also read:

• “Open Weight” Does Not Mean Safe for Commercial Use—Check the License Chain
• An SEM Audit Can Optimize the Wrong Goal—Check This Before Keywords
• Crypto Trading Bots Don’t Run on Autopilot—Keys and Rate Limits Decide the Risk