Gemini API Rate Limits: Diagnose and Resolve Production 429 Errors

A Gemini API 429 does not point to one universal limit. For the Gemini Developer API, limits depend on the project’s usage tier and the model or feature being called. First identify the project used by the failing credential, then check that project’s active limits. Limits are project-scoped, not key-scoped, so another key in the same project does not provide a separate quota. Google’s rate-limits documentation is the starting point. [1]

Use this order: confirm the API path and project → inspect active limits and the error details → reduce or pace traffic if a quota is being reached → retry only with bounded backoff when appropriate → verify recovery under the intended workload.

1. Confirm which Gemini product is making the request

Before changing quotas or retry behavior, identify the exact access path:

• Gemini Developer API: Use the official Gemini API rate-limits documentation. The steps below focus on this path. [1]
• Firebase AI Logic: Its provider quotas and Firebase’s own per-user quota are separate layers. Firebase documents four quota dimensions for its context—RPM, RPD, TPM, and TPD—and says provider limits depend on the selected provider. Those Firebase details are not a substitute for checking a direct Gemini Developer API project. [3]
• Gemini CLI: CLI request allowances and /stats model apply to Gemini CLI, not an application calling the API directly. For example, the CLI documentation’s 250-request daily allowance is specifically for unpaid-key Flash requests in the CLI context. [4]
• Vertex AI / Agent Platform: This is a separate Google Cloud product path with its own quota and capacity guidance. Don’t apply Gemini Developer API limits or instructions to it. [5]

For a direct API incident, record the project, model, endpoint or feature (including any built-in tool), request time, HTTP status, and full response body. This helps avoid confusing a limit from another project, model, or product with the one that failed.

2. Find the limit that applies to your project and model

Match the deployed credential to its project first. In Google AI Studio, open the API keys or Projects view and find the key-project pair corresponding to the credential configured in your production deployment. Google’s documentation says keys are associated with projects; the AI Studio table displays key-project pairs. Do not expose the key itself while checking this. [6]

Then check the active limits for that project:

1. In AI Studio, open Dashboard → Rate Limit. Google’s Gemini API documentation links to AI Studio to view active rate limits; the Google AI Developers Forum also identifies the Dashboard’s Rate Limit view. [1, 7]
2. Select or confirm the same project used by the deployed credential, then inspect the row for the model and any feature used by the failing request. AI Studio’s active view is the project-specific source; don’t substitute a quota number from another project or a general example. [1]
3. To check the project’s usage tier, use the Billing Tier shown in the AI Studio API keys/Projects table. The billing documentation says Gemini API rate limits are tied to the project’s usage tier and describes the tier in that table. [2]

If the project or model shown in AI Studio does not match the production request, resolve that mismatch before diagnosing the quota. The exact limits may differ by model, feature, and tier; there is no single quota number that applies to every production project. [1, 2]

Google documents these common Gemini Developer API dimensions: [1]

• RPM: requests per minute
• Input TPM: input tokens per minute
• RPD: requests per day

Other model- or feature-specific limits may apply. Daily request quotas reset at midnight Pacific time. Limits vary by model, and built-in tools can have their own limits. [1]

3. Diagnose what the 429 means

Compare the failed request’s project and model with the applicable limits and your traffic records. Check each applicable dimension: a project can hit a request limit even when token usage is below its limit, or hit a token limit while request volume is modest. Also check model- or feature-specific limits if the request uses a built-in tool or another feature with its own quota. [1]

Google’s Gemini API documentation also describes spend-based rate limits: reaching one can return 429 RESOURCE_EXHAUSTED. The documented remedies include waiting and retrying after a short period, reducing expensive request volume—for example, by using a smaller context or shorter output—or requesting an increase if normal usage repeatedly reaches the limit. [1]

A practical investigation:

1. Confirm the project. Verify which project the production credential is paired with. Multiple keys in the same project share project-level limits. [1, 6]
2. Check the model and feature. Look for model- or feature-specific limits in addition to RPM, input TPM, and RPD. [1]
3. Compare usage around the failure. Use application logs or telemetry to compare request counts and input-token volume with the project’s applicable limits. Treat this as an operational investigation, not a replacement for the project’s quota information.
4. Read the response body. Preserve the full error details in logs. If displayed limits and observed traffic do not explain the failure, investigate the specific response and documentation for the correct product rather than assuming a new API key or repeated retries will fix it.

