Gemini 3.8 Live Extended Thinking Makes “Done” a Three-Clock Problem

Google has released Gemini 3.8 Live and Gemini 3.8 Live Extended Thinking as generally available developer endpoints. The obvious reading is that Google has added a deeper reasoning option to its voice stack. The more consequential engineering change is in the interaction contract: with Extended Thinking, the model can finish an utterance while reasoning and tool work continue in the background.

In other words, the moment an agent stops talking is no longer the moment its work is done. A spoken “I’ll check that” may be followed by more speech, a tool call, another progress update, and eventually an idle signal. Even that idle signal does not prove that a reservation, refund, transfer, or support-ticket change committed in the system that owns the record.

Voice-agent teams now need three separate clocks: speech completion, interaction completion, and business-action completion. Collapse them into one boolean and a pleasant conversation can hide stale work, double execution, or a confident confirmation for an action that never happened. Keep them separate and Gemini 3.8 Live Extended Thinking can serve as the model interface inside an application runtime for continuous conversation around asynchronous work.

Google did not invent asynchronous voice tools this week; the Live API supported asynchronous function calling in 2025. The release matters because the deeper reasoner makes that asynchronous lifecycle central to how the model speaks and works. The builder question is therefore not “Does it sound human?” It is “Can the application prove what is still running, what finished, and what actually changed?”

Two Live models, two orchestration contracts

The names invite a simple fast-versus-smart comparison. The APIs are less interchangeable than that. gemini-3.8-live has interleaved reasoning but no configurable thinking level. gemini-3.8-live-extended-thinking exposes low, medium, and high background reasoning and changes what completion means. Both are Stable model IDs, and Google’s September 15 API changelog labels both generally available.

The shared “3.8” label can also mislead. The audio model card identifies Gemini 3 Pro as the underlying model, while the previously released Gemini 3.8 Flash is a text-output model that does not support the Live API. This is a follow-up to RohitAI’s analysis of Gemini 3.8 Flash, not a voice wrapper around the same endpoint.

Both new models accept text, images, audio, and video, with 131,072 input tokens and 65,536 output tokens. Native response guidance is audio-first; applications that need text should use output-audio transcription rather than assume an arbitrary text-only Live response. Visual context is sampled, too: the Live capabilities guide documents JPEG or PNG frames at up to one frame per second. “Sees video” should not become a promise of frame-perfect observation.

Availability needs equally precise language. Developers can use both models in the Gemini API and AI Studio now. Google describes enterprise access as private preview, with broader Customer Experience and Workspace business support coming later; consumer rollout spans different Search, Gemini, Docs, Gmail, and Keep surfaces. Developer API GA is not the same claim as universal enterprise availability.

Google’s own model card keeps the launch-day claims in perspective: it acknowledges hallucinations and occasional slowness or timeouts. Its frontier-safety discussion also draws on Gemini 3.7 Flash evaluations, based on Google’s assessment that the audio models add no materially different frontier capabilities. That is a vendor assessment, not an independent certification. The endpoints may be GA; multilingual accuracy, tail latency, and interruption safety in your workload remain unproven until your own traces say otherwise.

The three clocks behind every useful voice action

Speech completion is a user-experience signal. Interaction idle is a runtime signal. An authoritative receipt is the business truth.

Extended Thinking makes the first two clocks visibly different. Google’s Live thinking guide says turnComplete: true can finish an utterance while the server continues emitting audio or tool calls. Clients are expected to keep receiving events and use interaction_status—IN_PROGRESS versus IDLE—to manage the overall interaction.

1. Utterance clock. Did the current spoken segment end? This drives audio playback, barge-in, captions, and turn-taking.

2. Interaction clock. Is the model still reasoning, narrating progress, or waiting to issue another tool call? This drives “working” UI and stream consumption.

3. Business clock. Did the external system commit the intended effect, and can the application show a durable receipt? This drives truth, retries, and reconciliation.

