Google's Gemini Update Spans Real-Time Transcription, Video Generation and a Voice-First App

A three-part Gemini update

In late August 2026 Google shipped a cluster of related Gemini releases rather than a single feature. According to a summary published on dev.to, the expansion covers three areas: Gemini 3.5 Transcribe for speech-to-text, Gemini Omni 1.1 Flash for video generation and editing, and Gemini Live, a voice-first experience built into the Gemini app. Google positions the transcription model as its most precise speech-to-text offering yet, while Omni 1.1 Flash adds expanded creative capabilities and controls for video workflows.

Two transcription models with nearly identical names

A separate hands-on account on dev.to, written by a developer adding transcription to a macOS meeting-translation app, highlights a complication for anyone adopting the new model: Gemini 3.5 Transcribe actually arrives as two models with similar names and very different capabilities.

The first, gemini-3.5-transcribe-live, runs over the Live API using WebSocket streaming and transcribes speech as it happens. The second, gemini-3.5-transcribe, runs over the Interactions API as a standard HTTP request and processes an audio file uploaded after recording via the Files API.

The differences are significant. The live model supports sessions of up to ten minutes and produces interim results, tentative text that gets replaced as the speaker continues, which suits live subtitling. It does not support speaker diarization or word-level timestamps. The batch model handles audio up to an hour, or thirty minutes when diarization is enabled, distinguishes up to eight speakers, and returns word-level timestamps.

Real-time limits and developer gotchas

Google's documentation, as cited by the developer, is blunt about the split: diarization is not available in live streaming sessions, and anyone who needs to know who said what must record the audio and send it to the non-streaming endpoint afterwards. That constraint dictated the developer's whole architecture, since real-time speaker attribution is not currently possible.

There is also a mode trade-off. SMART mode strips filler words and adds formatting, producing cleaner meeting minutes, while VERBATIM keeps everything word-for-word. Diarization only pairs with VERBATIM, so teams wanting speaker labels must give up SMART's cleanup. A custom vocabulary option accepts up to 1,000 terms, though the documentation recommends staying below 100 for best results.

The developer flagged further implementation traps: the batch model does not use the standard generateContent endpoint, omitting the timestamp granularity setting causes word-level timestamps to fail silently, and speaker labels come back as anonymous IDs such as spk_1 rather than names. Google also notes that attribution with three or more speakers is experimental.

Video generation and voice-first interaction

The other two releases extend Gemini in different directions. According to the dev.to summary of Google's announcements, Gemini Omni 1.1 Flash expands creative capabilities and controls for video generation and editing, placing video production alongside Gemini's existing text, developer and enterprise surfaces. Gemini Live, meanwhile, is a voice-led interface in the Gemini app, aimed at moments when speaking is more practical than typing.

Neither announcement included pricing, detailed rollout terms or specifics on third-party integrations, the summary notes, so access and commercial terms may vary across Google's product surfaces.

Why it matters

Taken together, the updates show Gemini stretching across the full content workflow: capturing speech, producing video, and being spoken to rather than typed at. For developers, the transcription release carries a practical warning. Two similarly named models sit on different APIs with different session limits, and the headline capability many teams want, real-time speaker attribution, is explicitly unavailable in streaming mode. Anyone building meeting tooling on Gemini 3.5 Transcribe has to decide up front between live text and labeled speakers, because the current API does not offer both at once.