gemini-3.8-live: model replies with transcription but no audio

Gemini API
,
1

Body

## Summary

With **gemini-3.8-live** on the Live API (raw WebSocket, `v1beta` `BidiGenerateContent`), many model turns arrive

with **no audible audio**: every `serverContent.modelTurn.parts[].inlineData.data` chunk of the turn is exactly **4base64 characters**, at the normal streaming cadence. For the same turn:

- `outputTranscription` contains the complete sentence;

- `usageMetadata` reports normal AUDIO response tokens (e.g. 207), so the turn is billed;

- `turnComplete` is not sent until the turn is interrupted;

- no error is returned and the socket stays open.

The same client code against **gemini-3.1-flash-live-preview** has never shown this. The standalone script below (raw WebSocket, `websockets` only) reproduces it in **23 of 29 runs**. In our production calls on 2026-09-30, 12 of 26 model turns were affected.

## Impact

We run a telephone receptionist on the Live API. An affected turn is complete silence for the caller, who then speaks again and interrupts. The model’s context treats the unheard question as already asked. This blocks us from moving production traffic from `gemini-3.1-flash-live-preview` to `gemini-3.8-live`.

## Questions

1. Is this a known issue with gemini-3.8-live? Is there a setting or API version that avoids it?

2. Is withholding `turnComplete` on these turns expected?

Full details, per-run results and the raw log: http/drive.google.com/drive/folders/1Pr1pmdOFQ8RA0yvmqGlm02Tc_KNFfcoW

2

Same issue here, with a second backend, so this does not look limited to the Gemini Developer API.

Context: we run an AI phone receptionist for small businesses (French). Twilio Media Streams ↔ our Node.js bridge ↔ Live API over WebSocket. We are migrating from gemini-live-2.5-flash-native-audio to gemini-3.8-live on Vertex AI (v1beta1 BidiGenerateContent), prebuilt voice Achernar, default thinking. We reproduce it on the eu multi-region (aiplatform.eu.rep.googleapis.com) and also saw it on us-central1.

Latest test series (2026-10-16, eu multi-region, 35 calls / 49 model turns):

  • 8 of 49 model turns (16%) broken, in 6 of 35 calls (17%).
  • 7 turns: digital silence inserted mid-sentence. The model speaks for 1.5–1.7 s, then keeps streaming normal-sized chunks that are all zeros, while outputTranscription already contains the full sentence. 6 of these 7 were the greeting, always cut at the exact same point, right after the first sentence (“, bonjour.”). That is 6 of 35 greetings (17%).
  • 1 turn fully silent. Every chunk is AAA= (2 bytes = a single zero PCM sample), about 25 chunks/s. The transcript is complete and the audio is billed, but nothing is audible.
  • Silence length, where measurable: 2.6 s, 5.9 s, 8.5 s and 9.3 s. In the two longest cases the turn never completed by itself: it only ended with interrupted when the caller started talking. In 3 calls the caller hung up before the turn ended.
  • No error, and the socket stays open. We checked against the recorded call audio (model channel), not only our logs. outputTranscription arrives before the audio, so the transcript looks perfect while the caller hears silence.

Affected Live sessions (Vertex AI, eu multi-region, times in UTC):

Session ID Silence starts (UTC) What happened
5894ad08-0e1b-474a-971a-1057e21c9e62 2026-10-16 13:47:24 Greeting cut after 1.5 s; silence ~5.9 s until turnComplete
5894ad08-0e1b-474a-971a-1057e21c9e62 2026-10-16 13:47:36 2nd turn cut after 1.6 s; caller hung up before the turn ended
12f22dcd-3eef-4bfc-88c6-6da1f5707439 2026-10-16 13:48:30 Greeting cut after 1.5 s; caller hung up before the turn ended
3510592b-5b09-4160-a3c0-3b508a7a7dcc 2026-10-16 14:19:41 Greeting cut after 1.5 s; silence ~9.3 s, ended only by interrupted
83ad390d-6668-4eb0-a84a-f219ab9401d8 2026-10-16 14:21:53 Greeting cut after 1.5 s; silence ~2.6 s until turnComplete
83ad390d-6668-4eb0-a84a-f219ab9401d8 2026-10-16 14:22:01 Fully silent turn (AAA= only), transcript “Je vous écoute.”
92beb75a-1eb7-4af8-80b9-c45520e80aaa 2026-10-16 14:22:19 Greeting cut after 1.5 s; silence ~8.5 s, ended only by interrupted
dd80d125-9071-4f65-8b19-86a3051a9ec8 2026-10-16 14:24:30 Greeting cut after 1.7 s; caller hung up before the turn ended

