Use case
We run live event translation (conferences, houses of worship) in Colombia. Each operator console runs a native engine that opens one Live API session per target language (“route”), streaming mic PCM (16 kHz) continuously for 3-4 hours. The translated audio + captions are then distributed to up to 3,000 phones over WebRTC (that part never touches Gemini). A typical event today: up to 6 consoles × 2 languages = 12 steady concurrent Live sessions, each cycling through the ~10-min connection lifetime, all on paid Tier 2 projects with a pool of API keys.
Our engine follows the pattern Kaz Sato’s live-translator work arrived at independently (GitHub - kazunori279/live-translator: Real-time audio translation app powered by ADK Gemini Live API · GitHub): clean session replacement on goAway, no session resumption in routine rollover — his 1-hour soaks showed resumption degrading translation quality (98% → 65% pass), and our field data agrees.
We just finished an instrumented night of testing (probes + production engine, all timestamps below from 2026-08-31/09-01) and we’d rather share data than anecdotes. Everything below was measured with WebSocket-level probes (BidiGenerateContent directly) as well as our production engine — two independent implementations; where noted, findings were reproduced simultaneously from two independent network paths (direct ISP route and a US-datacenter relay), same key, same audio, same instants.
paths (direct ISP route and a US-datacenter relay), same key, same audio, same instants.
One honesty note on methodology: both implementations originally shared two setup fields (contextWindowCompression and sessionResumption: {}), so “ruled out: client” below means client transport and pipeline, not every byte of config. We have since removed contextWindowCompression entirely — thread 175234 documents Google staff confirming a bug where “disabling compression has been identified as a viable workaround” — but the stalls reproduce with and without it, and other reporters see them without our config (threads 179803, 179817).
What we measured
1. Concurrency headroom (good news). A soak of 60 concurrent sessions on one key/project sustained for 10 minutes worked: all 60 accepted, ~8% random churn (close codes 1006/1011), the rest stable until the connection lifetime cut. So the practical limit is ≥60/project. We could not find the actual documented limit anywhere.
2. The dashboard logs routine end-of-life closes as “409 Conflict”. Every connection gets goAway {timeLeft: ~50s} at ~9:00 and a server close (1008) at ~10:00 (observed 60/60 on this model — the goAway regression of thread 177402 seems specific to 3.1-flash-live). When our old engine let the server cut the connection, the AI Studio error graph recorded one “409 Conflict” per cut — we cross-checked a mass close of 55 live sessions against the dashboard: exactly 30+25 “409s” at the same second. These are not real conflicts; they made us chase a quota ghost for a day. (Since our engine now closes politely on goAway, our 409 panel went flat.) The mirror problem also exists: a session that silently stalls for 50 s is logged as a successful request — so the dashboard can neither show real degradation nor real conflicts. The only documented “session conflict” we found is reusing a resumption handle across two live connections (Vertex session docs), and the one forum thread on Live-API 409s (110860) ends unresolved.
3. Real 409s exist and are undocumented. HTTP 409 on the WS handshake appears after abrupt client exits followed by quick restarts (orphaned sessions still counting during some server-side grace period). Three app restarts within ~90 s produced 4 handshake 409s on a Tier 2 project running only 2-4 sessions. A clean Close frees the slot immediately. What is the grace period for abandoned sessions, and is the per-project concurrent-session limit what a handshake 409 actually means?
4. Silent stalls, per-session, on paid tier — and “zombie” session streaks. During the Aug 25-31 window (matching threads 179803 and 179817) sessions would stop delivering output for 8 to 51 seconds with the WebSocket open, no error, no goAway — then deliver everything in a burst (nothing lost, everything late). Two identical concurrent sessions (same machine, key, audio) stalled at independent moments — raw probe excerpt (10 s cycles; ult = last-turn latency, audio_rx = cumulative translated audio received):
[87s] cycle 9: direct: ult=110ms turns=3 audio_rx=33.8s | alt: ult=174ms turns=7 audio_rx=71.5s
[107s] cycle 11: direct: ult=26ms turns=5 audio_rx=103.8s | alt: ult=174ms turns=7 audio_rx=71.5s
[136s] cycle 14: direct: ult=179ms turns=8 audio_rx=132.3s | alt: ult=176ms turns=9 audio_rx=130.8s
Summary — direct: turns=11/18 median=182ms max=51237ms goaways=0
alt: turns=12/18 median=174ms max=43696ms goaways=0
At cycle 10 the “direct” session resolves a turn after a 51.2 s silence and flushes ~60 s of audio at once — while “alt” is already frozen in its own independent ~44 s stall (its counters stop at cycle 8 and move again by cycle 14, when both are healthy at ~175 ms). Identical final audio_rx on both: nothing lost, everything late — and for live translation, a 50-second-late translation is no translation. So it’s per-session server-side placement, not network, client pipeline, key, or project. Network specifically: the production machine is on gigabit ethernet and we measured 0.0% packet loss and ~2 ms jitter to the API endpoint during the affected window, with TLS handshakes stable at 109-126 ms. The worst variant: one route went through four consecutive freshly-created sessions that never translated (a single sentence across 125 transcript lines) while a sibling session on the same machine and key flowed normally the whole time. Thread 179803 reports the stalls on free tier since Aug 25; thread 179817 (Aug 27) reports 74% failures with ~1 min average latency on BidiGenerateContent, with staff requesting DMs; we can confirm it also happens on paid Tier 2. Third-party corroboration: StatusGator logged 4 Gemini/AI Studio incidents between Aug 27-31 that never appeared on Google’s status page — including one on Aug 31 evening, the exact window of our worst measurements.
5. Sessions born right after another session dies start degraded. Measured repeatedly: create sessions back-to-back (~1 s after closing the previous one on the same key) → first response takes 10-12 s; space creations ≥12 s apart → first response 4-5 s, consistently. This interacts badly with naive client retry loops (a session that “connects fine but translates slowly” tempts an immediate restart, which makes the next one worse). We now enforce a 12 s spacing client-side, but this behavior appears entirely undocumented — and spacing mitigates, it does not cure: sessions born 40+ s apart also came up degraded during the bad window.
Questions
- What are the actual concurrency limits for Live API sessions per project on paid tiers (sessions? TPM? both?), and what’s the right way to request an increase for a Live-API-heavy workload? (The quota form is TPM-oriented and doesn’t map obviously to concurrent audio sessions.) For planning: we need ~30 concurrent sessions peak today (routes + rollover overlap + hot spares) and would like budget for 50-100 as events grow.
- Is logging end-of-life connection closes as “409 Conflict” in the AI Studio dashboard intended? Combined with silent stalls being logged as successes, customers currently have no way to monitor either real conflicts or real degradation.
- What is the grace period for abandoned sessions (no Close frame) before they stop counting against the project?
- Are the silent output stalls and zombie sessions (WS open, no error, output frozen 10-50 s or absent entirely, burst catch-up) a known regression in the Aug 25+ window? Is there any signal (event, header, anything) a client could use to detect an unhealthy session faster than watching output silence? And related: is there per-project traffic shaping after usage spikes? Both our projects had unusual load the night degradation peaked, and we cannot distinguish “post-spike shaping” from “general service illness” from the outside — if shaping exists, saying so would save everyone a lot of debugging.
- Is the degraded-birth behavior (sessions created <12 s after a previous one on the same key starting ~2.5× slower) an intentional rate-adaptation? Is the 12 s spacing we measured a stable number we can rely on?
- Roadmap: any ETA for this model on Vertex AI (ref thread 170660), and given the 2-week preview retirement policy, what’s the recommended pattern for production event workloads that can’t migrate mid-event?
One honesty note on methodology: both implementations originally shared two setup fields (contextWindowCompressionandsessionResumption: {}), so “ruled out: client” below means client transport and pipeline, not every byte of config. We have since removedcontextWindowCompressionentirely — thread 175234 documents Google staff confirming a bug where “disabling compression has been identified as a viable workaround” — but the stalls reproduce with and without it, and other reporters see them without our config (threads 179803, 179817).
What we measured
1. Concurrency headroom (good news). A soak of 60 concurrent sessions on one key/project sustained for 10 minutes worked: all 60 accepted, ~8% random churn (close codes 1006/1011), the rest stable until the connection lifetime cut. So the practical limit is ≥60/project. We could not find the actual documented limit anywhere.
2. The dashboard logs routine end-of-life closes as “409 Conflict”. Every connection gets goAway {timeLeft: ~50s} at ~9:00 and a server close (1008) at ~10:00 (observed 60/60 on this model — the goAway regression of thread 177402 seems specific to 3.1-flash-live). When our old engine let the server cut the connection, the AI Studio error graph recorded one “409 Conflict” per cut — we cross-checked a mass close of 55 live sessions against the dashboard: exactly 30+25 “409s” at the same second. These are not real conflicts; they made us chase a quota ghost for a day. (Since our engine now closes politely on goAway, our 409 panel went flat.) The mirror problem also exists: a session that silently stalls for 50 s is logged as a successful request — so the dashboard can neither show real degradation nor real conflicts. The only documented “session conflict” we found is reusing a resumption handle across two live connections (Vertex session docs), and the one forum thread on Live-API 409s (110860) ends unresolved.
3. Real 409s exist and are undocumented. HTTP 409 on the WS handshake appears after abrupt client exits followed by quick restarts (orphaned sessions still counting during some server-side grace period). Three app restarts within ~90 s produced 4 handshake 409s on a Tier 2 project running only 2-4 sessions. A clean Close frees the slot immediately. What is the grace period for abandoned sessions, and is the per-project concurrent-session limit what a handshake 409 actually means?
4. Silent stalls, per-session, on paid tier — and “zombie” session streaks. During the Aug 25-31 window (matching threads 179803 and 179817) sessions would stop delivering output for 8 to 51 seconds with the WebSocket open, no error, no goAway — then deliver everything in a burst (nothing lost, everything late). Two identical concurrent sessions (same machine, key, audio) stalled at independent moments — raw probe excerpt (10 s cycles; ult = last-turn latency, audio_rx = cumulative translated audio received):
[87s] cycle 9: direct: ult=110ms turns=3 audio_rx=33.8s | alt: ult=174ms turns=7 audio_rx=71.5s
[97s] cycle 10: direct: ult=51237ms turns=4 audio_rx=94.3s | alt: ult=174ms turns=7 audio_rx=71.5s
[107s] cycle 11: direct: ult=26ms turns=5 audio_rx=103.8s | alt: ult=174ms turns=7 audio_rx=71.5s
[136s] cycle 14: direct: ult=179ms turns=8 audio_rx=132.3s | alt: ult=176ms turns=9 audio_rx=130.8s
Summary — direct: turns=11/18 median=182ms max=51237ms goaways=0
alt: turns=12/18 median=174ms max=43696ms goaways=0
At cycle 10 the “direct” session resolves a turn after a 51.2 s silence and flushes ~60 s of audio at once — while “alt” is already frozen in its own independent ~44 s stall (its counters stop at cycle 8 and move again by cycle 14, when both are healthy at ~175 ms). Identical final audio_rx on both: nothing lost, everything late — and for live translation, a 50-second-late translation is no translation. So it’s per-session server-side placement, not network, client pipeline, key, or project. Network specifically: the production machine is on gigabit ethernet and we measured 0.0% packet loss and ~2 ms jitter to the API endpoint during the affected window, with TLS handshakes stable at 109-126 ms. The worst variant: one route went through four consecutive freshly-created sessions that never translated (a single sentence across 125 transcript lines) while a sibling session on the same machine and key flowed normally the whole time. Thread 179803 reports the stalls on free tier since Aug 25; thread 179817 (Aug 27) reports 74% failures with ~1 min average latency on BidiGenerateContent, with staff requesting DMs; we can confirm it also happens on paid Tier 2. Third-party corroboration: StatusGator logged 4 Gemini/AI Studio incidents between Aug 27-31 that never appeared on Google’s status page — including one on Aug 31 evening, the exact window of our worst measurements.
5. Sessions born right after another session dies start degraded. Measured repeatedly: create sessions back-to-back (~1 s after closing the previous one on the same key) → first response takes 10-12 s; space creations ≥12 s apart → first response 4-5 s, consistently. This interacts badly with naive c