Regression since ~Aug 4: GoAway no longer sent before Live API connection close (gemini-3.1-flash-live-preview) — connections now die silently

[Kiarasch_Kuschki]

Model: gemini-3.1-flash-live-preview (Gemini API via generativelanguage.googleapis.com WebSocket, half-cascade audio, de-DE, session resumption enabled)

Summary: Until Aug 3 we reliably received the documented goAway notice (~50 s timeLeft) before every connection termination. Since Aug 4 it has stopped arriving — connections now close hard (1006, empty reason) or die completely silently with no close frame at all. The connection lifetime itself is roughly unchanged (~8–9 min); only the advance warning is gone.

Evidence from a nightly automated check (identical probe every night at 01:25 CET: open a session, stay idle, measure time to termination and whether GoAway precedes it):

• Aug 1: GoAway after 540.3 s, timeLeft “50s”, clean close
• Aug 2: GoAway after 540.3 s, clean close
• Aug 3: GoAway after 540.3 s, clean close
• Aug 4: hard close 1006 (empty reason) after 533.1 s — no GoAway
• Aug 5: hard close 1006 after 523.1 s — no GoAway
• Aug 6: hard close 1006 after 480.6 s — no GoAway (the lifetime also appears to be shrinking)

The probe code is unchanged since Jul 25 — the same instrument that measured green through Aug 3 measures red since Aug 4.

Corroboration from live sessions (different network, different codebase):

• Aug 4, morning: a 15-minute session still received one GoAway at min ~8.9 (timeLeftMs: 50000) — so the change appears to have rolled out gradually during Aug 4.
• Aug 5: an 18.9-minute session received no GoAway at all; the connection died silently twice (min ~7.3 and ~15.8) — no close frame, wasClean: false. These sessions stream audio continuously, so idle timeouts on the network path don’t apply; we only detect the death via a response watchdog (~7 s), after which a resume reconnect succeeds in <1 s with context intact.
• Aug 6: same pattern again, silent death ~7 min into a session.

Impact: Without GoAway the documented graceful-handover pattern is impossible; every ~7–9 minutes users now experience several seconds of “the assistant stopped responding” before watchdog-based recovery kicks in.

Questions:

1. Was there a server-side change around Aug 3/4 affecting GoAway delivery for gemini-3.1-flash-live-preview?
2. Is GoAway still a guaranteed part of the connection-termination contract, or should clients now treat silent connection death as expected?
3. Possibly related to the ongoing investigation in this thread (1011s / resumption on the same model)?

An earlier report of GoAway-less closes (idle case, Dec 2025) is here — at the time the answer was “timeout and GOAWAY notification work correctly”. Our measurements show a clean before/after break on Aug 3→4, so this looks like a fresh server-side regression rather than a client issue.

Happy to provide exact timestamps or sanitized logs if that helps reproduce.

[Kiarasch_Kuschki]

Update after six more nightly measurements — this has gotten significantly worse, and it
is no longer just the missing GoAway.

1. The idle lifetime is collapsing. Same automated probe as in the original post
(code unchanged since Jul 25; open a session on gemini-3.1-flash-live-preview, stay
idle, measure time to termination and whether GoAway precedes it):

Aug 1:  GoAway after 540.3 s, timeLeft "50s", clean close
Aug 2:  GoAway after 540.3 s, clean close
Aug 3:  GoAway after 540.3 s, clean close
Aug 4:  hard close 1006 (empty reason) after 533.1 s — no GoAway
Aug 5:  1006 after 523.1 s — no GoAway
Aug 6:  1006 after 480.6 s — no GoAway
Aug 7:  1006 after 391.4 s — no GoAway
Aug 8:  1006 after 309.5 s — no GoAway
Aug 9:  1006 after 253.1 s — no GoAway
Aug 10: 1006 after 191.6 s — no GoAway

Through Aug 3 the lifetime was deterministic to the second (540.3 s three nights in a
row). Since Aug 4 the warning is gone and the idle lifetime has fallen from ~9 minutes
to ~3.2 minutes within one week, shrinking almost monotonically by ~60–90 s per day.

