Paid Tier 2 project: consistent 503 on gemini-3-pro-image-preview (Nano Banana Pro) while Tier 3 in same billing succeeds 100% — reproducible diagnostic

Gemini API
1

Hi all,

Posting a reproducible diagnostic in case anyone else is hitting this,
and hoping for guidance from the Gemini API team.

TL;DR — gemini-3-pro-image-preview (Nano Banana Pro) and
gemini-3.1-flash-image-preview (Nano Banana 2) both refuse every
request from a Paid Tier 2 project with HTTP 503, while a Tier 3
project in the same billing account succeeds on every attempt.
gemini-2.5-flash-image works fine from the same Tier 2 project.
The single variable that determines success is the project’s billing
tier.

Setup

Project A (affected) Project B (control)
Tier Paid Tier 2 (postpaid, active) Paid Tier 3
Billing account shared (same) shared (same)
Project ID studiofreewillusion-ta (other)
Project number 87813803557 -–
Resource name projects/87813803557 -–
Created 2026-05-04 (older)

Region: requests from KR. REST v1beta generateContent.

Reproduction (run back-to-back within the same minute)

curl -sS -w "\nHTTP %{http_code} | %{time_total}s\n" \
  -X POST "https://generativelanguage.googleapis.com/v1beta/models/gemini-3-pro-image-preview:generateContent?key=$KEY" \
  -H "Content-Type: application/json" \
  -d '{"contents":[{"parts":[{"text":"a red apple on white background"}]}]}'

5 attempts each:

Key tier Model Success Notes
Tier 2 gemini-3-pro-image-preview 0 / 5 HTTP 503 in 1–3s every time
Tier 3 gemini-3-pro-image-preview 5 / 5 HTTP 200 in 18–26s, image returned
Tier 2 gemini-3.1-flash-image-preview 1 / 5 4× 120s timeouts, 1 lucky 33s success
Tier 3 gemini-3.1-flash-image-preview 5 / 5 HTTP 200 in 18–28s
Tier 2 gemini-2.5-flash-image 5 / 5 HTTP 200 in ~7s — works fine

Tier 2 response body for gemini-3-pro-image-preview (identical
every time, 198 bytes):

{
  "error": {
    "code": 503,
    "message": "This model is currently experiencing high demand. Spikes in demand are usually temporary. Please try again later.",
    "status": "UNAVAILABLE"
  }
}

Response headers of interest:

X-Gemini-Service-Tier: standard
Server-Timing: gfet4t7; dur=1499
(no Retry-After header)

models.get and models.list return 200 with the model entries
present on the Tier 2 key — permissions/key validity are not the
issue.

What this rules out

  • :cross_mark: Client / SDK bug — direct curl reproduces it
  • :cross_mark: Invalid key / wrong project — metadata APIs return 200
  • :cross_mark: Network — Tier 3 key succeeds from same machine within seconds
  • :cross_mark: Global model outage — Tier 3 has 0 failures across both models
  • :cross_mark: Project ramp-up alone — the hard, deterministic cutoff between
    Tier 2 and Tier 3 within the same billing account points to
    tier, not project age
  • :cross_mark: Old vs. new image model — gemini-2.5-flash-image works on
    Tier 2; the cutoff specifically tracks the Gemini 3 image family

Questions

  1. Is restriction of gemini-3-pro-image-preview and
    gemini-3.1-flash-image-preview to Tier 3 intended during the
    preview capacity ramp, or is this an allocation issue?
  2. If intended, is there a documented path for Tier 2 paid customers
    to access these models — explicit capacity allocation, waitlist,
    or manual escalation through Support?
  3. Anyone else on Paid Tier 2 actually getting gemini-3-pro-image-preview
    to return 200 right now? Replies welcome — would help isolate
    whether this is universal Tier-2 behavior or specific to my
    billing account.

Affected project (for any Googler reading this): projects/87813803557
(studiofreewillusion-ta). Happy to share full diagnostic logs,
request IDs, or billing context via the appropriate secure channel.

Thanks,
— Hyunwoo Kim, Studio Freewillusion

2

Thank you for sharing this

I am investigating this and will send your a DM with more details