The other 29 sessions of the same series, with identical setup and prompt, had no broken turn.

We have never seen this on gemini-live-2.5-flash-native-audio with the same bridge code.

Why it hurts on the phone: while a silent turn is still open on the server, the caller assumes nobody is there and starts talking. The model then misunderstands or answers out of context. We found no clean way to close the stuck turn from the client:

  • clientContent with turnComplete: false does not interrupt it.
  • Sending an empty turn does interrupt it, but triggers a new model response.

Questions for the Google team:

  • Is this tracked internally as a known issue for gemini-3.8-live (Gemini API and Vertex AI)? Is there an ETA?
  • Is there a setting, region, or API version that avoids it in the meantime?
  • Is there a supported way to cancel or close a server turn that is stuck emitting silence?

gemini-live-2.5-flash-native-audio retires on 2026-12-13. As things stand we cannot move production traffic to 3.8, so a fix before then is critical for us. We can share the recordings and our Google Cloud project ID privately if that helps.

3

Follow-up: we ruled out our own greeting injection as the cause.

All our earlier sessions started with a clientContent ({turnComplete: true}) to make the model greet first. So we ran a series where the bridge sends no clientContent, no text and no tools at all: only caller audio over realtimeInput, with turns triggered by server VAD (caller says “Allô ?”, then “Comment ça va ?”).

Results (2026-10-16 15:52–16:01 UTC, Vertex AI eu multi-region, same setup otherwise, 17 calls):

  • 5 of 16 greetings broken (31%): 3 fully silent (AAA= chunks only, full outputTranscription), 2 cut after the first sentence then silence.
  • 4 of 18 later turns broken (plus 2 turns where the first audible chunk only arrived ~2 s late).
  • 7 of 17 calls affected. That is at least as bad as our series using a clientContent trigger (6/35 calls).

So the bug occurs with pure audio input and no client-side content. Affected sessions (UTC):

  • 0281dd3c-718e-4cb0-9cc0-44b378e919a9: 15:55:18
  • 36e42ab8-789f-4924-b105-600477b77a5e: 15:55:35
  • 798be953-4baf-4ec6-a380-81bbcbaa2063: 15:56:21
  • 1e04976e-db19-4211-9420-d77b9b18adc6: 15:56:58
  • 5597d9f9-4c32-41b4-b705-178893ff0a86: 15:57:11
  • bca4709b-23f0-4650-8ac0-79592d09f60b: 15:58:10
  • 7f7b7e3a-1c39-43d9-b4fc-54d7df8c1e2a: 16:00:50
4

Some controlled measurements from our side, on the Gemini Developer API from Taiwan.

Test. One spoken utterance is streamed over realtimeInput. The model calls one tool, and we judge only its reply sentence after the tool response. The arms run interleaved, 30 trials each, so they share the same time window.

“Usable” means audible from the start. We also count it as usable when only the first 1–2 chunks are 3-byte empties, because 3.1 does that on 28 of 30 normal turns too.

3.1 vs 3.8, same network, same 45 minutes:

Model Usable Head missing (8–46 empty chunks, then audio) Fully empty
gemini-3.1-flash-live-preview 29/30 0 0
gemini-3.8-live, tools BLOCKING 10/30 7 11
gemini-3.8-live, tools NON_BLOCKING 10/30 9 10

Official SDK vs raw WebSocket (gemini-3.8-live). The SDK is google-genai 2.10.0, and it sends the same frames as our raw client.

