Gemini-embedding-001 returns 429 despite AI Studio showing 76 / 20K RPM

We are experiencing sustained 429 Too Many Requests responses from the Gemini Developer API embedding endpoint in a production workload.

This is an AI Studio / Gemini Developer API key integration. We call generativelanguage.googleapis.com directly; this is not a Vertex AI integration.

Endpoint:
POST generativelanguage.googleapis.com/v1beta/models/gemini-embedding-001:batchEmbedContents

Model:
gemini-embedding-001

First observed:
2026-09-01 around 05:00 UTC

Impact:
A meaningful share of embedding requests fail after Gemini returns 429 on all retry attempts.

Observed volume:

  • In the affected window, approximately 4,900 embedding-backed requests were made.
  • Approximately 1,200 ultimately failed after Gemini returned 429 across three attempts: about 25% user-visible failure rate.
  • During the peak six-hour period, about 29% of requests failed.
  • The equivalent window on the preceding day had no corresponding failures.

AI Studio rate-limit dashboard at the time of the incident:

  • Gemini Embedding 1 RPM: 76 / 20,000
  • TPM: 230 / 20,000,000
  • RPD: 5.07K / Unlimited

The failing request can contain a single short string in a batch of one. This does not appear to be a large-batch or high-token-volume issue.

Could someone from Google clarify:

  1. Is there a known quota-routing, metering, or capacity incident that began on 2026-09-01?
  2. What is the effective RPM, TPM, or regional/global quota for gemini-embedding-001 in this situation?
  3. Which quota metric is enforcing these 429 responses?

This appears similar to these reports:

https://discuss.ai.google.dev/t/gemini-api-embedding-rejected-by-an-aiplatform-googleapis-com-quota-tier-3-project-at-5-of-its-limit/180424

https://discuss.ai.google.dev/t/gemini-embedding-2-returning-429-resource-exhausted-citing-vertex-quota-despite-near-zero-usage-ai-studio-tier-2/169814

Another independent report from the same day shows the same model, visible 20,000 RPM limit, low measured usage, and the exact hidden quota metric:

This further suggests a Gemini embedding quota-routing or backend-enforcement issue rather than normal exhaustion of the visible AI Studio quota.

We can provide project details, exact UTC timestamps, AI Studio screenshots, and redacted raw 429 response details through a private channel if needed.

Hey! This was an intermitted issue, should now be working fine.

:plus: have been fighting this the entire day.

Thanks Aakash, the issue has indeed stopped.

Could you explain what happened and whether this was a known incident? Also, how should we handle this type of failure in the future? As noted in the related posts, similar issues appear to affect other users intermittently.

We chose Tier 3 partly to support our high-availability requirements. If Gemini embedding requests can be rejected despite remaining far below the displayed quota, we need to understand the expected reliability model and the recommended mitigation. Otherwise, we may need to evaluate alternative providers for this dependency.

Thanks.

For workloads requiring high-availability, you should implement exponential backoff with jitter to absorb 429 and 503 errors.

Aakash_Bansal:

For workloads requiring high availability, you should implement exponential backoff with jitter to absorb 429 and 503 errors.

I already have this behavior in place (exponential backoff + full jitter), and I still got 429s for almost 30% of my requests.

More importantly, we were well below the rate limits in general, so why did the API return 429s in the first place? Asking me to add more waiting time between retries hurts my performance, while I wasn’t doing anything wrong or even getting close to the rate limits shown in the Google AI Studio dashboard.

As far as I understand from the last 24 hours, Google simply doesn’t guarantee that it won’t return 429 errors even when the request rate on my side remains unchanged and well below the documented limits.

That’s a pretty significant downside of using this API, at least for my company’s use case—which seems like a pretty normal use case to me.

Dear community and support, still hitting this today, 4 Sept.

Project pipelines-491211, paid Tier 1, Gemini Embedding 2 (not -001), AI Studio key. Dashboard shows peak 1.4K / 3K RPM and 18.6K / 1M TPM while errors run near continuous 429s across the same window, not even half way there and its just 429.

Error cites an aiplatform.googleapis.com quota, same as above. Was a root cause ever found? Different model and different tier here, so it doesn’t look confined to gemini-embedding-001 on Tier 3.

Same problem here, still ongoing. Adding hard numbers measured from Cloud Monitoring rather than application logs.

Two projects, 93844482.. and 38387432.., both paid Tier 1, both AI Studio keys calling generativelanguage.googleapis.com. Model gemini-embedding-2, EmbedContent.

Only the embedding endpoint is refused. 30 days to 2026-09-06, one project, one API key throughout:

GenerateContent                    34,302 requests   0x 429
CreateFile / GetFile / DeleteFile  28,652 requests   0x 429
EmbedContent                       35,168 ok         3,373x 429

Near-identical call volume between GenerateContent and EmbedContent on the same credential over the same month. One has never been refused once.

Last 24 hours, to 2026-09-06 18:50 UTC:

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

We are far under every quota that applies. Busiest single minute in 28 days: 160 requests, against a Tier 1 limit of 3,000/min. That is 5.3%. The aiplatform metric named in these errors resolves on our projects to 6,000/min for gemini-embedding-2, so we are 2.7% of that one. Under both.

It does not track request rate in any direction. 294 of 556 active minutes contained a 429. The smallest per-minute total that still received a 429 was one request. Minutes containing 75+ requests completed with zero refusals.

It has a start date. No 429s of any kind across the whole 30-day window until 2026-08-27 — a single refusal, then isolated singles through 08-29, then sustained from 09-03 and worsening since. Our request pattern, rate, model, SDK and client did not change.

The error points at a Vertex AI doc for a call that never touches Vertex AI:

{ "error": { "code": 429, "message": "Resource exhausted. Please try again later.
Please refer to https://cloud.google.com/vertex-ai/generative-ai/docs/error-code-429
for more detail..." } }

aiplatform.googleapis.com is DISABLED on 938444820.. and ENABLED on 383874328… Both are refused, at 66% and 43%. So enabling that service is not the fix.

@Aakash_Bansal — on the backoff suggestion, we already run retry ladders on both call paths plus failover between two projects’ keys. Both keys get refused within seconds of each other: in the worst hour, 109 of 113 failover attempts were also refused. We tested batching in case that was the answer — equal request counts through :batchEmbedContents and :embedContent against the same key, interleaved so both met the same minutes — and the batch endpoint was refused more often per request, 20% vs 5%. Backoff absorbs some of this. It does not address being refused at under 3% of a documented limit.

This was marked “an intermittent issue, should now be working fine” on 2 Sept. It was not — it worsened from 3 Sept and is ongoing today, 6 Sept.

Which quota metric is actually enforcing these 429s? The one named in the error resolves to a limit we are 40x under.

having a lot of issues with gemini embedding 2, despite being nowhere near the limits

Gemini Embedding 2, Tier 1

Our production usage of Gemini Embedding 2 is suffering over the past few days from 429s. We retry via exponential backoff and even fallback between vertex and gemini global endpoints, and yet we have requests that falls through and fully error out due to recent capacity (I’m assuming) issues. This is really unacceptable reliability from Google, as an org that’s trying to draw more AI mindshare. If this continues for much longer we have no choice but to migrate away, however painful it might be. Really hoping some Googlers are paying attention here.

Our account was auto-upgraded to Tier 2 but that had zero impact on 429 Service Unavailable volume. Our volume still pretty low, way way under any rate limits. Can someone from Google clarify what is happening? This is impacting our production and there seems to be no way to fix this.

@Aakash_Bansal Using different api keys (round robin) should help handling these outages?

Any updates? We still having same issues.