Gemini Live and TTS Preview Models Retire November 17: Migration Guide

Gemini's two Live preview models and three TTS preview models will retire on November 17, 2026; Google recommends migrating to the 3.8 series.
Google announced that two Gemini API Live API preview models and three TTS preview models will be officially shut down on November 17, 2026. The official migration path is Gemini 3.8 Live and Gemini 3.8 Flash TTS. Migration is not just a model ID swap; it also involves format adjustments to Live API session configuration parameters and TTS request bodies, and developers need to adapt fields such as audio sample rate, voice activity detection, voice selection, and output format according to the new model documentation. In addition, preview and GA billing may differ, so cost changes under billing by session duration and by character or audio duration need to be evaluated. The article recommends running the complete flow in a test environment before replacing production and performing regression tests on latency, audio quality, and format to avoid service interruptions before the deadline.

Google's Gemini API is cleaning up a batch of preview-stage models. According to the official announcement, two Live API preview models and three TTS preview models will be officially shut down on November 17, 2026. For developers currently using these models to build real-time voice interaction or speech synthesis features, this is a migration that must be handled in advance.
Which Models Are Being Retired?
This retirement involves two categories of models: Live API previews and TTS previews. The Live API supports low-latency real-time audio/video interaction, while TTS handles text-to-speech output. The announcement explicitly lists two Live preview models and three TTS preview models, which will stop serving after the deadline.
Although the original text does not list the complete model IDs one by one, developers can check the Gemini API's model version page to verify whether the model identifiers they are currently using appear on the retirement list. The key point is that these models carry a "preview" label, meaning they never received a stable general-availability commitment and their lifecycle was always limited.
Live API is the interface in the Gemini API for real-time bidirectional interaction. It is built on WebSocket or WebRTC long connections, allowing the model to continuously receive audio/video streams and return voice responses instantly. Typical use cases include voice assistants, real-time translation, and customer service bots. It differs from ordinary single request-response calls in that session state persists for the duration of the connection, so session initialization parameters (such as audio sample rate, voice activity detection thresholds, and context truncation strategy) have a major impact on the experience. TTS (Text-to-Speech) is the interface that converts text to speech, allowing developers to specify voice, speaking rate, and output audio format. Gemini's TTS preview models carry a preview suffix in their naming, indicating that their API contract and model behavior may still change. Google typically does not provide a GA SLA for them and may announce retirement at any time—which is exactly the root cause of this migration.
Alternatives: Gemini 3.8 Live and 3.8 Flash TTS
After retirement, the officially designated migration path is Gemini 3.8 Live and Gemini 3.8 Flash TTS. As the naming suggests, the new models make a version-number leap, and the Flash series typically implies lower inference latency and higher throughput efficiency.
For Live API users, the model ID in the code needs to be replaced with the identifier corresponding to Gemini 3.8 Live. For TTS users, switching to Gemini 3.8 Flash TTS is required. The good news is that the migration mainly involves changing model IDs rather than rewriting the entire API architecture.
Flash is the lightweight series in the Gemini model family aimed at low-latency, high-throughput scenarios. Compared with the Pro series, it is sold on a smaller model size and faster time to first token, making it suitable for response-speed-sensitive tasks such as real-time voice. In TTS scenarios, the Flash version typically means shorter synthesis latency and lower unit cost, but audio quality detail or emotional expressiveness may differ from larger models, so audition-based evaluation is important during migration. GA models for the Live API typically mean more stable session management semantics, clearer concurrency quotas, and billing rules. Note that moving from preview to GA often comes with parameter renames, default value changes, or even field deprecations, so a version jump (such as going directly from a preview to 3.8) is not just a marketing number—it reflects a substantive evolution of the API shape.
Specific Changes to Session Config and TTS Requests
Migration is not as simple as changing a string. The announcement states that the formats of session config and TTS requests will be adjusted. This means developers need to check two places in their code:
- Live API session initialization parameters: The new models may have new requirements or defaults for configuration fields such as audio sample rate, voice activity detection, or context window.
- TTS request body: Voice selection, output format, or rate parameters may change and need to be adapted according to the new model documentation.
It is recommended to first run the complete flow with the new models in a test environment, then gradually replace production configurations to avoid service interruptions before the November 17 deadline.
Price Changes: Do the Math Before Migrating
The announcement mentions a comparison of prices before and after migration. Preview models often have trial-period pricing or free quotas, while GA models (especially the 3.8 series) may have different billing standards. Developers need to watch two dimensions: whether Live API billing by session duration changes, and whether TTS billing by character or audio duration changes.
If the new models' unit prices are higher than the old preview versions, it is necessary to estimate call volume in advance and optimize request frequency. Conversely, if the Flash series brings cost reductions, this migration is also an opportunity to optimize the bill.
Billing by session duration is the typical model for the Live API: the billing unit is usually seconds or minutes the connection is maintained, rather than tokens, because real-time audio streams are difficult to meter precisely by token. This means that even if the user is silent, charges may accrue as long as the connection remains open. Optimization strategies include promptly closing idle sessions and setting server-side timeouts. TTS billing commonly uses either input character count or output audio duration, and some services apply different unit prices for different quality tiers (such as standard quality and high-fidelity quality). When evaluating migration, remove the old preview version's free quota or trial discount, compare real call volume multiplied by the new unit price, and watch for hidden cost items such as minimum billing duration and concurrency limits introduced by the new models.
Code Change Checklist
Overall, the work is concentrated in three areas:
- Model ID replacement: Update the Live and TTS model identifiers to the 3.8 versions.
- Request structure adaptation: Adjust session config and TTS request fields according to the new model documentation.
- Regression testing: Verify that real-time interaction latency, speech synthesis audio quality, and format meet expectations.
This retirement is a reminder to developers: preview models are good for quickly validating ideas, but relying on preview versions in production always carries the risk of service discontinuation. Planning the migration in advance is far safer than scrambling to switch before the deadline.
Related articles

WorkBuddy Full Guide: How an AI Coworker Takes Over Workplace Automation
What is WorkBuddy? This article analyzes the core capabilities of this full-scenario AI agent: autonomous execution with deliverable results, local file processing, multi-agent parallelism, and workplace automation workflows, helping you judge its essential difference from ordinary AI chat tools.

The Truth About AI Agents: A Hundred Lines of Code + an LLM, Deconstructing the Agent's Underlying Logic
AI agents aren't a new AI species—just a language model plus tools, a loop, and a goal. Here's the underlying logic: how 100 lines of Python hit a 75% fix rate, why the harness beats the model, and Gartner's "agent washing."

AI Agent Deployment: Three Things Developers Should Do
AI Agent deployment doesn't require rushing into multi-agent systems. This article outlines an actionable deployment path and engineering acceptance thresholds for developers, covering human baselines, bounded single-agent scope, and a controlled code-modification loop.