2. Active sessions show a second face of the problem — response-plane stalls on an
OPEN socket. Across nine real sessions on Aug 10 (continuous audio streaming, so idle
timeouts on the network path do not apply), our client detected five silent response
stalls in four sessions (four unambiguous, one with a possible VAD confound), at
session ages of 65.5, 82.1, ~89.5, 153.7 and 497.9 seconds. In every case the WebSocket
remained OPEN and the server kept delivering sessionResumption handle updates at ~1/s
throughout the silence window — only the response plane went quiet. No GoAway, no close
frame. Our response watchdog (~7 s) then tore the session down; the resume reconnect
opened a fresh socket in 150–200 ms and recovered with context intact, proving the
network path was healthy. Each stall costs the user roughly eight seconds of “the
assistant stopped responding”. Independent corroboration from another user:
WebSocket ping timeout after ~170 seconds on the same model (2.5 Live worked fine).

Impact: This is a production voice application with long-running conversations.
Without GoAway the documented graceful-handover pattern is impossible; with idle
lifetimes collapsing and active sessions stalling at unpredictable moments, users hit
multi-second freezes several times per conversation. And with the earlier Live
generations retired or scheduled for retirement, gemini-3.1-flash-live-preview is
effectively the only Live API path going forward — currently degrading week over week.

Open questions, more urgent than a week ago:

1. Was there a server-side change around Aug 3/4 affecting GoAway delivery for
   gemini-3.1-flash-live-preview — and is it a known incident?
2. Is GoAway still a guaranteed part of the connection-termination contract, or should
   clients now treat silent connection death as expected?
3. Are the shrinking idle lifetime and the mid-conversation response stalls intentional
   (quota/abuse control?) or part of the same regression?
4. Possibly related to the ongoing investigation in
   this thread (1011 / resumption on the same model)?

An earlier report of GoAway-less closes
(idle case, here)
was answered at the time with “timeout and GOAWAY notification work correctly”. Our
measurements show a clean before/after break on Aug 3→4 plus a progressive decay since,
so this looks like a fresh, evolving server-side regression rather than a client issue.

Full sanitized JSONL logs of every nightly run since Aug 1 are available on request.

[Kiarasch_Kuschki]

Update (Aug 16) - partial recovery observed, monitoring continues

Since my Aug 10 post, our nightly probe (same setup: WebSocket,
gemini-3.1-flash-live-preview, idle connection, timestamped) first saw the
decline bottom out and then a return of the documented behavior:

• Aug 11: hard close (1006) after 136.7 s, no GoAway
• Aug 12: hard close (1006) after 72.7 s, no GoAway
• Aug 13: hard close (1006) after 16.6 s, no GoAway (trough)
• Aug 14: GoAway after 540.1 s idle, timeLeft “50s” — documented behavior
• Aug 15: identical (540.1 s, GoAway with timeLeft)
• Aug 16: identical (540.1 s, GoAway with timeLeft)

So for three consecutive nights the pre-close GoAway notice is back, at the
pre-Aug-4 ~9-minute idle lifetime, with the timeLeft duration format unchanged.
Our session-start and function-calling probes pass as well.

I’m not calling this resolved yet - the decline in week 1 was gradual, so a
few good nights don’t prove stability. We’ll keep the nightly probe running
and report back if it regresses again.

Was there a fix or rollout on the service side around Aug 13/14 that Google
can confirm? That would help us decide whether to remove the client-side
tolerances we added during the regression.

[DIGITALMIDI]

I can confirm that I’m seeing very similar intermittent behavior with gemini-3.1-flash-live-preview.

I maintain a real-time voice assistant application, and the Live API had been working very well for us previously. Recently, however, we started seeing intermittent stalls, unusually high response latency, and sessions that remain connected but stop producing useful audio responses.

What makes this particularly interesting is that I was able to reproduce the issue outside of our main application using minimal test scripts.

I tested gemini-3.1-flash-live-preview with a very simple text input → audio output setup:

• No microphone

• No camera/video

• No function/tool calling

• No application UI

• Fresh Live API session

In one run, several consecutive turns worked perfectly, with first audio typically arriving in approximately 0.8–1.5 seconds.

Only a few minutes later, using the same script and model in a new session, the very first simple "hello" took 8.617 seconds before the first audio arrived.

I also reproduced another failure mode using a direct WebSocket test: the first turn completed normally, but a subsequent turn stalled while the WebSocket remained open. After sending another message, I received INTERRUPTED, followed by TURN_COMPLETE with 0 audio bytes.

I also upgraded the Python google-genai SDK from 2.18.1 to 2.19.0, but the behavior remained the same.

