Gemini Live retirement: what changes for voice agents on 17 November

Google shuts down the Gemini API's two preview Live models, gemini-3.1-flash-live-preview and gemini-2.5-flash-native-audio-preview-12-2025, on 17 November 2026, along with three preview TTS models. All of them point to Gemini 3.8 Live or the 3.8 TTS models. Changing the model ID takes a minute; the replacement changes when tools run, when the agent stays quiet and what the TTS reads aloud.

So the next three and a half weeks belong to re-testing conversations, not editing config.

The general mechanics of surviving model churn (registries, aliases, reversible migrations) are in how a voice AI platform keeps running when the models change under it; this is the specific case. New to how voice agents fit together? Start with the complete guide to AI voice agents.

What retires, and where

The 17 November date belongs to the Gemini Developer API. Its deprecations page, last updated on 22 October, calls these the earliest possible shutdown dates. Plan on them anyway.

• gemini-3.1-flash-live-preview, replaced by gemini-3.8-live
• gemini-2.5-flash-native-audio-preview-12-2025, replaced by gemini-3.8-live
• gemini-2.5-flash-preview-tts, gemini-2.5-pro-preview-tts and gemini-3.1-flash-tts-preview, replaced by gemini-3.8-flash-tts or gemini-3.8-flash-lite-tts

Other surfaces keep their own calendars:

• Vertex AI. The native-audio Live model there, gemini-live-2.5-flash-native-audio, is listed for retirement on 13 December 2026.
• Cloud Text-to-Speech. Its Gemini-TTS models, such as gemini-2.5-flash-tts and gemini-2.5-pro-tts, carry no retirement notice as of this week. Google also says the 3.8 TTS models aren't offered through the Cloud Text-to-Speech API; they're in preview through the Gemini Enterprise API.
• Not Google, same month. Sarvam ends Bulbul V3 in its hosted Voice Agents product on 10 November. Its changelog is explicit that this applies to Voice Agents only: Bulbul V3 stays on the Text-to-Speech API.

Get this split right first. Our Live integration stores Developer API model IDs in the registry and resolves them to Vertex publisher IDs when a call's agent is built, so our 2.5 native-audio deadline is the Vertex one. Our pipeline's Gemini TTS engine calls gemini-2.5-flash-tts, which isn't on the 17 November list.

A vendor should be able to tell you which date applies to each of your agents in one sentence.

Then confirm the replacement actually serves you. Gemini 3.8 Live was listed on 15 September. Three days later, opening a Live session on it through the Vertex endpoint our projects use still returned "publisher model not found". A model on a docs page and a model accepting sessions in your project and region are separate events.

The defaults that flip

The trap is assuming a successor is a superset. Gemini 3.1 Flash Live had no proactive audio, no affective dialog and synchronous tools only. 3.8 Live doesn't restore the 2.5 options as choices: it makes one mandatory, removes another and flips the tool default. Flags copied from the predecessor will be wrong.

Coming from 2.5 native audio, you cross two generations at once, and Google's 3.8 Live page documents migration from 3.1 Flash Live only. Our registry keeps an explicit flag per capability for each Live model, read by the runtime, the API and the agent builder, so a flip like this is a reviewable diff, not a hunt through code.

Tools run in the background unless you say otherwise

On 3.1 Flash Live, Google's docs are blunt: the model will not start responding until you've sent the tool response. On 3.8 Live, non-blocking execution is the default, and you mark a function declaration as blocking to keep the old behaviour.

When a background result comes back, a scheduling value decides what happens: interrupt (stop and report it now), when idle (finish the current sentence first) or silent (use it later without announcing it).

On a phone call you can hear the difference. A background lookup lets the agent keep talking: "While I pull that up, is the delivery address still the same?" A background write lets it say "you're booked for Thursday" before the booking exists, or take the caller's next answer while the result is still in flight.

