Wed, 4 Nov 2026
Programming

Gemini 3.8 Live reaches developers with conversation that continues during tool calls

Google's September 15 release adds new voice-model options to its API. Fluent dialogue and a correctly completed application task remain separate measures of success.

Osamah Ismail · Founder & Editor-in-Chief
· 2 min read · Updated:
Gemini 3.8 Live reaches developers with conversation that continues during tool calls
Official Gemini Live API announcement artwork. Credit: Google.

Google released Gemini 3.8 Live and 3.8 Live Extended Thinking through the Gemini API and Google AI Studio on September 15, 2026. Its developer announcement describes models that can execute tool and API calls in the background while continuing to stream conversational audio, with visual context among the supported capabilities.

The announcement also discusses Gemini 3.5 Transcribe, which was originally introduced on August 26. That model turns speech into text. The Live models address spoken dialogue. This distinction matters because transcription accuracy and successful completion of an application task are different outcomes.

An application still needs a task model

Consider a hypothetical order-status assistant. It asks another system for information, then waits for a response. During that interval, the user might correct the order number, ask a different question or cancel the request. A delayed response must be associated with the right request before the application uses it.

The design problem therefore extends beyond producing a quick spoken acknowledgement. The application needs to track which task is active, which results are still relevant and whether an action should proceed. Continuing to talk while work happens makes those state transitions more visible, rather than making them disappear.

These are proposed evaluation questions, not findings from our own testing of Google's models. A development team could create representative tasks with known expected results and record three things separately: what the system heard, what information it produced and what it changed. That separation helps identify whether a failure began in speech recognition, interpretation or execution.

For a task that changes data, it is also useful to inspect the final application state. Correctly repeating an order number does not establish that the intended record was updated. The relevant evidence is the completed result.

Local-language quality needs local evidence

A broad language-coverage claim cannot establish quality for a particular dialect or workflow. A Kurdish-language service would benefit from tests containing local personal and place names, numbers and speech mixing Kurdish with Arabic or English. Different microphones and realistic background sounds would make those tests more representative.

Corrections deserve their own cases. A person might begin with one number and replace it halfway through a sentence. The application should be assessed on the final intended value, rather than on whether it transcribed the first number clearly.

The release gives developers another way to build a voice interface. Whether it fits a product depends on task requirements, language performance and control over actions in that particular environment. This report makes no independent speed, accuracy or hands-on performance claims; those require testing beyond the availability announcement.

Sources

Sources: Google — September 15 developer announcement, Google — August 26 Transcribe announcement
Osamah Ismail

Founder and editor-in-chief of Kurd Developers. Phone and tech news on YouTube, Instagram and TikTok.