Only the first two are model-protocol states. The third belongs to the application and the authoritative service. A voice model can become idle after handing off a call that times out, returns an ambiguous result, or commits after the user changes their mind. That is why an agent ledger needs request, tool, receipt, and outcome records even when the conversation layer is managed for you.

// Application-level pseudocode
utterance.status   = speaking | complete
interaction.status = in_progress | idle
action.status      = requested | authorized | dispatched |
                     committed | cancelled | unknown

const needsReconciliation =
  action.status === "dispatched" || action.status === "unknown"

if (interaction.status === "idle" && needsReconciliation) {
  // The model is done. An outstanding operation still needs a receipt.
  reconcile(action.operationId)
}

This state machine is not ceremony. Imagine a caller changing a flight while a fare check runs. The model says it is looking, the caller switches dates, and the first request later returns. If both requests share an unversioned callback, the stale result can overwrite the new intent. If a retry lacks an idempotency key, an uncertain timeout can turn into two purchases.

Interruption is a coordination problem

Both models let clients send content throughout a session, and sending client content with turn_complete=true interrupts active generation. That is useful for natural barge-in. It is not evidence that an already queued or running external tool was cancelled, and Google’s documentation does not promise rollback or exactly-once external effects.

The safe design is to make correction explicit. Assign every interpreted intent a monotonically increasing version. Attach that version and an idempotency key to effectful calls. Suppress a stale read result from the conversation, but never discard a mutation receipt: record it, reconcile the committed effect, and use an explicit cancellation or compensating operation where policy allows. If a write times out with an unknown outcome, query the system of record before retrying. A stopped voice buffer should never be your cancellation protocol.

• Separate read tools from write tools. A stale restaurant search can be discarded; a stale booking needs cancellation or reconciliation.

• Bind confirmation to exact parameters. “Yes” should authorize one visible itinerary, amount, and clearly identified account—not a moving conversational summary. The server should bind that approval to one immutable operation ID and its idempotency key.

• Record every transition. Requested, authorized, dispatched, committed, cancelled, and unknown are operational states, not prose in a transcript.

• Keep listening after speech ends. An Extended Thinking client that closes on the first turnComplete can lose later progress, tool calls, or results.

The tool contract reinforces this design. Extended Thinking accepts only NON_BLOCKING function declarations. An application built around synchronous callbacks cannot treat migration as a model-name replacement. The base model retains an explicit blocking compatibility mode; Extended Thinking does not.

The benchmarks argue for routing, not upgrading

The early independent numbers tell a more useful story than “Extended Thinking wins.” In the Artificial Analysis speech-to-speech snapshot, the High configuration is much stronger on difficult grounded tasks, while base Live is preferred in conversational measures. These are benchmark-specific point estimates—not a controlled production trial—but the direction is consistent enough to shape an eval plan.

ServiceNow’s EVA framework separates accuracy from experience and shows the same basic tension in its current clean-data pass@1 rows: Extended Thinking High scores 54.8% on EVA-A versus 45.9% for base Live, while base Live scores 88.6% on EVA-X versus 73.7% for Extended Thinking. Different composites, judges, and harnesses mean the numbers should not be blended into one score. Their disagreement is the insight.

Extended Thinking is not an upgrade button; it is a routing decision. A language-practice companion, receptionist, or fast lookup flow may gain more from conversational timing and lower work per turn. A troubleshooting agent coordinating several systems may gain more from deeper reasoning and background tools. An irreversible financial or booking action needs the stronger application control plane regardless of model choice.

Route at a workflow boundary, not halfway through an active call on hope alone. Preserve structured task state outside the model session, then start the selected route with the facts it needs. A shared product name does not guarantee that an in-place endpoint swap preserves reasoning state, pending tools, or media context.

Same rate card, different realized cost

