Resource has been exhausted (e.g. check quota)

Gemini API
,
1

Since Aug 4 we’ve seen a rising share of requests fail with HTTP 429 / RESOURCE_EXHAUSTED, and since Aug 6 ~19:00 UTC roughly half of all gemini-3.6-flash calls fail. All 3 retries fail immediately, so the user-facing request dies.

Response body (no quota details at all):

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

Response headers contain no Retry-After and no quota metric. server-timing: gfet4t7; dur=359 — the request is rejected in ~360 ms, which does not look like per-minute rate limiting.

Failure rate per day (UTC), measured as failed calls / total calls from our own telemetry:

Date gemini-3.6-flash gemini-3.1-flash-lite
Jul 31 0.3% 0%
Aug 3 0.4% 0%
Aug 4 2.0% 0%
Aug 5 3.2% 0.2%
Aug 6 18.0% 1.9%
Aug 7 50.4% 4.9%

Two things I’d like help separating:

  1. On Aug 6 at 18:13 UTC we deployed a change that sets serviceTier: "priority" on one of our call paths (the AI SDK sends it as the serviceTier field in the request body). The 429 rate on that path jumped from ~8% to ~48% within the hour. Is a 429 RESOURCE_EXHAUSTED the expected response when a project requests the priority service tier without provisioned priority capacity? If so, could the error message say that explicitly instead of the generic quota message?

  2. Independently of the priority tier, our standard-tier traffic also degraded: gemini-3.1-flash-lite went from 0% to ~5% 429s, and gemini-3.6-flash was already at 2-3% on Aug 4-5, before the priority change. That looks like a capacity issue on your side rather than our quota, since our request volume has been flat (~5-7k calls/day) and we’re well under our documented limits.

Questions:

  • Can you confirm whether these 429s are quota-based or capacity-based? The response carries no QuotaFailure details or RetryInfo, which makes it impossible to tell from the client side.
  • Is there a recommended backoff for RESOURCE_EXHAUSTED when no Retry-After is returned? Our 3 exponential retries all fail within the same second.
  • Is there any per-model capacity issue currently affecting gemini-3.6-flash?

Happy to provide project number, API key prefix and exact request IDs privately.

2

Update — I found the actual trigger on our side, and it’s much narrower than “quota exhausted”. It’s the file ingestion path, not the model.

Same file, same prompt, same model, same minute, one API key, 1 request/s. The only variable is how the file is delivered:

delivery result latency
fileData with a signed GCS URL 0/5 succeeded — all 429 RESOURCE_EXHAUSTED 10-15s before the error
inlineData with the same bytes in base64 5/5 succeeded 9-26s

The file is a 3.2 MB PDF. Two things worth highlighting:

  1. The 429 takes 10-15 seconds to come back. A rate limit rejects in milliseconds — we see exactly that on a different code path, where the rejection lands in ~400 ms. Ten seconds is the server fetching and processing the document and then refusing it. Whatever is exhausted, it’s downstream of the fetch, and it is not our RPM/TPM.

  2. A trivial request on the same key, in the same minute, is completely fine. {"contents":[{"parts":[{"text":"hi"}]}]} at 1 req/s: 20/20 HTTP 200. So the project is not out of quota in any sense the API is willing to describe.

This also explains why so many reports in this category look inconsistent: if your payload carries a fileUri the model never sees the request, and if it doesn’t, everything works. Two developers on the same tier will report opposite results depending only on whether they send files.

Which brings me to the part I want to complain about, because it turned a one-line fix into two days of work for us and, judging by this thread, for others too:- RESOURCE_EXHAUSTED is the wrong error. le fetch capacity, document parsing, ingestionbacklog — it is not the caller’s quota. The rese, no RetryInfo, no Retry-After. There isliterally nothing in the payload that distingui" from "our file pipeline can't take this right now", and those demand opposite responses from change how you send the file. - **The console actively misleads you.** Ours se as the 0.03% reported at the top of this thread. So the API says "resource exhausted" an is exhausted", and both are official Google surfaces. - **There is no status page where this could evogle.com has no component for generativelanguage.googleapis.com — the AI-rei Code Assist, Gemini Enterprise, Gemini on Agent Platform and the Vertex products. The Workspaceapp, not the API. So for the Gemini API there isno first-party surface that can say “degraded”,his endpoint is invisible to customers byconstruction. We only found it because we happe and could see a step change in our own errorrate.

Requests, in order of how much they’d help:

  1. Return a distinct status (or at minimum a dire` detail) when the failure is in file fetchingor ingestion rather than caller quota.
  2. Publish a status component for `generativela
  3. Confirm whether fileData ingestion is currhere’s a size or rate threshold above which itstarts refusing — we can reproduce this on demand and are happy to run any test that helps.

Our workaround, for anyone hitting the same wall: send the bytes inline instead of a URI. It costs a bigger request body, and above ~15 MB you have to use the Files API (basst the 20 MB request cap), but it bypasses the
fetcher entirely and our success rate went stra