Client Usable
SDK, BLOCKING 4/30
SDK, NON_BLOCKING 11/30
raw, BLOCKING 13/30
raw, NON_BLOCKING 13/30

Conclusions

  • Only 3.8 is affected.
  • The client library and the tool behavior make no difference.
  • 41 of 42 fully empty turns never sent turnComplete within 25 s.

Workaround. A clientContent text with turnComplete: true cuts the silent turn and makes the model regenerate. When the next turn is also empty, a fresh session (not a resumed one) recovers better. We stay on 3.1 for now.

5

We are getting this also.

Can google engineering team expedite this it’s causing grief with the test teams.

6

Hello,

Please ensure temperature is left at its default value of 1.0 (remove any lower temperature setting from generationConfig), as recommended in the Gemini 3 temperature guide. Please retry with the default temperature and let us know if you still see silent turns.

7

I will test and feedback.

One thing to be ware of if you set temperature high e.g 1.0 and spell e.g ROBERTS it spells it R O B E E R T S sometimes. However if you slow it down with comma’s it seems to resolve it but the readback is slower. If you set temperature low you don’t typically see this issue.

I cannot 100% confirm but we have two projects which get stuck in loops so I have fed this to the other engineering team on the temperature 1.0 recommendation. I seems to stop the looping. The silence issue has not gone away,

I’ve put this into my AI Advisors (Gemini and Claude) and it’s analyzed all our logs. Both concluded same outcome.

It’s worth the google engineering team to know that suggested 1.0 is not solving silence.

SUMMARY

Six of the 19 calls hit at least one defect. Our client works around each one (re-prompts, a local turn end, a transfer), but these mitigations add seconds of silence or end the call.

Defect Calls affected (of 19)
1. Silent turn: no audio after a function response, even after the client sends turnComplete 2
2. Runaway audio: the model keeps generating for 13–15 s with no turnComplete 2
3. Session dropped with WebSocket 1006, no goAway 1
4. Audio differs from the model’s own outputTranscription; tool call skipped 2

Evidence (all times UTC; each line also gives the session ID our client stack reported at SetupComplete)

1. Silent turn after a function response

26 Oct 2026, session 10e5ff32-6712-43ee-a8e6-d626552886d4

  • 03:13:10.522: function response sent (the result of a booking change).
  • No serverContent of any kind for 1.46 s. At 03:13:11.982 the client sends clientContent with turnComplete: true (nudge 1).
  • Still nothing. At 03:13:13.481 the client sends nudge 2.
  • 03:13:14.198: first outputTranscription. Audio starts at 03:13:14.451.
  • 3.9 s of silence after the function response. The caller waited 6.8 s in total from finishing speaking.

25 Oct 2026, session 95847c44-0ba0-4776-96ba-a8d73986a57b

  • 19:29:32 to 19:29:38: after the runaway turn below, the client re-prompted the model and got no audio (silent turn recorded at 19:29:36.020).

2. Runaway audio with no turnComplete

25 Oct 2026, session 95847c44-0ba0-4776-96ba-a8d73986a57b

  • 19:29:06.025: audio starts in reply to the caller.
  • It runs for 14.9 s (54 words) with no turnComplete or generationComplete. The client ends the turn locally at 19:29:20.896.

25 Oct 2026, session 9085d750-9a6d-451b-b0a1-07e4aa72cd85

  • About 16:08:36.7 to 16:08:50.261: the same pattern, 13.6 s, at a yes/no confirmation question. The client ended the turn.

3. Session drop, WebSocket 1006

25 Oct 2026, session aafb638d-377e-4830-a20c-8615e59c6049

  • 20:15:05.361: a normal generationComplete and turnComplete, with usageMetadata.
  • 20:15:07.5: the caller starts speaking (audio streaming to the model).
  • 20:15:09.383: WebSocket closed with 1006, “No close code frame has been received”. No goAway was received first, and the session was about 3 minutes old (about 20.6k tokens).
  • The call had to be transferred. We have no supported way to resume after an unexpected 1006.