Google lists both Live variants at identical Standard rates. That makes Extended Thinking look free. It is not. The tariff is the same; the quantity of billable work can differ. Thinking tokens are included in output billing, transcription adds text-output charges, proactive listening bills input throughout the listening period, and the active accumulated context is processed again as a conversation grows. Google’s Live pricing table is the start of a cost model, not the end.

Artificial Analysis measured a benchmark-normalized cost of roughly $3.50 per hour of input audio for Extended Thinking High and $0.84 for base Live. That is not a provider quote for a one-hour phone call: the publisher normalizes a fixed Big Bench Audio workload. It does, however, illustrate the point that equal unit prices do not force equal workload bills.

realized_cost_per_verified_outcome =
  (live_media
   + replayed_context
   + thinking_and_output
   + search_and_external_tools
   + retries_and_recovery
   + human_review)
  / verified_successes

That denominator matters. A higher-reasoning route can be cheaper if it avoids retries and resolves more hard cases; it can be wasteful if it narrates and thinks through easy ones. This extends RohitAI’s argument that model orchestration is a spending policy: measure cost per accepted, verified result, then set per-workflow budgets for reasoning, tool calls, wall time, and context.

Long calls turn memory into an economic control

Voice sessions accumulate expensive context because audio history remains active. Google’s best-practices guide says each turn rebills the active accumulated context and notes that transcription is an additional text-output charge. Both 3.8 models also have proactive audio permanently enabled, so a quiet but open listening window is not necessarily a free one.

Context compression can trim that growing window. Treat it as both a memory policy and a cost policy. Compress too late and old audio keeps inflating later turns. Compress carelessly and the assistant may lose a spelling, account identifier, consent boundary, or correction that still matters to the transaction. The durable answer is to keep authoritative task state outside the audio window, then rehydrate only the facts the current step needs.

Transport continuity is a separate layer again. Google’s session-management guidance gives generic limits of 15 minutes for audio-only sessions and two minutes for audio-video without compression, with connections around ten minutes and resumption handles valid for two hours after termination. Context compression manages retained model context; session resumption carries conversation state onto a new connection; neither is an exactly-once transaction log.

• Connection ID: which WebSocket is carrying frames right now.

• Session ID: which model conversation and compressed context are active.

• Intent ID: which version of the user’s request is current.

• Action ID: which external mutation must be reconciled exactly once from the product’s point of view.

Do not overload one identifier for all four. A reconnect should not create a new purchase; a new user intent should not inherit an obsolete tool result; a compression event should not erase the external receipt.

A migration checklist for real applications

The release-day example repository changed its default to gemini-3.8-live and removed the default thinking configuration. That small diff captures the migration risk: old session setup can be invalid even before application semantics are considered. Audit the contract, not just the model string.

• Choose the endpoint intentionally. Remove thinking_config for base Live; use only low, medium, or high for Extended Thinking.

• Remove obsolete switches. Setting proactive_audio: false errors on the new models, and the base migration guide removes the older affective-dialogue flag.

• Audit every function declaration. Extended Thinking requires non-blocking tools and does not support function-response scheduling.

• Consume the full event stream. Treat turnComplete as utterance completion and interaction_status: IDLE as model-interaction completion.

• Keep privileged execution server-side. The browser or mobile client can carry ephemeral media access; authorization and effectful tool calls belong behind your policy boundary.

• Persist task truth outside the model. Store intent versions, approvals, tool requests, receipts, and reconciliation state in a durable ledger.

• Plan for GoAway and compression. Exercise reconnects while reasoning and tools are in flight; do not assume transport recovery restores application effects.

• Meter complete calls. Capture media, context replay, thinking, audio output, transcription, Search queries, external-tool fees, retries, and human review.

The eval harness should reward verified resolution

A demo rewards the first smooth interaction. A deployment lives in the tail: background noise, accents, code-switching, corrections, timeouts, duplicate callbacks, and the one tool result that arrives after the caller hangs up. Google says the models can switch among 97 languages, but language availability is not evidence that names, addresses, amounts, or identifiers survive every locale and acoustic condition.

