The proposed announcement is not confirmed by the available sources
The premise that Gemini 3.8 Live and Gemini 3.8 Live Extended Thinking were released on September 15, 2026 requires an announcement source or release notes that explicitly identify the models, their date, and their availability status. That material is not included among the verified sources provided for this article. It is therefore not possible to state as fact that both identifiers are generally available, that the date is correct, or that they replace an earlier Live model.
The sources do cover relevant aspects of the Live API: the exchange between the client and tools, the use of identifiers to associate a call with its response, non-blocking tool behavior, and the specifics of reasoning in the API. Those mechanisms are sufficient to define a prudent integration review, but not to validate model names, pricing, regions, model-specific quotas, or lifecycle commitments on their own.
The practical consequence matters. A team should not promote a migration based only on an interpretation of a launch description. It must verify in its own project that the identifier is accepted, that it has effective access, that observed behavior matches the documented contract, and that the applicable cost, data, and security policies remain valid.
Why an asynchronous tool changes the operating model of a voice agent
In a voice conversation, the model producing audio is not equivalent to a business operation being complete. A tool call may need to check inventory, create a booking, open a case, or request confirmation. If that call does not block the conversation, the agent can keep assisting the user while the external system is still working.
The Live API tool-use documentation describes a protocol in which the function call includes an identifier and the client returns a function response linked to that interaction. It also documents the non-blocking mode, called `NON_BLOCKING`, and options for planning how a tool response is incorporated into the flow. The client application remains responsible for performing the external action, retaining the necessary context, and sending the corresponding response.
This requires conversational language to be separated from transactional reality. The assistant may say that it is checking a request; that must not be recorded as a confirmation. Likewise, a late tool response should not automatically become a new utterance if the user cancelled, changed topics, or the session has already been reconciled after a reconnection.
States that should be modeled separately
| State | What it represents | Risk if confused with another state |
|---|---|---|
| Audible or textual output | What the user may have heard or received during the turn. | Treating a provisional sentence as a business confirmation. |
| Session turn | The conversational progress the client has received and retained. | Replaying or losing context when resuming a connection. |
| Pending tool call | An identified request whose execution or response has not yet been closed. | Running an action twice because of a retry or reordered events. |
| Confirmed external effect | The result verified in the business system or provider. | Claiming success before there is evidence of the effect. |
Reasoning, session content, and events: what requires careful reading
The Live API reasoning documentation distinguishes operation with background reasoning from intermediate utterances and describes interaction-status fields, including `interaction_status`. It also warns of specifics in end-of-turn signaling. For the extended-thinking model described in that documentation, tools must be configured as non-blocking.
This does not allow one to infer that every intermediate output is a final decision or that `turnComplete` has the same operational meaning in every configuration. A robust client must process events according to their type and state instead of turning every received fragment into definitive history, audible confirmation, or a trigger for an external action.
The proposal also attributes full client session-content updates to the models. The supplied sources are not enough to confirm that specific formulation or an official reconciliation rule after reconnection. Even so, reconciliation risk exists in any integration that maintains local state: the client needs to define which version of the conversation it retains, how it detects duplicates, and what it does when it receives data belonging to a previous turn.
Minimum process for reconciling a session and its tools
- 01Assign an internal identifier to the session and to every turn that may originate an external action.
- 02Store the received function call, including its identifier, name, normalized arguments, timestamp, and local status.
- 03Perform the operation with an idempotency key in the external system whenever that system allows it.
- 04Link the function response to the original call identifier and record whether it arrives after an interruption, a turn change, or a reconnection.
- 05Before announcing an irreversible success, verify the effect in the relevant system of record.
- 06Maintain an explicit decision for late results: notify, exclude from the conversation, request confirmation, or open an operational review.
Predictable failures that must be included in regression testing
Interruptions are the first critical case. The user may speak while the agent is responding, cancel the original intent, or begin another request while a tool continues to run. The test is not limited to checking that audio stops: it must demonstrate that no nonexistent success is communicated and that an operation already started is not duplicated.
Reconstructions and retries create a second problem. An application may send a request again because it does not know whether the remote service received it, or it may receive a response after connectivity is restored. Without identifier-based correlation and idempotency at the destination, a booking, payment, cancellation, or update can run more than once.
Out-of-order results must also be tested. A slow tool can respond after a more recent request from the same user. Arrival order must not replace the causal relationship between the turn, the call, and the result. In regulated systems or systems with sensitive effects, the trace must make it possible to reconstruct who requested an action, which arguments were sent, which system executed it, and what outcome was confirmed.
Test suite before production
| Scenario | Expected check | Evidence to retain |
|---|---|---|
| Interruption during a pending call | The conversation can continue or stop without turning pending work into an automatic confirmation. | Turn and function identifiers, interruption marker, and decision applied. |
| Retry after a network outage | The external effect is not duplicated. | Idempotency key, destination response, and final status. |
| Late response | The result is associated with the original call and follows an explicit policy. | Send and receipt times, relationship to the turn, and reconciliation action. |
| Two similar actions | Each retains its own identifier and arguments. | Correlation map and separate results. |
| End of turn with reasoning | The client does not interpret partial signals as transactional closure. | Received events, interaction status, and final operation state. |
Migration checklist: what to validate in the project, not only in the documentation
First, verify actual access to the model identifier you intend to use and document the environment, region, account, and SDK version used for the test. Then run a reference conversation without tools and another with a non-blocking tool, comparing transcripts, events, timestamps, and internal states. The purpose is not to measure a subjective impression of the voice, but to identify contract changes that affect the application.
Second, define what cancellation means at each layer. It may mean that the user stops hearing a response, that the client stops waiting for a tool, that a remote request is cancelled, or that an external system reverses an operation. These actions are not equivalent. If there is no documented and available operation to cancel remote execution, the team must treat that limitation as a product risk and design operational compensations.
Third, measure the full experience. Useful latency includes intent detection, the exchange with the tool, external confirmation, and the response to the user. Also record errors, abandonments, compensated operations, and discrepancies between what the user heard and what remained in the system of record. None of these metrics can be inferred from documentation; they require testing with the organization’s domain, services, and data.
Finally, review the usage limits currently in effect for the project. The rate-limits documentation explains that they are managed by project and expressed through metrics such as requests, tokens, and daily requests, as well as usage tiers. Specific values can vary and must be checked in the current information for the model and account, rather than assumed from an isolated test.
Production-promotion criterion
- 01Complete tests for interruption, reconnection, duplication, late responses, and changes of intent.
- 02Demonstrate idempotency or a compensation mechanism for every tool with external effects.
- 03Verify that traces relate the session, turn, function call, response, and business effect.
- 04Set alerts for late responses, state discrepancies, tool failures, and increased latency.
- 05Obtain a security, privacy, and compliance review for audio, transcripts, tool arguments, and logs.
- 06Promote gradually and maintain a path to revert to prior behavior.
What remains uncertain and what is worth monitoring
With the supplied sources, it is not possible to establish a verifiable comparison between Gemini 3.8 Live and Gemini 3.8 Live Extended Thinking beyond the reasoning and tool characteristics described by the general Live API documentation. Nor can the claim that asynchronous behavior is mandatory by default for both alleged models be confirmed. The documentation does distinguish the requirement for non-blocking tools in the extended-thinking mode it describes.
There is also insufficient evidence concerning audio quality in a particular domain, the accuracy of tool decisions, cost per resolution, action security, regional availability, data retention, or suitability for sector-specific obligations. These are deployment decisions, not conclusions that a technical note can settle on its own.
Before treating this change as availability news, it is advisable to add an official source that confirms the announcement and the exact identifiers. Until then, the operational value of the available documentation is in preparing a resilient integration: separate conversation from transaction, use consistent correlation, assume late results may occur, and require external confirmation before declaring an action complete.
Open questions
- No release note or official announcement was provided that confirms the Gemini 3.8 Live and Gemini 3.8 Live Extended Thinking names, their release date, or their general availability.
- The supplied sources cannot confirm that asynchronous calls are mandatory default behavior for both cited models.
- The provided material does not document pricing, regions, model-specific limits, a remote-cancellation operation, or a specific reconciliation rule for complete session content.
- Each integration’s response to an interruption also depends on the external tool and on the policy implemented by the client.
Keep exploring
Sources consulted
Corrections and transparency
If you spot incorrect or outdated information, send us a correction with the page and source we should review.
Submit a correction