Our Gemini native-audio integration has run tool calls synchronously, with no audio until the tool returns. For us, as for anyone coming from 3.1 or a synchronous 2.5 setup, choosing per tool is new work. OpenAI reached the same shape another way: GPT-Live hands tools and reasoning to a separate backend model, as we described in the delegation pattern.

Proactive audio is always on

Proactive audio lets the model decide not to respond when it judges the input irrelevant. On 2.5 native audio it was opt-in, and we left it off by default. On 3.8 Live it's permanently enabled, and sending it as off returns an error.

On a phone line that sounds helpful: a television, someone else in the room, the caller speaking to a colleague. The risk is the other side. A quiet "yes" under traffic noise, a "hello?" to check the line, or an answer in an unexpected language can be judged irrelevant too, and then the caller hears silence.

Silence watchdogs catch some of this. Ours nudge a caller who goes quiet mid-call, and a second one recovers if the agent itself stops talking. Re-test on real line audio and count how often they fire: a watchdog firing every few turns is a symptom, not a fix.

Settings that used to work now fail

Three settings that 3.1 or 2.5 accepted are gone:

• Thinking control. 3.1 Flash Live took a thinking level, minimal by default; 2.5 native audio took a thinking budget. 3.8 Live interleaves its reasoning, and Google says to leave thinking configuration out of session setup.
• Proactive audio off. An error now, as above. Remove the field.
• Affective dialog. Removed from the API. Delete the setting.

Two quieter changes ride along. Output is audio only, so switch on output audio transcription if your transcript depends on the model's text. And turn coverage now includes all video frames by default, which matters if an in-app or browser agent streams a camera.

Gemini 3.8 Live Extended Thinking is not the named replacement. It runs tools non-blocking only, without scheduling options, and takes thinking levels from low to high. Choose it on purpose, not because the name sounds like an upgrade.

Injected turns now interrupt

One change won't show up in a config diff. On 3.8 Live, a text message your platform sends into the session and marks as completing the turn interrupts whatever the model is generating; one sent without that marker makes the server wait for more.

Platforms inject text mid-call more often than they realise. On our Gemini Live path, the greeting cue, the silence-watchdog nudge and the instruction to close the call all enter the session this way. Each is a point where timing changes: a nudge that lands while the agent is mid-sentence now cuts it off. Audit every injection point, including events pushed from a CRM or payment system.

Which tools should block

Start from the split your platform already uses to decide what's safe to repeat. Our runtime classifies every custom tool from its configuration alone: an MCP tool marked read-only, or an HTTP GET or HEAD, is a lookup, and anything else changes data. That line is the right starting point for the blocking choice.

1. Block anything that changes data. Bookings, payment links, CRM updates, transfers, follow-up scheduling. The agent must not describe an outcome it doesn't have yet. Make write endpoints idempotent anyway: bind the call ID to a tool parameter so a repeated request is harmless.
2. Block lookups the next sentence depends on. Slot availability, an outstanding balance, eligibility. If the agent can't say anything useful without the answer, a background call only produces filler. Pair it with one short hold line so the wait isn't dead air.
3. Run enrichment in the background, when idle. Order history fetched during the greeting, or a customer tier that sharpens a later answer. Nothing the agent says next depends on it.
4. Run bookkeeping in the background, silently. Tags, notes, analytics, quality scoring. The caller should never hear about these. On the synchronous native-audio path we don't register our per-turn conversation-quality tool at all, because a bookkeeping call that holds audio every turn costs more than it reports. A silent background call is the shape it always needed.
5. Interrupt rarely. Keep it for a result the caller must hear now, such as a payment that just failed. It cuts the agent off mid-sentence, which is right only when the news outranks the sentence.

Keep your loop guards whichever mode you choose. With synchronous calls on Gemini Live we've watched the model re-call the same bookkeeping tool with identical arguments after each response, dozens of times in a few seconds, while the caller heard nothing.

