Gemini Flash + Google Search grounding returning 429 even on the Global endpoint

A Reddit thread in r/googlecloud lays out a specific, reproducible-sounding problem: an enrichment pipeline on Vertex AI, calling Gemini 2.5 Flash with Google Search grounding enabled, gets intermittent 429 RESOURCE_EXHAUSTED errors — and switching the endpoint from us-central1 to global did not make them go away. The setup, in the reporter's own words: MAX_CONCURRENCY = 5, VERTEX_MAX_IN_FLIGHT = 5, single prompt variant, pay-as-you-go billing (not Provisioned Throughput), each job fanning out into roughly 10 independent grounded calls at 20-30 seconds each. Concurrency low, still 429s.

Worth saying up front: this thread is unresolved. Four other people replied "same issue" over the following weeks, and nobody — including the OP — posted a confirmed fix. If you landed here looking for a definitive answer, this post will not give you one; what it gives you is the actual questions worth asking your own pipeline, sourced from people hitting the same wall.

The most substantive reply came from another Vertex AI user (OccasionWorried7280), who reported the same symptom in their own pipeline and offered one concrete distinction: "the 429s were almost always project-level RPM quota, not regional capacity — the global endpoint helps with routing but it doesn't bypass your project's own limits." That is the one piece of signal in the whole thread worth taking seriously — the Global endpoint changes *where* your request gets routed for capacity, it does not raise your project's own requests-per-minute or tokens-per-minute ceiling. If your pipeline is 429ing at low concurrency, the Global endpoint switch (which several threads and docs suggest as a first fix) may simply not be addressing the actual bottleneck.

The OP followed up asking the practical next question — which specific quota metric is being exhausted: requests per minute, tokens per minute, or Dynamic Shared Quota (DSQ, the shared-capacity pool Vertex draws grounded/thinking model calls from before you provision dedicated throughput). Nobody in the thread had a confirmed answer, and two more people (domlebo70, Slov1ker) piled on weeks apart with "we have the same issue" and "is this resolved, I am getting the same issue right now." As of this writing, it still is not resolved in the thread.

This site is about gemini-3.5-flash specifically, and the reported thread is running gemini-2.5-flash. We are not claiming this is a 3.5-specific bug — we do not have a 3.5 report to point to yet. What makes it relevant here anyway: Google Search grounding and Dynamic Shared Quota are infrastructure shared across the Gemini Flash line, not something reimplemented per model version, so a project-level RPM/TPM or DSQ constraint that bites 2.5 Flash grounded calls is a plausible failure mode for 3.5 Flash grounded calls too — especially since 3.5's thinking_level config (see /thinking-level) changes how many tokens each call burns, which is one of the two quota dimensions (TPM) directly in play here. If you are on 3.5 Flash with grounding and hitting the same error, the diagnostic steps below still apply; just do not assume this specific thread confirms a 3.5 bug.

In order, cheapest to most expensive:

1. Confirm it is really a quota 429, not something else with the same status code. Log the full error body, not just the HTTP status — RESOURCE_EXHAUSTED with a quota-metric string in the details is a different problem than a generic rate-limit 429 from a proxy or load balancer in front of your own service.

2. Check your project's actual RPM/TPM quota values in Cloud Console under APIs & Services → Quotas, filtered to the Vertex AI Gemini API, before assuming you are hitting shared/DSQ capacity. domlebo70's question in the thread — "to up the quota, do I find it in APIs & services like other quotas?" — is the right instinct; if your project-level quota is genuinely low relative to your fan-out (10 concurrent grounded calls per job, in the OP's case), that is a request-a-quota-increase problem, not a code problem.

3. If project quota looks fine, the remaining suspect is DSQ — the shared capacity pool pay-as-you-go traffic draws from before you have Provisioned Throughput. This is architecturally more likely to produce *intermittent* 429s that do not correlate cleanly with your own concurrency settings, which matches what both the OP and OccasionWorried7280 described.

4. Add real backoff-and-retry around grounded calls specifically (separate from your non-grounded Gemini calls, since grounding calls run longer — the OP notes 20-30 seconds each — and are more likely to land during a capacity crunch). Exponential backoff with jitter on RESOURCE_EXHAUSTED is the standard mitigation while you wait on a quota increase or investigate further.

5. If 429s persist after confirming project quota is not the bottleneck, Provisioned Throughput is the actual structural fix — it reserves dedicated capacity instead of drawing from the shared DSQ pool. It is also the one variable the thread never got an answer on ("did Provisioned Throughput significantly reduce or eliminate these errors?") — if you have tried it, that is a genuinely open question worth testing and reporting back on.

Everything else on this site is about silent quality regressions — a call that succeeds but produces a worse answer because a config default changed underneath you (see /migrate, /parameters). A 429 is the opposite failure mode: loud, not silent, but just as poorly documented in terms of root cause. If your grounded Gemini Flash pipeline is failing intermittently and you have already ruled out the obvious (bad API key, wrong endpoint, malformed request), the project-quota-vs-DSQ distinction from this thread is the most concrete lead available right now — check the boring thing (your own project's RPM/TPM quota) before assuming you have found a platform-level capacity bug.