Gemini 3.8 Live is generally available, but migrating a voice agent is not just a model-name change. Default asynchronous tools and Extended Thinking’s separate interaction lifecycle mean that a finished utterance is not proof of a finished business action. Before connecting write-capable tools, separate audio playback, model activity and backend transaction state—and test what happens when the user says “stop” after dispatch.
What changed in Gemini 3.8 Live
On 15 September 2026, Google announced Gemini 3.8 Live and Gemini 3.8 Live Extended Thinking. The Gemini API release notes identify both audio-to-audio models as generally available. The announcement describes real-time visual context, language switching and background tool execution while the conversation continues. These are vendor-described capabilities, not a production acceptance result for your workflow.
The two API identifiers are gemini-3.8-live and gemini-3.8-live-extended-thinking. Google positions the first for low-latency dialogue and the second for more complex background reasoning. This article focuses on developer integrations, not an assumption that every Gemini app or Workspace account receives identical functionality at the same time.
The operational change is concrete. The 3.8 Live migration page says asynchronous function calling is now the default. Explicit BLOCKING tool declarations remain available for compatibility. That differs from the older 3.1 Live documentation’s sequential-only tool behavior. Extended Thinking requires non-blocking tools. A client that previously used conversational pauses as a rough proxy for work in progress needs an explicit state contract.
Access, pricing and the boundaries still to verify
Access is through the Gemini Live API; Google also describes rollout across its application ecosystem. The API’s available-regions page includes Germany. Country eligibility is not a guarantee of model-specific capacity in your project, a particular enterprise contract or EU-only processing. Confirm the endpoint, account entitlement, quota and data-handling terms for the route you will actually deploy.
On 16 September 2026, direct retrieval of the Developer API pricing page showed both new models in a shared rate section: per million tokens, paid-tier input is $0.75 for text, $3.00 for audio and $1.00 for image/video; output, including thinking tokens, is $4.50 for text and $12.00 for audio. Google also lists audio equivalents of $0.005 per input minute and $0.018 per output minute. These are modality rates, not a fixed price per wall-clock conversation minute. Search grounding and external services can add charges. The page marks product-improvement data use as Yes for the free tier and No for the paid tier; review the applicable terms rather than treating a free test as an approved enterprise data route. These are hosted models, not an announced open-weight package for self-hosting.
Evaluate cost per accepted business outcome, including spoken progress updates, unsuccessful sessions, tool execution and human handoff. A lower perceived response delay can coexist with a longer transaction and a larger bill. This is an accounting design recommendation, not a measured cost comparison between the two new models.
Extended Thinking changes what “done” means
Google’s Live API thinking guide makes the distinction explicit: for standard 3.8 Live, turnComplete: true closes a turn. For Extended Thinking, it can finish an intermediate utterance while the interaction remains IN_PROGRESS. The client must track interaction_status—shown as interactionStatus in wire examples—and return the conversational interface to idle only on IDLE.
Neither signal should be promoted into your authoritative business-transaction status. An acknowledgement such as “Let me check that” is not an order receipt. Even an idle model cannot replace the receiving system’s evidence that a reservation was committed, rejected or cancelled. Persist a business operation identifier independently of the audio session and the provider’s tool-call identifier.
A useful implementation has three independent records. The playback record tracks buffered, playing or interrupted audio. The model-interaction record tracks the provider’s current lifecycle. The operation ledger tracks proposed, awaiting approval, dispatched, committed, cancellation requested, cancelled or outcome unknown. Those operation states are a proposed application design, not Gemini API enum names.
For example, a service-desk assistant starts booking a technician. The caller interrupts: “Stop—use the other site.” Stop obsolete audio immediately, but do not report the booking cancelled merely because generation stopped. If dispatch has not happened, invalidate the old proposal. If it has, query the booking system, request cancellation when supported and record the result before preparing a replacement. Otherwise the smoother conversation can conceal two valid bookings.
Migration details that deserve a contract test
For standard 3.8 Live, Google says to omit thinking_level or thinking_config; this model does not accept configurable thinking depth. Extended Thinking supports low, medium and high reasoning settings, but not MINIMAL. Its tools must explicitly use NON_BLOCKING; the thinking guide says synchronous blocking declarations return an error.
The model-specific migration page also says that send_client_content is supported throughout the session and that turn_complete=true interrupts active model generation. That statement is about generation, not a documented transactional rollback of your external tool. Do not infer a cancellation guarantee the source does not provide.
Other configuration changes matter during rollout: proactive audio is permanently enabled, proactive_audio: false returns an error, and the affective-dialogue configuration has been removed. Video frames are included by the default turn-coverage setting; send them only when needed. The model page instructs integrations to use audio responses and output transcription when a transcript is required.
There is documentation lag. Some general Live tool and capability pages retrieved for this review still compared 3.1 and 2.5 rather than the new models. The newer model page and thinking guide also use differing scheduling labels. Avoid copying an old example or guessing the correct enum. Pin the SDK, validate the actual model-specific schema and capture a successful setup plus a tool-response trace before production. No executable integration or benchmark is claimed here.
Five acceptance checks before enabling business writes
1. Prove utterance completion is not transaction completion
For Extended Thinking, capture an intermediate utterance ending with turnComplete while the interaction remains in progress. The UI must not show “completed,” close the business ticket or release a second conflicting write. Pass evidence is an ordered trace linking the provider event, UI state and unchanged operation-ledger status. Test the standard model separately rather than sharing an unexamined completion handler.
2. Test interruption on both sides of dispatch
Interrupt before tool dispatch, during execution and after the backend commits but before its response arrives. Require either a confirmed cancellation, the confirmed committed result, or an explicit unknown outcome with handoff. Never turn a stop request into a fabricated success. The approval-gate architecture supplies the authorization boundary; it does not itself cancel a remote write.
3. Prevent a reconnect from becoming a second booking
Disconnect the audio session after dispatch and reconnect with the same business operation. Require the client to reconcile the first attempt before sending another. Reuse a stable idempotency identity where the receiving API supports it, and verify its retention and payload-matching contract. The retry-budget guide explains why lost acknowledgements need reconciliation rather than blind replay. This test concerns the new voice-session lifecycle, not a replacement for that broader retry policy.
4. Keep old results away from new instructions
Change an address or asset identifier while a slow tool is running. Bind the response to the operation and input revision that produced it. A late result must not overwrite the corrected request or trigger a follow-on action under new approval. Show the user what actually happened to the old operation. This adds state and coordination cost; a simpler read-only assistant may be preferable when the business cannot support that control.
5. Measure useful completion, not reassuring speech
Run German utterances, English–German switches, overlapping speech, background noise and ambiguous part numbers against labelled outcomes. Measure first audible acknowledgement separately from verified task completion, cancellation outcome and handoff. Require the agreed latency and cost budgets without sacrificing correctness. Use the segment-specific release-gate method to stop a good aggregate result hiding a weak German or high-consequence cohort. Set thresholds from the business risk; there is no universal safe percentage.
Limits and the rollout decision
The announcement’s benchmark scores do not establish your booking accuracy, factory-noise robustness or safe cancellation rate. The model-specific pages list limitations including no structured-output mode, no built-in code execution and no context caching. Function calling still needs schema validation, authorization and business checks in your backend; fluent speech cannot supply them.
Begin with read-only status retrieval. Add a reversible, explicitly approved action only after the five checks pass. Use standard 3.8 Live when direct dialogue and simple tools suffice; test Extended Thinking when the task genuinely needs background reasoning and the client can represent its lifecycle. Neither choice authorizes direct control of safety-critical equipment. Recording, employee monitoring and data-transfer questions require the responsible privacy and legal reviewers; this is engineering guidance, not legal advice.
For a voice-agent architecture review, bring one recorded test flow, the tool’s cancellation contract and a lost-response example. The useful deliverable is a state-transition contract and an acceptance pack that distinguishes what the assistant said from what the business system actually did.