Public benchmarks are valuable starting points. tau-Voice tests grounded tasks with overlapping speech and audio perturbations, while EVA covers 213 scenarios across three enterprise domains and separates accuracy from conversational experience. Their simulators, automated judges, and data scope are part of the result. Sierra’s public methodology is English-focused and uses synthesized personas, so a multilingual product still needs its own purpose-recorded or consented test audio.

1. Stratify the workload. Keep easy conversational turns, single-tool reads, hard multi-step work, and irreversible mutations in separate buckets.

2. Replay realistic audio. Vary accents, noise, pauses, interruptions, code-switching, names, numbers, and weak connections.

3. Inject lifecycle failures. Disconnect during reasoning; return a tool result after correction; time out after an external commit; duplicate a callback; compress before a critical fact is reused.

4. Verify against systems of record. A judge saying the answer sounds correct is not enough for bookings, tickets, payments, or account changes.

5. Repeat hard cases. One successful run proves little. Record variance and p50/p95 behavior under load.

Instrument at least six times: user speech end, first audio, first substantive answer, first tool dispatch, external commit, and verified completion. Add interaction idle, but do not substitute it for the last two. Then report task success, policy adherence, entity fidelity, interruption recovery, stale-result rejection, cancellation correctness, and realized cost per verified outcome.

This also prevents a perverse optimization. Extended Thinking can emit early audio and narrate progress, which can improve perceived responsiveness even when time to resolution stays flat. If the dashboard tracks only first audio, filler wins. Track first useful information and authoritative completion, and narration has to earn its place.

Three predictions for voice-agent product design

My first prediction is that voice interfaces will split their status model. “Listening” and “speaking” will remain, but serious products will add “working,” “waiting for approval,” “committed,” and “needs attention.” Extended Thinking makes the missing states impossible to ignore because progress can continue after an utterance ends.

My second prediction is routing by error economics. Teams will keep a conversation-first path and escalate only workflows where deeper reasoning improves verified completion enough to justify extra work. The split may happen by queue, intent, or workflow—not necessarily by user-visible model choice.

My third prediction is that long-call memory becomes product infrastructure. The team that preserves critical structured facts, limits replayed audio, and reconciles work across reconnects can deliver a cheaper and more trustworthy agent even with the same model. The moat moves from voice polish toward state discipline.

Quick answers

Are Gemini 3.8 Live and Extended Thinking generally available?

The two Developer API model IDs are Stable, and Google’s API changelog marks them GA on September 15, 2026. Enterprise and consumer product access has its own staged rollout, so check the exact surface and account rather than generalize from API status.

Is Extended Thinking always better than base Live?

No. Current benchmark-publisher data favors Extended Thinking High on difficult audio and grounded tool tasks, while base Live scores better on measured conversational dynamics, preference, first-audio latency, and normalized workload cost. Evaluate by task class.

Do the two models have the same price?

They have the same published Standard token rates. The realized bill can differ because reasoning output, response length, accumulated audio context, transcription, listening time, Search queries, external tools, and retries vary by workload.

Does turnComplete mean an action finished?

Not for Extended Thinking. It can mark the end of one utterance while the interaction remains in progress. Even interaction_status: IDLE only says the model interaction is idle; an effectful business action still needs an authoritative receipt and reconciliation policy.

The useful way to read Gemini 3.8 Live

Google’s launch is not simply “voice, but smarter.” It moves the boundary of a voice turn. Speech can be a progress channel while reasoning and tools remain active, which makes a voice assistant feel less like a sequence of recorded answers and more like a continuous agent runtime.

That power comes with a stricter engineering obligation. Use base Live where conversation quality and speed carry the product. Use Extended Thinking where deeper work earns its extra runtime. For both, separate what the agent said, what the model finished, and what the business system proved.

The best voice agent will not be the one that says “done” most naturally. It will be the one that knows which kind of done it means—and can produce the receipt.