Find the expiring model IDs in your voice agent before Nov 17

Most voice agents I see in production aren't one model. They're three or four: a speech-to-text model, an LLM, a TTS voice, often a fallback LLM, sometimes a realtime speech model doing all of it at once. Each one is a string in a config file somewhere.

This month several of those strings got an expiry date. Some of them won't fail when the date comes. They'll keep answering, on a different model.

On a web app you might catch that in a dashboard. On a phone call the caller just hears a slightly different voice, a slower first word, or an agent that suddenly calls tools differently. Nobody files a ticket. They hang up.

So this one is practical: what changed in the first week of November 2026, and a three-step routine to find the affected model IDs in your stack and catch the calls that quietly ran on another model.

What shipped (and what's expiring)

Google Gemini API: two deprecations (Nov 2) and voice remixing (Nov 4). On Nov 2 Google deprecated gemini-2.5-pro and gemini-2.5-flash. From December 1, 2026, requests to gemini-2.5-pro automatically route to gemini-3.8-flash, and requests to gemini-2.5-flash route to gemini-3.5-flash-lite, billed at the new model's rates. Google lists breaking API changes for both moves: stricter validation for function calling and thought signatures, a thinking-level setting replacing the thinking budget, and the removal of some sampling parameters and of prefilled model turns. gemini-2.5-flash-lite is not deprecated. (Gemini API release notes)

The voice-specific part is on Google's deprecations page: the preview TTS models gemini-2.5-flash-preview-tts, gemini-2.5-pro-preview-tts and gemini-3.1-flash-tts-preview have a shutdown date of November 17, 2026 (replacement: gemini-3.8-flash-tts or gemini-3.8-flash-lite-tts). So do the Live API previews gemini-3.1-flash-live-preview and gemini-2.5-flash-native-audio-preview-12-2025 (replacement: gemini-3.8-live). Google notes that dates on that page are the earliest possible shutdown dates. These are listed as shutdowns, not re-routes.

And on Nov 4 Google released voice remixing: you give it a base voice (a prebuilt voice, a library voice or one you designed) plus an instruction like "slightly older, slower pacing", and get back a new stored voice ID that works with both Gemini 3.8 Flash TTS and Flash-Lite TTS. That's timely, because anyone moving off a preview TTS model this month is about to re-check how their agent sounds anyway.

ElevenLabs changelog (Nov 2). A lot in one entry (changelog):

• Default LLM: new agents created without an explicit LLM now use gemini-3.5-flash instead of gemini-2.5-flash. Existing agents are unchanged.
• Staged migrations: gpt-5, gpt-5-mini, gpt-5-nano and their 2025-08-07 snapshots are deprecated ahead of OpenAI's December 11 shutdown, with traffic moving to gpt-5.6-sol, gpt-5.6-terra and gpt-5.6-luna "in steps from 10% on November 11 to 100% on December 6". The fallback ramp for gemini-2.5-flash and gemini-2.5-flash-lite now starts on November 8 instead of November 1, with the November 30 cutoff unchanged. Claude Sonnet 4.5 is deprecated on November 30, replaced by Claude Sonnet 4.6.
• Eleven Realtime for every workspace, finishing a rollout that started on October 19, including connecting an OpenAI Realtime client to the Realtime WebSocket.
• Realtime API behaviour changes: the speech-started and speech-stopped events are now sent once per committed user turn instead of on every pause; each manual commit of the input audio buffer transcribes only the speech since the previous commit; idle audio sessions close after 3 minutes instead of 60 seconds, with a session idle timeout error.

The OpenAI date checks out on OpenAI's side too: its deprecations page lists gpt-5, gpt-5-mini and gpt-5-nano (and their 2025-08-07 snapshots) for removal on Dec 11, 2026.

The common thread: none of this needs you to deploy anything. Your agent changes on the provider's calendar, not yours.

Why phone agents feel this more

Three reasons, all boring, all real:

• Swaps are partial. "10% of traffic on November 11" means for a while some of your calls run on the old model and some on the new one. If one of them handles a tool call or a long policy answer differently, you get a bug that shows up on one call in ten. That's the hardest kind to chase from call recordings.
• Re-routes keep working. A shutdown fails loudly: the request errors, your fallback kicks in or the call drops, and you notice. An automatic re-route to a different model with breaking API changes (function calling, thinking settings, sampling parameters) fails quietly. The call still connects. The agent is just a bit different.
• The caller is the only monitor. A TTS swap changes the voice your callers have heard for months. A different LLM changes how long it takes to produce the first token, and on a phone line that's dead air. There's no UI to show a spinner in.

And the event changes matter if you built logic on top of realtime events. If your agent treated every speech-started event as "the caller is talking again" (to stop playback, or to start a "listening" timer), it now gets that event once per committed turn instead of on every pause. That's probably what you wanted, but it's a behaviour change, so test it rather than assume it.

Step 1: find every model ID you actually use

Model names hide in more places than the main config: environment files, fallback lists, a hard-coded default in a helper, the eval setup, an exported agent definition. A plain text search finds most of them, but a search for gemini-2.5-flash also turns up gemini-2.5-flash-lite (not deprecated) and gemini-2.5-flash-preview-tts (a different deadline). So match whole model IDs: a hit only counts when the name isn't part of a longer one.

Then put every hit in one list, with the date from the provider's own page, what happens on that date (a shutdown or an automatic re-route) and the replacement the provider names, and sort it by deadline. On a small demo agent, the top of that list was the Gemini Live native-audio preview and the preview TTS model (shut down on November 17), then gemini-2.5-flash (re-routed on December 1), then gpt-5-mini (removed on December 11). The fallback set to gemini-2.5-flash-lite correctly stayed off the list.

Make the check repeat itself. If your build fails whenever a model in use is 30 days or less from its date, you'll get nagged until it's fixed.

Two honest limits: the list only knows the IDs you put in it, and if you're on a hosted agent platform that picks the model for you, the ID might not be in your repo at all. That's what step 2 is for.

Step 2: log the model per call, then look for drift

Your config says what you asked for. What matters is what answered. Most APIs report the model in the response, and hosted agent platforms usually expose it per conversation. Record both on every call, next to the call ID: the configured model and the reported model.

Then count, for each configured model, how many calls it handled and how many came back on something else. On a made-up log of 40 calls where every tenth one came back on the new model, that's 40 calls with 4 on another model, or 10%. That number is fake; yours is the interesting one. Once you can see the split, you can compare the two groups on things you already track: time to first audio, tool-call errors, transfers to a human, call length.

(Treat a call with no reported model as drift too. A call where you didn't record the model is a call you can't explain later.)

Step 3: re-listen on the phone leg, not on your laptop

If you're moving off a Gemini preview TTS model, the voice will change, at least a little. Listen to the new one the way callers hear it: 8 kHz, through a real call, ideally on a cheap handset. Studio-quality samples at 24 kHz hide exactly the things that get lost on a phone line, like breathy high-end detail and very fast pacing. If your agent runs on LiveKit, the easy way is to put a real number in front of a test room (a Vobiz SIP trunk on LiveKit is one way to set that up), dial it from your own phone, and listen to both voices side by side.

If the new model's version of your voice is close but off (too quick, too bright), that's where Google's voice remixing is useful: describe the change, get a new voice ID, and pin that ID in your config. I wouldn't promise it recreates the old voice exactly. It's a way to adjust, not a copy button.

What I'd do next

1. Search every repo that touches your voice agent for whole model IDs, including eval setups and agent exports. Fix anything with a Nov 17 date first.
2. Pin explicit model IDs everywhere. Defaults change (ElevenLabs' new-agent default just did), and "whatever the default is" is a different agent every few months.
3. Record the configured model and the reported model on every call, starting today, before the 10% ramps begin.
4. For anything that will auto-route, read the migration guide's breaking changes against your tool-calling setup. A re-route that keeps the call connected but breaks function calls is worse than a clean error.
5. If you use realtime events for barge-in or timers, replay a few recorded turns against the new event behaviour before you trust it.

Voice agents used to break when you shipped. Now they also change when you don't.

Disclosure: I work on the phone-line side at Vobiz, telephony for voice agents (SIP trunks and real numbers under stacks like LiveKit, Pipecat and Vapi), handling 11M+ calls a day, so the phone leg is the part I stare at.

About the author

Piyush Sahoo, Founding Member, Vobiz, writes about where AI voice agents meet the phone network. More at piyushsahoo.me.