The fix was a per-turn cap on bookkeeping tools plus a repeat breaker that answers with an instruction to stop calling the tool and speak to the caller. Non-blocking execution may remove the silence. Nothing in Google's documentation says it removes the loop.

Your TTS prompt may be read aloud

This is the change most likely to produce an audible bug. Gemini 3.8 Flash TTS treats input text strictly as a verbatim transcript. Google's own example: "Say cheerfully: Hello!" is now spoken, instruction and all.

Sustained style and speaker labels move to a separate speech metadata field, momentary sounds and pauses use angle-bracket tags (a laugh, a short pause), and Google recommends designing a voice persona once and reusing its ID instead of long style blocks.

We know where this bites because our pipeline's Gemini TTS engine is built on the older contract. Each request carries a director's-notes block (style, pace, volume) above the transcript. For very short lines it adds a directive to say only the phrase and stop, because Gemini 2.5 Flash TTS, handed a standalone "Got it.", will sometimes "complete" the turn with a run of invented acknowledgements.

On a verbatim-transcript model, every one of those directions is text to be spoken.

Two lessons carry beyond Gemini. First, guards written as prose turn into speech when the contract changes, so a hallucination guard should live in structure as well as wording: batch a short line with the next sentence, and cap audio length against input length.

Second, check the bytes. Unary 3.8 TTS responses come back as WAV with a header, so code that adds its own header will double-wrap, usually heard as a click at the start of each line. For phone audio, Google lists headerless μ-law and A-law output.

The re-test plan

Run it per agent, in this order, before the date that applies to you.

1. Inventory. List every model ID the agent calls (Live, TTS, STT, LLM) and the surface behind each: Developer API, Vertex AI, Cloud Text-to-Speech or a vendor's hosted product. Check each on its own lifecycle table.
2. Probe. Open a real session on the replacement in your project and region, with your voice and language.
3. Re-derive capabilities. Build the replacement's flags from its model page, and remove dead settings: thinking control, proactive audio off, affective dialog.
4. Classify tools. Apply the five rules above to every tool, built-in and custom, and record the decision beside the tool.
5. Audit injections. Find every place text enters the session mid-call and decide whether it should interrupt.
6. Fix TTS requests. Move style and speaker into speech metadata, remove manual WAV wrapping, pick a telephony format, and listen to your shortest lines.
7. Replay real calls. Use phone audio: noisy lines, one-word answers, barge-in, a voicemail greeting, a transfer, a booking. Compare transcripts with the current model and look for any confirmation spoken before its tool returned.
8. Move a few agents first. Watch voice-to-voice latency, tool time, silence nudges, hang-ups during tool waits and booking or transfer success before moving the rest.

Give language its own pass: the 3.8 Live model page doesn't list supported languages. Our Live setup pins the voice's locale to the agent's primary language (Indian English, say) so even the greeting doesn't drift to a generic US accent. Confirm the replacement honours that before an Indian-language campaign runs on it.

What this means if you're buying, not building

You shouldn't need to know any of this to run good calls. Ask your vendor four questions and expect short answers:

• Which model and which surface does each of my agents use, and what's the retirement date on that surface?
• Which of my tools block on 3.8 Live, and which run in the background?
• On the date, are my agents repointed automatically, pinned until I approve, or left to fail?
• Can I compare a few agents on the new model before everything moves?

Not every agent should make this move. If an agent's job depends on exact wording, such as a regulated disclosure or an amount read back, a speech-to-speech model was already a weak home for it: on that path the model is asked to say a line rather than guaranteed to.

Use the migration to move that agent to the pipeline instead. We set out how to choose per call type in speech-to-speech vs pipeline voice AI.

And if your Live traffic runs through Vertex, your date is 13 December. Don't squeeze an untested migration into a deadline that isn't yours.

The model ID is the easy part. Tool timing, silence and spoken prompts are where a migrated agent breaks, and they only show up on real calls. To see how Callaro lets you choose and change models per agent, start with models and languages.