We run a production telephony assistant on the Live API (BidiGenerateContent, audio in/out, tools, input/output transcription). Until 2026-09-05 ~09:00 UTC our first-audio latency after the opening clientContent turn was consistently ~1.0 s (139 of our last 400 calls < 1.5 s). Since then it is 9–15 s and in roughly 1 of 3 sessions no audio arrives within 15 s at all. Callers hang up before the model speaks.
Reproduction (independent of our app — plain WebSocket, setup + one clientContent text turn + 16 kHz PCM silence):
- server (Oracle, eu), project A key: 14.1 s, 14.8 s, 11.6 s, 10.9 s, 1× none in 15 s
- same key from a laptop on a different network: 11.8 s, 11.6 s, 1× none
- a freshly created key in a different project (Tier 1): 12.2 s, 13.6 s, 2× none
- gemini-2.5-flash-native-audio-latest, same setup, same minute: 1.9–2.4 s
- setupComplete itself is fast (~300 ms); the delay is entirely between the first user turn and the first serverContent audio part. No usageMetadata arrives during the silent period.
- Additionally, warm sockets are frequently closed at setup with 1008 “Request had invalid euc header” (69 occurrences in our log); a fresh socket retry succeeds, so this is separate from the latency problem.
Setup: generationConfig.responseModalities=[“AUDIO”], systemInstruction (5–17k chars, but a 200-char instruction shows the same latency), 4 functionDeclarations, inputAudioTranscription/outputAudioTranscription enabled, automaticActivityDetection disabled (manual activity), Turkish content.
AI Studio Playground responds normally for the same model, so this looks specific to the API serving path. Is this a known incident? Is there a status page entry or an ETA? We have moved production to 2.5 native audio in the meantime. But it doesn’t match the quality:(.