**[In-Depth Investigation] Gemini 2.5 Pro/Flash Models Return Misleading 429 `ResourceExhausted` Error, Linked to Project-Level Permission Issues**

Gemini API
, , , ,
1

Hello everyone,

I am creating this comprehensive thread to report a persistent and misleading 429 ResourceExhausted error when calling the Gemini 2.5 Pro and Gemini 2.5 Flash models.

After extensive troubleshooting and cross-account testing, it is evident that this is not a standard rate-limiting issue. Instead, it appears to be a systemic problem tied to the underlying permissions and configuration of the Google Cloud Project from which the API key originates. Many users across the forums, using both new and established accounts, are reporting the exact same behavior.

This post aims to consolidate all findings, provide concrete evidence, and request clarification from the Google team.

1. The Core Problem: A Consistent and Specific Failure Pattern

Any user experiencing this issue observes the following, regardless of their account’s age or usage history:

  • Selective Model Failure:

    • FAIL: Calls to gemini-2.5-pro or gemini-2.5-flash immediately fail with a 429 error.
    • SUCCESS: Using the exact same API key, project, and codebase, switching the model to gemini-2.0-flash (or other older models) results in a perfectly successful API call.

  • Not Related to API Call Frequency:

    • The error occurs on the very first attempt to call the 2.5 models.
    • API metrics in the Google Cloud Console confirm that the request count for these models is minimal (often just 1-2 failed attempts), well below the documented free-tier RPM limits. This definitively rules out traditional rate limiting as the cause.

2. The Decisive Evidence: Replicating the Issue

The root cause becomes clear through two key diagnostic steps:

A. Cross-Project / Cross-Account Verification

The issue is strongly correlated with the specific Google Cloud project/account.

  • “Healthy” Project: An API Key from one of my Google Cloud projects can access all models, including the 2.5 series, without any issues.
  • “Affected” Project: An API Key from a different project consistently reproduces the failure pattern: 2.0 models work, 2.5 models fail with a 429. This has been observed with both new and old accounts.

This proves the issue is not with the client-side code but is intrinsically linked to the server-side state of the project that owns the API key.

B. The “Smoking Gun”: Fundamental Permission Error in AI Studio

This is the most critical piece of evidence. When logged into the Google AI Studio with the account associated with the “Affected” Project, a fundamental operation fails:

Attempting to create a new project directly within AI Studio results in the error:

Failed to create project: permission denied. Please try again.

This core permission failure within AI Studio is the common denominator reported by multiple users who also experience the 429 API error. It indicates a foundational problem with the account’s ability to provision resources on Google Cloud Platform, which likely prevents it from being correctly provisioned for new model access.

3. Conclusion & Hypothesis

Conclusion: The 429 ResourceExhausted error code, in this context, is highly misleading. It is masking a deeper, unresolved permission or provisioning failure.

Hypothesis:
A Google Cloud Project can enter a state where its core permissions are impaired (evidenced by the inability to create projects in AI Studio). This state may be triggered by various factors (e.g., new account sandboxing, incomplete billing setup, a silent backend provisioning failure).

This impaired permission state prevents the project from being granted access entitlements to the newer Gemini 2.5 series models. When an API key from this project attempts to call these unauthorized models, the API gateway returns a generic 429 “quota” error instead of a more accurate 403 Permission Denied error.

4. Request to the Google Team & Community

  1. Request for Acknowledgment: Can the Google team confirm if this is a known issue where projects with underlying permission failures are incorrectly returning 429 errors for new models?
  2. Request for Improved Error Handling: We strongly request that the API return a more accurate error message for this scenario. A 403 Permission Denied with a message like “This project is not authorized to use the requested model” would save developers countless hours of troubleshooting.
  3. Request for a Solution: For users whose projects are in this “affected” state, what are the official steps to resolve the underlying permission issue? Is there a specific support channel or diagnostic procedure we should follow?

Thank you for your time and attention to this detailed report. We hope that by consolidating our findings, we can help facilitate a swift resolution.

Best regards.