# 429 RESOURCE\_EXHAUSTED at 0.03% of quota — reproducible across projects, tiers and endpoints

**URL:** <https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317>\
**Category:** Gemini API\
**Tags:** rate-limits\
**Created:** [August 6, 2026, 7:47am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317 "2026-08-06T07:47:47Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Petr\_Hlavka](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/petr_hlavka/32/141045_2.png) [@Petr\_Hlavka](https://discuss.ai.google.dev/u/Petr_Hlavka)\
**Post date:** [August 6, 2026, 7:47am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/1 "2026-08-06T07:47:47Z")

</div>

**Model:** `gemini-3.1-flash-lite` **Observed:** August 5–6, 2026 (CEST) **Region:** Czech Republic

Summary

Roughly 40% of my requests fail with `429 RESOURCE_EXHAUSTED` while the Cloud Console reports my quota usage at 0.03%. I have ruled out every client-side cause I can think of, including creating a brand new project on a different tier. I would appreciate any pointer as to what resource is actually being exhausted.

A secondary issue: the OpenAI-compatibility endpoint reports this same condition as `400 INVALID_ARGUMENT`, which sent me looking for a malformed request for two days.

## Reproduction

Minimal request, native endpoint, no SDK:

curl -X POST  
“[https://generativelanguage.googleapis.com/v1beta/models/gemini-3.1-flash-lite:generateContent](https://generativelanguage.googleapis.com/v1beta/models/gemini-3.1-flash-lite:generateContent)”  
-H “x-goog-api-key: $KEY”  
-H “Content-Type: application/json”  
-d ‘{“contents”:[{“parts”:[  
{“fileData”:{“fileUri”:“[https://bb0536d6afeb6d2c8a69b249107861bf.cdn.bubble.io/f1785960536931x858895192810575800/UcTest\_04A.jpeg",“mimeType”:"image/jpeg](https://bb0536d6afeb6d2c8a69b249107861bf.cdn.bubble.io/f1785960536931x858895192810575800/UcTest_04A.jpeg%22,%22mimeType%22:%22image/jpeg)”}},  
{“text”:“Describe this image in one sentence.”}  
]}]}’

Run five times with 30-second gaps between calls:

attempt 1: 200  
attempt 2: 429  
attempt 3: 200  
attempt 4: 200  
attempt 5: 429

Successful responses are correct and complete. Failures return:

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

What I ruled out

**Quota.** Cloud Console → Quotas, filtered to Gemini API, shows “Current usage \> 90%: 0” across all 1,858 quotas. Request limit per model per minute: 1.25 of 4,000 (0.03%). Input token count limit per minute: 858 of 4,000,000 (0.02%). No quota is anywhere near its ceiling.

**Rate limiting.** AI Studio Rate Limit page: 3/4K RPM, 8.9K/4M TPM, 66/150K RPD. Adding 30-second gaps between calls improved the failure rate from ~40% to ~20% but did not eliminate it — and the very first call after a multi-minute idle period has failed on several occasions.

**Billing.** Tier 1, active billing account, positive prepay balance (paid by card, ~2% consumed). No warnings on the billing page.

**Project and key.** I created a new project with a new API key on the Free Tier. Same behaviour, same rate: 3 failures out of 5 calls.

**Endpoint.** Both `/v1beta/models/...:generateContent` and `/v1beta/openai/chat/completions` fail at comparable rates.

**Payload.** Fails identically with a 5,085-token prompt and with an 8-token ASCII prompt. Image is 1,064 tokens either way and is publicly reachable — successful calls fetch and read it correctly. `maxOutputTokens` raised from 1,500 to 5,000 with no effect.

**Client.** Reproduces from both a server-side HTTP client and plain curl on a local machine, in the same minutes.

## Secondary issue: error code mistranslation

Through `/v1beta/openai/chat/completions` this same condition surfaces as:

{“error”:{“code”:400,“message”:“Request contains an invalid argument.”,“status”:“INVALID\_ARGUMENT”}}

A 400 tells the caller their request is malformed, so I spent two days auditing my request body, prompt encoding, image URL and token limits — none of which were the problem. The native endpoint returned 429 on the first try and immediately pointed in the right direction. If the compatibility layer passed the underlying status through, this would have been a ten-minute diagnosis.

I also saw one response with an empty `content: {}` and `totalTokenCount == promptTokenCount`, i.e. a 200 with no output tokens generated. That may be the same condition surfacing a third way.

Context

AI Studio Usage shows both `400 BadRequest` and `429 TooManyRequests` bars over the affected period, alongside some `503 ServiceUnavailable`. The status page at he official status page has reported “All Systems Operational” throughout. Third-party monitoring picked up user reports of sustained 503s across several Flash models over the same window, so I do not believe this is specific to my account.

The Cloud Billing console currently displays a banner about cost data delays affecting multiple GCP services since August 1, 2026. I mention it only in case the billing pipeline and the quota enforcement path share state — I have no evidence either way.

Question

Which resource is being reported as exhausted when every visible quota sits below 0.1%? Is there a limit dimension not surfaced in Cloud Console quotas or the AI Studio rate limit page — concurrency, per-region capacity, or vision-specific throughput?

If this is capacity-related rather than quota-related, a `503` would let callers apply the right retry strategy. A `429` implies backing off will help; in my measurements the failures arrive in clusters of up to nine consecutive calls, so it largely does not.

Happy to provide request IDs, timestamps or project numbers.

---

<div class="post-metadata">

**Author:** ![Auntie](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/auntie/32/31602_2.png) [@Auntie](https://discuss.ai.google.dev/u/Auntie)\
**Post date:** [August 6, 2026, 7:56am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/2 "2026-08-06T07:56:49Z")

</div>

Not a developer here but it feels and sounds like what I’m experiencing. Thank you for putting it into terms I could not relay.

---

<div class="post-metadata">

**Author:** ![Petr\_Hlavka](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/petr_hlavka/32/141045_2.png) [@Petr\_Hlavka](https://discuss.ai.google.dev/u/Petr_Hlavka)\
**Post date:** [August 6, 2026, 8:53am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/3 "2026-08-06T08:53:21Z")

</div>

Since when are you experiencing that?

---

<div class="post-metadata">

**Author:** ![Auntie](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/auntie/32/31602_2.png) [@Auntie](https://discuss.ai.google.dev/u/Auntie)\
**Post date:** [August 6, 2026, 9:14am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/4 "2026-08-06T09:14:13Z")

</div>

two days ago i reported it as lag… double charging prompts. then yesterday i didnt do much and this morning it wasted 17 RPD for 1 prompt

---

<div class="post-metadata">

**Author:** ![Sai\_Deepika\_K](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/sai_deepika_k/32/34803_2.png) [@Sai\_Deepika\_K](https://discuss.ai.google.dev/u/Sai_Deepika_K)\
**Post date:** [August 7, 2026, 4:02am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/5 "2026-08-07T04:02:43Z")

</div>

Hello @Petr_Hlavka ,

If you’re receiving 429’s and have checked no [rate limit](https://aistudio.google.com/rate-limit) was breached for the period, please add your details to [this form](https://docs.google.com/forms/d/e/1FAIpQLScIHhj38oNf5an12JSu2SK4bQY9V6HrOc6g76LC0wKM13WiXw/viewform?usp=header) & we’ll check it out.

---

<div class="post-metadata">

**Author:** ![Petr\_Hlavka](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/petr_hlavka/32/141045_2.png) [@Petr\_Hlavka](https://discuss.ai.google.dev/u/Petr_Hlavka)\
**Post date:** [August 7, 2026, 6:00am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/6 "2026-08-07T06:00:39Z")

</div>

Hello, I already did that. All the details are in this post and in the related form.  
Thank you.

---

<div class="post-metadata">

**Author:** ![joao\_licitei](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/joao_licitei/32/133072_2.png) [@joao\_licitei](https://discuss.ai.google.dev/u/joao_licitei)\
**Post date:** [August 7, 2026, 12:24pm UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/7 "2026-08-07T12:24:29Z")

</div>

Corroborating this from a different project, same window — paid tier, native `generativelanguage` REST endpoint (streaming, `?alt=sse`), Vercel AI SDK on Node 24, requests originating from us-east.

Same shape as yours: `429 RESOURCE_EXHAUSTED` with a bare body — no `QuotaFailure` details, no `RetryInfo`, and no `Retry-After` header:

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

The responses come back in ~360 ms (`server-timing: gfet4t7; dur=359`), which doesn’t look like per-minute rate limiting — it reads like a capacity rejection. Our 3 exponential retries all fail inside the same second, so the whole user-facing request dies.

Failure rate from our own telemetry (failed calls / total calls per day, UTC), ~5-7k calls/day, volume flat across the whole period:

| Date | gemini-3.6-flash | gemini-3.1-flash-lite |
| --- | --- | --- |
| Jul 30 | 0.2% | 0.2% |
| Jul 31 | 0.3% | 0% |
| Aug 3 | 0.4% | 0 |
| Aug 4 | 2.0% | 0 |
| Aug 5 | 3.2% | 0 |
| Aug 6 | 5.9% | 1 |
| Aug 7 | — | 4 |

Two notes on the table so it isn’t misread: the Aug 6 figure covers 00:00–18:00 UTC only, and I left Aug 7 blank for `gemini-3.6-flash`, because at 18:13 UTC on Aug 6 we deployed a  
change on our side affecting thg shown above is untouched  
standard-tier traffic, and `gem touched at all — that column is  
clean end to end.

So this doesn’t look specific t see the same climb on`gemini-3.6-flash`, starting Aug 4, roughly an order of magnitude above our baseline of 0.2-0.4%.  
Questions that would unblock us- Are these quota-based or capalure`or`RetryInfo` in thepayload, there’s no way to tellud console shows us nowhere nearour limits either.

- What backoff is recommended fno `Retry-After` is returned?
- Is there any status surface where this would show up? `status.cloud.google.com` has no component for `generativelanguage.googleapis.com`, so a degradation here appears to be invisible to customers by design.

Happy to share project number ahat helps narrow it down.

---

<div class="post-metadata">

**Author:** ![kk\_oo1](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/kk_oo1/32/141382_2.png) [@kk\_oo1](https://discuss.ai.google.dev/u/kk_oo1)\
**Post date:** [August 10, 2026, 4:16am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/8 "2026-08-10T04:16:12Z")

</div>

I am seeing what appears to be the same issue in my environment, and I was able to reduce it to a very small reproducible request.

I am using:

Model: gemini-3.5-flash-lite  
Tier: Tier 1  
API: Gemini API generateContent  
Endpoint: [https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash-lite:generateContent](https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash-lite:generateContent)

The Rate Limit page in AI Studio shows that the project is nowhere near its RPM, TPM, or RPD limits. The displayed usage is approximately:

RPM: 2 / 4,000  
TPM: 7.82K / 4M  
RPD: 12 / 150K

To isolate the problem, I created a minimal test separate from my production application.

1. Text-only request

Using the same API key, project, and model, this request succeeds:

{  
“contents”: [  
{  
“role”: “user”,  
“parts”: [  
{  
“text”: “Reply with OK only.”  
}  
]  
}  
]  
}

The response is HTTP 200:

HTTP status: 200  
text: OK  
promptTokenCount: 6  
candidatesTokenCount: 1  
totalTokenCount: 7  
serviceTier: standard

1. The same request with one public JPEG URL added

I then added only one fileData.fileUri part:

{  
“contents”: [  
{  
“role”: “user”,  
“parts”: [  
{  
“text”: “Reply with OK only.”  
},  
{  
“fileData”: {  
“fileUri”: “https//auctions.c.yimg.jp/images.auctions.yahoo.co.jp/image/dr000/auc0204/user/63a6718d196de03959df5f20f652789057e66a64b65849ac1c61b2c80adfd907/i-img800x1199-17774338629983njxg7z178522.jpg”,  
“mimeType”: “image/jpeg”  
}  
}  
]  
}  
]  
}

This image is publicly accessible over HTTPS and does not require authentication, cookies, or a login. It can also be opened directly in a private/incognito browser session.

With this single image added, the API returns HTTP 429:

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

There is no QuotaFailure, quota metric, quota limit, RetryInfo, or retry delay in the response.

So the minimal reproduction is:

Text only  
→ HTTP 200

Exactly the same request + one public JPEG via fileData.fileUri  
→ HTTP 429 RESOURCE\_EXHAUSTED

In my actual application, I normally send three public image URLs using fileData.fileUri, and the same 429 RESOURCE\_EXHAUSTED occurs there as well.

I initially suspected the larger prompt, multiple images, JSON schema, or normal RPM/TPM/RPD rate limits. However, the minimal test above shows that even adding a single public JPEG URL to a tiny six-token text request is sufficient to trigger the error.

I have also reproduced an image-related 429 using another Google account/project, so this does not appear to be limited to a single API key or project.

The problem has also persisted after waiting and retrying on different days, so it does not appear to be a short-lived RPM/TPM rate-limit event.

Based on this reproduction, I suspect the issue may be related to the external file ingestion/fetch path used by fileData.fileUri, rather than the normal user-visible RPM/TPM/RPD quotas.

I will also submit the unexpected-429 reporting form referenced by Google staff, including the affected Project Number and screenshots of the AI Studio Rate Limit page.

Please let me know if any additional request/response details or timestamps would be useful for investigation.

---

<div class="post-metadata">

**Author:** ![Petr\_Hlavka](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/petr_hlavka/32/141045_2.png) [@Petr\_Hlavka](https://discuss.ai.google.dev/u/Petr_Hlavka)\
**Post date:** [August 10, 2026, 10:23am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/9 "2026-08-10T10:23:54Z")

</div>

> [@kk\_oo1](#):
>
> I am seeing what appears to be the same issue in my environment, and I was able to reduce it to a very small reproducible request.
> 
> I am using:
> 
> Model: gemini-3.5-flash-lite  
> Tier: Tier 1  
> API: Gemini API generateContent  
> Endpoint: [https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash-lite:generateContent](https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash-lite:generateContent)
> 
> The Rate Limit page in AI Studio shows that the project is nowhere near its RPM, TPM, or RPD limits. The displayed usage is approximately:
> 
> RPM: 2 / 4,000  
> TPM: 7.82K / 4M  
> RPD: 12 / 150K
> 
> To isolate the problem, I created a minimal test separate from my production application.
> 
> 1. Text-only request
> 
> Using the same API key, project, and model, this request succeeds:
> 
> {  
> “contents”: [  
> {  
> “role”: “user”,  
> “parts”: [  
> {  
> “text”: “Reply with OK only.”  
> }  
> ]  
> }  
> ]  
> }
> 
> The response is HTTP 200:
> 
> HTTP status: 200  
> text: OK  
> promptTokenCount: 6  
> candidatesTokenCount: 1  
> totalTokenCount: 7  
> serviceTier: standard
> 
> 1. The same request with one public JPEG URL added
> 
> I then added only one fileData.fileUri part:
> 
> {  
> “contents”: [  
> {  
> “role”: “user”,  
> “parts”: [  
> {  
> “text”: “Reply with OK only.”  
> },  
> {  
> “fileData”: {  
> “fileUri”: “[https://auctions.c.yimg.jp/images.auctions.yahoo.co.jp/image/dr000/auc0204/user/63a6718d196de03959df5f20f652789057e66a64b65849ac1c61b2c80adfd907/i-img800x1199-17774338629983njxg7z178522.jpg”](https://auctions.c.yimg.jp/images.auctions.yahoo.co.jp/image/dr000/auc0204/user/63a6718d196de03959df5f20f652789057e66a64b65849ac1c61b2c80adfd907/i-img800x1199-17774338629983njxg7z178522.jpg%E2%80%9D),  
> “mimeType”: “image/jpeg”  
> }  
> }  
> ]  
> }  
> ]  
> }
> 
> This image is publicly accessible over HTTPS and does not require authentication, cookies, or a login. It can also be opened directly in a private/incognito browser session.
> 
> With this single image added, the API returns HTTP 429:
> 
> {  
> “error”: {  
> “code”: 429,  
> “message”: “Resource has been exhausted (e.g. check quota).”,  
> “status”: “RESOURCE\_EXHAUSTED”  
> }  
> }
> 
> There is no QuotaFailure, quota metric, quota limit, RetryInfo, or retry delay in the response.
> 
> So the minimal reproduction is:
> 
> Text only  
> → HTTP 200
> 
> Exactly the same request + one public JPEG via fileData.fileUri  
> → HTTP 429 RESOURCE\_EXHAUSTED
> 
> In my actual application, I normally send three public image URLs using fileData.fileUri, and the same 429 RESOURCE\_EXHAUSTED occurs there as well.
> 
> I initially suspected the larger prompt, multiple images, JSON schema, or normal RPM/TPM/RPD rate limits. However, the minimal test above shows that even adding a single public JPEG URL to a tiny six-token text request is sufficient to trigger the error.
> 
> I have also reproduced an image-related 429 using another Google account/project, so this does not appear to be limited to a single API key or project.
> 
> The problem has also persisted after waiting and retrying on different days, so it does not appear to be a short-lived RPM/TPM rate-limit event.
> 
> Based on this reproduction, I suspect the issue may be related to the external file ingestion/fetch path used by fileData.fileUri, rather than the normal user-visible RPM/TPM/RPD quotas.
> 
> I will also submit the unexpected-429 reporting form referenced by Google staff, including the affected Project Number and screenshots of the AI Studio Rate Limit page.
> 
> Please let me know if any additional request/response details or timestamps would be useful for investigation.

God bless you! It helped me to solve the problem it seems…

---

<div class="post-metadata">

**Author:** ![kk\_oo1](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/kk_oo1/32/141382_2.png) [@kk\_oo1](https://discuss.ai.google.dev/u/kk_oo1)\
**Post date:** [August 10, 2026, 10:55am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/10 "2026-08-10T10:55:46Z")

</div>

**Update:** The issue is still reproducible in my environment.

I also tested with `gemini-3.6-flash` using a completely different public file and domain:

```auto

```

```auto
Model: gemini-3.6-flash
File: https://ontheline.trincoll.edu/images/bookdown/sample-local-pdf.pdf
HTTP status: 429

```

Response:

```auto

```

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

```

So this does not appear to be specific to Yahoo-hosted JPEG images or to `gemini-3.5-flash-lite`. It appears to affect the external file ingestion path more generally.

---

<div class="post-metadata">

**Author:** ![Sai\_Deepika\_K](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/sai_deepika_k/32/34803_2.png) [@Sai\_Deepika\_K](https://discuss.ai.google.dev/u/Sai_Deepika_K)\
**Post date:** [August 11, 2026, 3:29am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/11 "2026-08-11T03:29:54Z")

</div>

Hello @kk_oo1 ,

Thank you for sharing the detailed reproduction steps, We have escalated this issue and are looking into it.

---

<div class="post-metadata">

**Author:** ![Petr\_Hlavka](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/petr_hlavka/32/141045_2.png) [@Petr\_Hlavka](https://discuss.ai.google.dev/u/Petr_Hlavka)\
**Post date:** [August 11, 2026, 10:57am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/12 "2026-08-11T10:57:28Z")

</div>

> [@kk\_oo1](#):
>
> **Update:** The issue is still reproducible in my environment.
> 
> I also tested with `gemini-3.6-flash` using a completely different public file and domain:
> 
> ```auto
> 
> ```
> 
> ```auto
> Model: gemini-3.6-flash
> File: https://ontheline.trincoll.edu/images/bookdown/sample-local-pdf.pdf
> HTTP status: 429
> 
> ```
> 
> Response:
> 
> ```auto
> 
> ```
> 
> ```auto
> {
> "error": {
> "code": 429,
> "message": "Resource has been exhausted (e.g. check quota).",
> "status": "RESOURCE_EXHAUSTED"
> }
> }
> 
> ```
> 
> So this does not appear to be specific to Yahoo-hosted JPEG images or to `gemini-3.5-flash-lite`. It appears to affect the external file ingestion path more generally.

Guys, inline base64 is a way how to bypass this issue.

---

<div class="post-metadata">

**Author:** ![kk\_oo1](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/kk_oo1/32/141382_2.png) [@kk\_oo1](https://discuss.ai.google.dev/u/kk_oo1)\
**Post date:** [August 11, 2026, 12:41pm UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/13 "2026-08-11T12:41:07Z")

</div>

> [@Sai\_Deepika\_K](#):
>
> Thank you for sharing the detailed reproduction steps, We have escalated this issue and are looking into it.

Thank you for the update and for escalating the issue.

The issue is still reproducible in my environment.

I understand that using inline Base64 can be used as a workaround. However, for a multi-user application, downloading the image files on our server and then uploading them again as Base64 increases server-side network traffic, memory usage, and processing load compared with using `fileData.fileUri`.

Therefore, we would appreciate it if the issue with the external file ingestion path could be fixed so that `fileData.fileUri` can be used normally again.

Please let me know if you need any additional reproduction data or testing from my side.

---

<div class="post-metadata">

**Author:** ![kk\_oo1](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/kk_oo1/32/141382_2.png) [@kk\_oo1](https://discuss.ai.google.dev/u/kk_oo1)\
**Post date:** [August 11, 2026, 12:47pm UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/14 "2026-08-11T12:47:30Z")

</div>

> [@Petr\_Hlavka](#):
>
> inline base64 is a way how to bypass this issue.

Thanks for sharing this.

---

<div class="post-metadata">

**Author:** ![Petr\_Hlavka](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/petr_hlavka/32/141045_2.png) [@Petr\_Hlavka](https://discuss.ai.google.dev/u/Petr_Hlavka)\
**Post date:** [August 12, 2026, 9:36am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/15 "2026-08-12T09:36:21Z")

</div>

> [@kk\_oo1](#):
>
> Thank you for the update and for escalating the issue.
> 
> The issue is still reproducible in my environment.
> 
> I understand that using inline Base64 can be used as a workaround. However, for a multi-user application, downloading the image files on our server and then uploading them again as Base64 increases server-side network traffic, memory usage, and processing load compared with using `fileData.fileUri`.
> 
> Therefore, we would appreciate it if the issue with the external file ingestion path could be fixed so that `fileData.fileUri` can be used normally again.
> 
> Please let me know if you need any additional reproduction data or testing from my side.

Just a note on the performance concern with the Base64 workaround: it depends on where you do the conversion.

In our setup the file is converted to Base64 **in the user’s browser** , before it ever reaches our backend, so there’s no server-side download-and-re-upload cycle. No extra server traffic, no memory overhead — the cost sits with the client that just picked the file anyway.

We migrated a production receipt-OCR pipeline from `fileData.fileUri` to inline Base64 across ~33 test documents (JPEG, PNG, PDF). Two side effects worth mentioning: median processing time dropped by roughly half, since Google no longer has to fetch the file from our CDN, and PDF input started working.

For anyone hitting this from a browser-based app, client-side conversion may be a better answer than waiting for the ingestion path to be fixed. It’s a different architecture rather than a workaround.

---

<div class="post-metadata">

**Author:** ![Kun\_Chen](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/kun_chen/32/142082_2.png) [@Kun\_Chen](https://discuss.ai.google.dev/u/Kun_Chen)\
**Post date:** [August 12, 2026, 9:55am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/16 "2026-08-12T09:55:25Z")

</div>

Any updates on this?

It is 100% reproducible on both Gemini 3.5 flash and Gemini 3.6 flash (it’s fine on gemini 2.5 flash). As long as you include an external resource via this file URI (check the sample below, which is taken from the gemini api doc), you run into the issue every time. This is going to impact a lot of customers. This is definitely a serious incident.

`[`  
` { text: "Describe this briefly." },`  
` {`  
` fileData: {`  
` mimeType: "application/pdf",`  
` fileUri: "https://ontheline.trincoll.edu/images/bookdown/sample-local-pdf.pdf"`  
` }`  
` }`  
` ]`

---

<div class="post-metadata">

**Author:** ![Kun\_Chen](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/kun_chen/32/142082_2.png) [@Kun\_Chen](https://discuss.ai.google.dev/u/Kun_Chen)\
**Post date:** [August 12, 2026, 9:57am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/17 "2026-08-12T09:57:54Z")

</div>

I can’t believe this 100% reproduciable bugs hasn’t been fixed for a week??

---

<div class="post-metadata">

**Author:** ![Stephen\_Moore](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/stephen_moore/32/31572_2.png) [@Stephen\_Moore](https://discuss.ai.google.dev/u/Stephen_Moore)\
**Post date:** [August 12, 2026, 10:49am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/18 "2026-08-12T10:49:42Z")

</div>

And most of us had to spend God knows how long to figure out what the problem was.

Unacceptable.

---

<div class="post-metadata">

**Author:** ![Felipe\_Vargas](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/felipe_vargas/32/23092_2.png) [@Felipe\_Vargas](https://discuss.ai.google.dev/u/Felipe_Vargas)\
**Post date:** [August 12, 2026, 5:15pm UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/19 "2026-08-12T17:15:36Z")

</div>

Hi there! Dealing with the Gemini API image understanding resource was an absolute waste of time for me as well, just like for everyone here… I spent hours trying to figure out what was wrong: checking my quota, inspecting CDN limitations, digging through the documentation, and even asking Gemini AI itself!

Please, update the documentation to clarify that when you mention ‘public URLs’, you essentially mean object URLs living within Google’s own storage services (such as the Google Files API or Google Cloud Storage buckets).

My images are stored in DigitalOcean Spaces, and the only way to avoid the `429 Resource has been exhausted` error was to temporarily upload those files to the Google Files API first and then pass the resulting Google file URIs into `client.interactions.create()`. It’s not ideal to manage an extra upload step, but it’s definitely better than sending them as base64 payloads.

---

<div class="post-metadata">

**Author:** ![kk\_oo1](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/kk_oo1/32/141382_2.png) [@kk\_oo1](https://discuss.ai.google.dev/u/kk_oo1)\
**Post date:** [August 15, 2026, 12:10am UTC](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317/20 "2026-08-15T00:10:02Z")

</div>

> [@Sai\_Deepika\_K](#):
>
> Thank you for sharing the detailed reproduction steps, We have escalated this issue and are looking into it.

**Update:** I received an email from AI Studio / Gemini API support stating that backend updates were recently made so that all 429 errors should include a description field explaining the cause.

I tested the minimal reproduction again after receiving that message, using `gemini-3.6-flash` and the same public PDF via `fileData.fileUri`.

The issue is still reproducible, and the response still contains no description or quota details:

```auto
{

```

“error”: {

```
"code": 429,

"message": "Resource has been exhausted (e.g. check quota).",

"status": "RESOURCE_EXHAUSTED"

```

}

}

This request does not use Search grounding or Maps grounding.

Support also mentioned that some rate-limit-exceeded calls were found in a 30-day scan of my account. However, those may be separate from this specific reproducible `fileData.fileUri` issue, since this minimal request continues to return a generic 429 without any description.

I attempted to reply to the support email, but the reply was rejected because `ai-studio-support-external@google.com` does not accept messages from my account, so I am posting this update here.

[Next page](https://discuss.ai.google.dev/t/429-resource-exhausted-at-0-03-of-quota-reproducible-across-projects-tiers-and-endpoints/177317.md?page=2)