Native Audio Live free-tier setup quota rejection below visible TPM — which admission metric applies?

We use models/gemini-2.5-flash-native-audio-latest. The console displays
1,000,000 input TPM and unlimited RPM/RPD; its seven-day peak was 3.79%.
We seek 100 concurrent conversations using the same three Native candidates
and one Transcribe Live provider per conversation. We are not claiming
this capacity is already available.

On October 1, 2026 we ran fixed, once-only controls using existing independent
projects, identical production provider/setup/prompt, thinkingBudget 128,
fresh history, no user input/output, no retries or fallback. Render was
suspended and no transcription provider was connected. The owner confirmed
there was no other active application using these projects.

Two matched project controls prepared six Native sockets and rejected the
seventh. Delaying the seventh until 75 s with only three prior starts in 60 s
also failed. Another control rejected the sixth after five ready sockets.
We then tested confirmed close/replacement: five ready, first B peer-closed,
four remained ready. Sixth C was rejected both ~1.758 s and ~65.952 s after the
confirmed close. In the delayed case no prior opens were within 60 s.

All 39 focused socket attempts physically closed, final live count 0.
Rejections occurred before setupComplete: peer close 1011, a 123-byte
quota-exceeded/billing reason with the same digest in all six controls,
but no structured metric/quotaId/violations/retry delay. Our local numeric
classification is 429. Google Bidi metrics also showed a 429 series in the
first large setup window. Earlier in that large window two projects briefly
had seven ready, so we do not infer a universal five/six connection limit.

The only visible active-session quota row in the console was paid tier 3;
we have not used that value as a free-tier limit. A read-only quota API
attempt with existing CLI authentication returned Cloud Quotas SERVICE_DISABLED
and Service Usage AUTH_PERMISSION_DENIED; it did not reveal an enforced limit.

Which exact Native Live admission metric applies, where can its enforced
free-tier value be read, and is its scope project/account/IP or another
shared scope? Does it count open/ready/closing/resumable sessions or new
setups over a longer window? What is the release delay after peer-confirmed
close without sessionResumption? What documented capacity/headroom is needed
for 300 Native +100 transcription connections? Please identify the metric;
we do not want to assume that a billing change or more API keys guarantees it.

Hello @Tuna_Kosar, thanks for the detailed testing. Free tier projects have a limit on concurrent Live API sessions. To run 100+ concurrent conversations, we recommend moving the project to a paid tier, where concurrent sessions scale with your TPM rate limits (https://ai.google.dev/gemini-api/docs/rate-limits).

Thanks, @Payal_Sharma2. What are the exact concurrent-session limits and quota metric for Free tier and paid Tier 1? Are Gemini 2.5 Native Audio and Transcribe Live counted together, and is the limit per project, account, or IP? For 100 conversations (300 Native + 100 Transcribe connections), which quota values must we verify, and where?