SUGGESTED TITLE: 429 "prepayment credits are depleted" triggered specifically by thinkingConfig:{thinkingBudget:0} on gemini-3.6-flash — same key/project works without it

I found a specific, reproducible trigger for the “prepayment credits are
depleted” 429 error that I haven’t seen mentioned in the other threads
about this bug (e.g. the ones tagged “billing” / “prepay-sync”). Posting
in case it helps narrow down the root cause.

Model: gemini-3.6-flash
Project: confirmed Free tier in AI Studio, no billing account ever linked

Reproducible pattern:

The exact same API key, same project, same endpoint
(generativelanguage.googleapis.com/v1beta/models/gemini-3.6-flash:generateContent)
gives two different results depending on ONE field in generationConfig:

FAILS — every time, with the “prepayment credits are depleted” 429:

{
  "contents": [{ "parts": [{ "text": "..." }] }],
  "generationConfig": {
    "temperature": 0.3,
    "maxOutputTokens": 4096,
    "thinkingConfig": { "thinkingBudget": 0 }
  }
}

WORKS — same key, same project, same prompt, only difference is the
absence of thinkingConfig:

{
  "contents": [{ "parts": [{ "text": "..." }] }],
  "generationConfig": {
    "temperature": 0.3,
    "maxOutputTokens": 4096
  }
}

Error body from the failing request:

{
  "error": {
    "code": 429,
    "message": "Your prepayment credits are depleted. Please go to AI Studio at https://ai.studio/projects to manage your project and billing.",
    "status": "RESOURCE_EXHAUSTED"
  }
}

I tested this across 6 different API keys from 6 different Google Cloud
projects (all confirmed Free tier, no billing linked on any of them).
All 6 succeeded when thinkingConfig was omitted. One of the 6 had been
consistently failing with the prepayment error for several days
specifically when thinkingConfig:{thinkingBudget:0} was included in the
request — removing that single field fixed it immediately, with no
other change (same key, same project, same model).

My guess is that explicitly disabling thinking on a model that has
thinking enabled by default routes the request through a different
internal billing/quota check than a “normal” request, and that path is
the one affected by the prepay-sync bug reported in the other threads
here. Since gemini-3.x models think by default, most people hitting
this bug probably aren’t setting thinkingBudget:0 explicitly, which
might explain why this specific trigger hasn’t come up yet.

Happy to provide the affected project ID / key details if useful for
debugging — didn’t want to post them publicly here.

Hello @Arturo_Carballo ,

Thank you for sharing your detailed investigation. We are looking into this and will keep this thread posted

Hello @Arturo_Carballo ,

This issue has been fixed now.