4. Audio differs from transcript; tool call skipped

24 Oct 2026, session 48730a0e-d58f-4356-b6dc-10e3860ad99e (about 20:17–20:19)

  • The recording has the model saying the start of the scripted confirmation line, then the ending of an earlier line that begins the same way (“…Could I take your first and last name…”).
  • outputTranscription for the same moment holds the correct scripted line. The audio and the transcript disagree.

24 Oct 2026, session ce43e891-01c8-4bad-8a90-83319c8538f9 (about 20:43–20:45)

  • The caller answered “Yes” to a confirmation question. The model did not call the confirmation function (2.5 always did). It improvised the next question in its own words and called the following function with empty arguments.

Control: a clean call on the same setup

26 Oct 2026, session 5671980f-6858-4faa-8a17-6859fe64f893 (02:34–02:36)

  • No defects. Audio started 0.6–0.9 s after each step. This shows the integration and configuration are correct when the model behaves.

Conclusion
This is a P1 (not a P2/P3) - it makes a system unusable and a show stopper.

Also if you are not auto testing all these use cases with automated calls with test results you should be. I launched a 45 million people voice / speech system and hammered it with automated test calls, routes, metrics, resilience, user cases.

Set one agent with voice/speech/detection capabilities (user cases) and call the other, generate the metrics and see all the edge bugs. This will dramatically shorten your cycles and find the issues. Once you have the logs put it through a code analysis and identify your issues.

might help!

8

Thank you! Seemed this is the key reason. In order to get a stable behavior , my previous temperature setting was 0.3~0.4 while using Gemini 3.1-live, which didn’t show problem yet bit me hard after changing to Gemini 3.8.

Now I use as setting that temperature 0.8~0.9, topK=0.8 and topP = 20, it behaved smooth and stable.

9

Thank you! Temperature was indeed the core reason led to this anomaly. I used a low one previously in Gemini 3.1-live which didn’t show problem.

Now I use as setting that temperature 0.8~0.9, topK=0.8 and topP = 20, Gemini 3.8 behaved smooth and stable.

10

I would not fully conclude this. Another team we have are reporting this issue on a pure gemini voice 3.8 and set it to temperature 1.0 - it still has silence on turns. I can’t tell you how often, maybe a lot less but it occurs.

If you raise the temperature it introduces other issues also. For example doing things with spelling/letters, it adds, omits letters in name during read backs. If you lower the temperature this problem typically goes away in combination with careful separate of spoken elements.

What I can conclude is the recognition has improved a lot more, and the output transcription has and the audio arrival has improved.

What has come in is

  1. Lower expressiveness compared to 2.5 - upbeat, joyful, excited seems to be totally missing now - In 2.5 I could adjust those in the instructions - has no effect in 3.8.
  2. Voice is slower than I would expect - one of our engineers comments she is speaking slow today when testing a customer solution.

This maybe because of the re-introduction of languageCode back in to stop the American voice and the sliding in and sliding out of an American voice in the early 3.8 release

Things I see occurring (some more than others)

Problems

  1. TURN SILENCE - turning temperature to 1.0 is not a solution BTW. Any temperature set should not impact turns being silent.
  2. VOICE SPEEDH - Voice speech is slower (maybe because of the re-introduction of languageCode?) to fix the UK English / American issues. At least now the UK English always speaks UK English.
  3. READBACK ASSURITY - If you want assured output in the audio elements where the LLM audio can’t get it wrong , then why not use a tag e.g. Jamieson or CK39393993 or CK-3948838 and bypass the LLM audio thinking
  4. EXPRESSIVENESS - Inject the kind of thing 2.5 expressiveness you had (joyful, happy, excited) - whilst it had is variances on the voice it was promising.
  5. ANNOYING BEHAVIOURAL TAGS - End instruction tags outputting into the text transcription (pass them as event notifications) but never in the text transcription or at least give the developer an option to block them (turn them off)
  6. SPEAKING RATES - some vendors are using speaking rate (even with ML TTS) rate from 1.00 to 1.50. This does work and you can nicely adjust it for your user case.