Google introduced Gemini 3.5 Transcribe this week, its most accurate speech-to-text model to date, and the interesting part is what it does after the words are recognized. The model converts raw audio directly into polished, formatted text: it strips filler words, resolves self-corrections like “let’s meet Tuesday, no, Wednesday”, and auto-formats the output. Conventional speech recognition pipelines hand you a messy transcript and leave the cleanup to you. This one aims to hand you the finished text.
The numbers, as measured by a third party
Google cites Artificial Analysis measurements rather than internal benchmarks, which I appreciate. The model averages a 4.0 percent word error rate for streaming use and 2.6 percent for non-streaming. On the FLEURS multilingual benchmark across top languages and locales, it posts 5.50 percent WER streaming and 5.04 percent non-streaming, improving on Google’s previous transcription model, Chirp 3. Time to final transcription improves by 70 percent over Chirp 3, which matters as much as accuracy for anyone building interactive voice products. A transcript that arrives two seconds late is useless for captioning and annoying for voice agents.
The model also handles noisy, real-world audio well and captures alphanumeric entities, postal codes, order IDs, account numbers, which are precisely the tokens where transcription errors become support tickets.
Two APIs, two very different use cases
Developers get the model through two endpoints. The streaming path, gemini-3.5-transcribe-live, runs on the Live API with continuous bidirectional streaming and sub-second latency, aimed at voice agents and live captioning. The recorded-audio path, gemini-3.5-transcribe, runs on the Interactions API and handles meetings, call logs, and archives, with speaker attribution and word-level timestamps. Both are available in Google AI Studio and the Gemini Enterprise Agent Platform.
Feature-wise, the recorded path identifies up to three speakers with timestamps (more than three is experimental), recognizes custom vocabulary so your product names and jargon transcribe correctly, and auto-detects over 85 languages including regional accents and mid-audio language switches. The model can also delegate tasks to other Gemini models through function calls, so a voice interaction can trigger image generation or document analysis without the developer orchestrating that handoff manually.
Where you have already used it
Google shipped this model into its own surfaces first. Gboard on Android uses it for the Rambler feature, which turns spoken rambling into well-formatted text and lets you edit by voice. The Gemini app on macOS uses it for natural dictation, and Chrome support is coming. That pattern is familiar: Google validates a model on consumer scale before exposing it broadly to developers, which is a reasonable proxy for “this survives contact with real-world audio”.
What it means for the voice stack
The competitive picture is worth stating plainly. Speech-to-text has been quietly commoditizing, and a frontier lab entering with 2.6 percent WER, custom vocabulary, and diarization bundled into the same API as its LLMs changes the calculus for teams building call analytics, meeting assistants, and voice agents. If transcription, diarization, language detection, and function calling all come from one endpoint, the dedicated speech API vendors are suddenly competing on the last mile: specialized domains, on-prem deployment, latency guarantees, and price.
For builders, the practical questions before migrating are the usual ones. What does the pricing look like at your call volume, and how does the streaming tier bill? Does the custom vocabulary feature handle your domain’s terminology without hand-tuning? How does it behave on your worst audio, which for contact centers means 8kHz telephony recordings, not studio mics? None of those have public answers yet, and the Artificial Analysis numbers were presumably measured on better input than a squished-down call-center recording.
A practical migration checklist
If the numbers hold up on your audio, moving an existing pipeline is mostly mechanical, but there are four things to test deliberately. First, run your worst-case recordings: telephony-grade 8kHz audio, cross-talk, room noise. Second, check the custom vocabulary system against your actual domain terms, since a model can be excellent in general and still mangle your product names. Third, if you need diarization, test with your real meeting sizes, because the three-speaker ceiling with experimental support beyond it may or may not fit a five-person standup. Fourth, measure the streaming path end to end from your client, not from Google’s servers, because the sub-second latency claim covers the model, not your network.
None of those tests take more than a day with the AI Studio playground, and they will tell you more than any benchmark comparison. The HN discussion of the launch pushed 235 points, which suggests a lot of teams have been waiting for a serious challenger in this space. If you have a transcription pipeline built around Chirp, Whisper, or a commercial API, it is worth an afternoon to run your own worst-case audio through and compare WER on your data rather than Google’s benchmarks. That comparison, not the press release, is what decides whether the 2.6 percent number survives contact with your users.