This appears highly intermittent: sometimes the same minimal test works extremely well for several minutes, and then a fresh session can immediately exhibit very high latency or stall.

We are also seeing similar behavior across multiple installations/users of our application, which is why I started testing the Live API independently from the application itself.

Has anyone else observed this kind of response-plane stall / large first-audio latency variation while the WebSocket itself remains connected?

And if anyone from the Google team is following this thread: was there any server-side change or rollout affecting gemini-3.1-flash-live-preview recently?

I can provide timestamps and additional logs if useful.

[Charlie_Peen]

I too can confirm this. It really became apparent for me around 8/17. I have a game plugin that solely relies on gemini-3.1-flash-live-preview to function, and it’s become basically unplayable now. Responses routinely delay or don’t arrive at all and users are getting horrible audio glitches and dropouts where the audio arrives in cutoff chunks with delays in between. My forum is flooded with these reports. Here’s my testing breakdown:

1. Connections are hard-aborted at 151 seconds, without GoAway. My logs show server closes with reason “The operation was aborted.” at metronomic ~151-second connection age — e.g., closes at 1:16:15, 1:18:47, 1:21:20, 1:23:53, 1:26:25 PM, for hours. Previously connections lived ~10 minutes and a goAway message arrived before termination; in an entire day of logs with dozens of aborts, I saw only 2 GoAway messages. Clients that relied on GoAway as the pre-termination signal now get killed mid-response with no warning.

2. Invalid resumption handles are accepted at setup, then kill the session on first use. Sessions resumed with a stale handle receive setupComplete normally, live 10–120 seconds, then close with “Precondition check failed.” the moment a turn is committed — eating the user’s turn. Concrete trace: one handle was resumed 4 times over 4 minutes; three consecutive committed turns got zero response, each followed by a precondition-failed close (session ages 112.1s, 10.6s, then repeat). Because the rejection doesn’t happen at setup, clients can’t distinguish a dead handle from a live session until a user turn is lost. (I note the official JS SDK special-cases this exact error string for retry, which suggests this is a known server behavior.)

3. Dead generations on healthy sessions. Repeatedly: turn committed (activityEnd after ~1s of speech), socket remains Open, no error, no close — and no response of any kind ever arrives (no audio, no transcription, no tool call). In one 3-minute window, I logged seven of these on freshly created sessions (no resumption involved).

4. Generation start latency of 11–15 seconds during bad windows. Same sessions, time from turn commit to first audio chunk: 11.0s, 11.1s, 11.8s, 15.2s. In healthy windows the same client/key measures 0.5–1.6s.

5. Mid-stream stalls: audio delivered slower than real time. Responses arrive smeared — e.g., ~5s of speech delivered over 14s of wall time, which plays as fragments of words with 1–2s silences. My standalone probe quantified this outside the game: across 30 turns (10 consecutive sessions, one at a time), 9 turns had an inter-chunk gap over 500ms, worst case a 4.1-second stall mid-response, on an otherwise healthy connection.

6. The severity is time-varying. The identical key, client, and session shape went from catastrophic (items 3–5 at their worst) to merely jittery (~1s first-audio, occasional 1–4s stalls) within 45 minutes, with zero client changes. This is consistent with an infrastructure/capacity issue, not client behavior — I verified my exact transport (raw WebSocket, same setup JSON) performs perfectly when the service is healthy, and I reproduced the degradation independent of my application.

I also logged one “You exceeded your current quota” close on a day of heavy testing (free tier), mentioned for completeness — the failures above occurred well away from that event, on multiple keys, including a newly created one. This is impacting paid tier keys as well. Several users have paid for pre-pay keys in hopes of better performance and did not get it - losing out on their credits.

Like others, my plugin has been using gemini-3.1-flash-live-preview since its release, and for the most part, even as a preview model, it’s been pretty rock solid for my needs. If anyone from the Google team needs log information or specific testing metrics, please let me know. I’ll do whatever I can to help get 3.1 back on track and my user base back to enjoying the mod they paid for.

[Charlie_Peen]

The issue has only gotten worse. It’s also impacting other Gemini models. I can confirm I’ve had the same issues with Gemini Flash 3.1 TTS, as well as their STT models. There’s still been no formal announcement from anyone regarding this issue or what changed last month. I’m having to find alternate solutions now to replace Gemini, which deeply saddens me.