4. Restore requests without creating a retry storm

Choose the response based on what the evidence shows:

• Requests or input tokens are reaching a per-minute limit: Reduce the send rate and smooth bursts. If the workload is parallel, use a shared limiter for the project rather than a separate limiter for each API key.
• The daily request limit is exhausted: A short retry loop will not restore the daily allowance. Wait for the documented reset at midnight Pacific time, reduce daily request volume, or consult the current rate-limits documentation for available options. [1]
• A spend-based limit is reached: Follow the documented remedies: wait and retry after a short period, reduce expensive requests, or request an increase if the limit is repeatedly reached during normal use. [1]
• The cause is still unclear: Avoid repeatedly resending at full speed. Preserve the response details and compare them with the applicable project limits before changing models or tiers.

For retryable errors, Google recommends exponential backoff: wait briefly before the first retry, then increase the delay between attempts. For custom retry logic, Google also recommends adding random jitter, retrying only documented transient errors, and setting a maximum retry count. [2]

Google’s troubleshooting guide gives the Python SDK as an example of automatic retries for transient errors: up to four retries, with an initial delay of about one second and a maximum delay of 60 seconds. Treat that as a Python example, not a guarantee of identical behavior across every SDK, version, or configuration. If your application adds retries around an SDK, check the combined behavior so retry layers do not multiply attempts unexpectedly. [2]

Retrying is not the same as removing a quota limit. Backoff may help with transient errors; it cannot create more daily quota or make sustained traffic fit under a per-minute limit. If you repeatedly hit a limit during normal use, open the official Gemini API rate-limits documentation and use its Request a rate limit increase section. Google documents this as an option, but does not guarantee an increase. [1]

Verify production recovery

After the relevant wait or traffic change, use this operational checklist—not a Google-mandated threshold:

1. Resume with a small, paced sample using the same project, model, and feature that failed.
2. Confirm that requests succeed and 429s have decreased.
3. Gradually restore the intended workload while comparing aggregate request and input-token volume with the applicable limits.

One successful request does not prove sustainable recovery. Confirm that the normal workload can run without again exceeding the diagnosed limit.

5. Reduce the chance of another production 429

• Track request count and input-token volume by project and model, not just by API key, because the documented limits are project-scoped. [1]
• Apply a shared rate limiter or queue for traffic using the same project; smooth bursts instead of allowing every worker to send or retry at once. This is an operational safeguard based on project-level limits and Google’s backoff guidance. [1, 2]
• Alert on rising 429 counts and compare them with applicable limits. Record the project, model, feature, timestamp, and response details so an incident can be matched to the relevant quota.
• Recheck applicable limits when changing models, usage tier, billing status, or features. Google notes that limits vary by model and tier. [1, 2]
• Keep custom retry attempts bounded, add jitter, and retry only documented transient errors. [2]

Keep product-specific quota advice separate

Firebase AI Logic documents RPM, RPD, TPM, and TPD quota dimensions, as well as a separate per-user quota for calls through its SDK. Those details are relevant if your application uses Firebase AI Logic, but they are not direct Gemini Developer API quota settings. [3]

Likewise, Gemini CLI’s daily request allowances and /stats model command are CLI-specific. They do not show the limits or usage of a separate production application calling the Gemini API. [4]

Sources

1. Rate limits — Gemini API
2. Billing — Gemini API; Troubleshooting guide — Gemini API
3. Rate limits and quotas — Firebase AI Logic
4. Quotas and pricing — Gemini CLI
5. Error code 429 — Gemini Enterprise Agent Platform
6. Using Gemini API keys
7. Google AI Developers Forum: Tier 1 rate limits

Sources

Rate limits | Gemini API | Google AI for Developers

Billing | Gemini API | Google AI for Developers

Troubleshooting guide | Gemini API | Google AI for Developers

Using Gemini API keys | Google AI for Developers

Tier 1 rate limits | Google AI Developers Forum

Rate limits and quotas | Firebase AI Logic

Gemini CLI: Quotas and pricing

Error code 429 | Gemini Enterprise Agent Platform