[429] RESOURCE_EXHAUSTED on Paid Tier 1 even though limits are not hit, and it is affecting another project under the same billing account

Gemini API
, , , ,
1

Hi team,

We are seeing repeated 429 RESOURCE_EXHAUSTED errors on Gemini API even though our project is on Paid Tier 1 and the rate limit dashboard does not show that we are hitting RPM / TPM / RPD limits.

This does not look like a simple quota-overuse case.

image
image1288×733 88.4 KB

Error returned by the API:

{
  "error": {
    "code": 429,
    "message": "Resource has been exhausted (e.g. check quota).",
    "status": "RESOURCE_EXHAUSTED"
  }
}

What makes this more concerning is that this is not isolated to one project.

We have also observed the same or very similar issue on another project under the same paid billing account, using a different API key. So this seems larger than a single key problem, and possibly larger than a single project-level quota issue.

What we have checked so far:

  • The affected project is on Paid Tier 1
  • Billing is active and linked
  • The Gemini API rate limit page shows usage well below the published limits
  • We tested with different API keys
  • We tested from another project under the same billing account
  • Small / isolated requests may sometimes return 200, but real application traffic still starts returning 429
  • The issue is recurring and not just a short temporary spike

From the outside, this looks like one of the following:

  1. quota / entitlement attribution is incorrect for the project
  2. the project is being treated as if it were on a lower tier
  3. there is a backend capacity issue being surfaced as 429 RESOURCE_EXHAUSTED
  4. there may be a billing-account-level or cross-project issue, because another project under the same paid billing account is also affected

According to the official Gemini API documentation, rate limits are applied per project, not per API key, which is why the cross-project symptom is especially confusing in our case:

Could someone please investigate whether there is an issue with quota assignment, tier recognition, or backend capacity for these projects?

If needed, I can provide the following by DM:

  • Project Number for project A
  • Project Number for project B

This issue is impacting more than one project for us, so it is affecting development/testing beyond a single application.

Thanks.

2

Hello @iring,
Can you DM your project numbers (not the Project ID) and models you are using . To send a direct message, click on my profile picture or name, and select the Message button.

3

I have the same issue. Though I have a single project and a single api key on my account.

4

I can’t see any Message button :frowning:

image
image791×323 33.1 KB

5

Check your DMs ~
Thanks

6

Hey Iring,

Sorry to ask one more thing of you. Please add your details to this form & we’ll check it out.

7

Hi Jon,

Thanks for the note. I’ve just submitted the form with my details. Let me know if you need anything else!

8

Still happening five months later, and I can narrow it: for us this is specific
to gemini-embedding-2 / EmbedContent, and nothing else on the same credential.

We run https//agentsofai… , a marketplace for AI-generated stock images and video. Creators upload their work, we analyse and index it, buyers search and license it. We launched three weeks ago and already hold 20K published assets .

The Gemini API is not a feature of this product, it is the spine of it. Two calls per asset, one call per search:

  1. Ingest analysis — one gemini-flash-lite call per asset that writes the title
    when the creator left it blank, writes the description, and returns the
    content-safety bands we moderate on.
  2. Ingest embedding — one gemini-embedding-2 EmbedContent call per asset (image or video), 1536 dimensions, taken from the actual pixels: the image itself, or for video
    the whole clip via a 720p proxy we build in the browser specifically so the model sees motion rather than a single poster frame.
  3. Search — one gemini-embedding-2 EmbedContent call per customer query, then a
    cross-modal vector walk from that text embedding against the stored pixel embeddings.

There is no keyword index behind this. No full-text search, no BM25, no fallback ranking. We chose a single multilingual cross-modal rail deliberately and built the catalogue around it. So an embedding call is not an enrichment step that can fail quietly — it is the difference between an asset existing and not existing as far as a buyer is concerned.

Concretely, when EmbedContent is refused:

  • a customer’s search returns an error page, because we have nothing to rank with;
  • a newly published asset appears on the site, in feeds and on its own page, but is absent from every search result until a background repair job manages to embed it later.

Query embeddings are cached for 30 days. Both call paths carry retry ladders (1/3/5 seconds on ingest, 1 second on search) and a failover between two keys. We identified and blocked a third-party AI crawlers that was running our own asset titles back through our search box and generating tens of thousands of unnecessary embeds, and we have since put a bot challenge in front of the search page entirely. All of that reduced our call volume. None of it changed the refusal rate.

Here’s the numbers:

Projects: 93844482048.. (customer search queries) and 38387432819.. (ingest
pipeline), both on billing account 019360-37E68D-296F.., paid Tier 1.
Model: gemini-embedding-2. Method: EmbedContent.

Measured over the 24 hours to 2026-09-06 18:50 UTC from Cloud Monitoring
(serviceruntime.googleapis.com/api/request_count), not from application logs:

93844482048.. EmbedContent 200: 313 429: 603 66% refused
38387432819.. EmbedContent 200: 3,450 429: 2,582 503: 26 43% refused

Busiest single minute across both projects: 154 requests, against a Tier 1 limit of 3,000 per minute per project per model. We peak at roughly 5% of our limit and are refused two thirds of the time on the search project.

The refusals do not track request rate at all. 294 of 556 active minutes contained at least one 429. The smallest per-minute total that still received a 429 was one request. Minutes containing 75 or more requests completed with zero refusals.

Same 24 hours, same API key, same project, same billing account:

GenerateContent 4,058 requests, 0 non-200
CreateFile / GetFile / DeleteFile 2,403 requests, 0 non-200
EmbedContent 3,450 ok, 2,582 refused

Only EmbedContent is refused. Every other method on the identical credential is
clean. That rules out the account, the key and the project as the variable, at
least for us. It also means our ingest analysis call succeeds and our ingest
embedding call fails for the very same asset, seconds apart, on the same key.

The error body is the capacity message (“Resource exhausted. Please try again
later.”) rather than the quota message (“You exceeded your current quota”).

Has anyone had a resolution beyond the report form? I am happy to provide request IDs, exact timestamps, or read-only monitoring access to anyone at Google looking at this — we already run a service account with Monitoring Viewer across both projects and can reproduce every figure above on demand.

Thank you!