Gemini 3.5 Transcribe Ships With 4.0% Streaming WER, a 70% Faster Time to Final Transcription, and a Three-Speaker Ceiling

Google released Gemini 3.5 Transcribe, a speech-to-text model, on August 26, 2026. As measured by Artificial Analysis, the model averages a 4.0% word error rate (WER) for streaming and 2.6% for non-streaming use cases, and time to final transcription improves by 70%. On the FLEURS multilingual benchmark it records 5.50% WER in streaming mode and 5.04% in non-streaming, and it automatically detects and transcribes over 85 languages. Speaker attribution in pre-recorded audio covers up to three speakers, with support beyond three marked experimental. ASAP works only from figures verifiable in Google's own announcement to show that the seat this model targets is the front end of a voice agent rather than a dictation tool.

The same model's WER splits differently across two measurements

The announcement carries two kinds of error rate side by side. One is the Artificial Analysis average of 4.0% WER for streaming and 2.6% for non-streaming. The other comes from FLEURS, measured across a set of top languages and locales, at 5.50% WER streaming and 5.04% non-streaming. Google describes the FLEURS result as an improvement over its previous model, Chirp 3.

Placed next to each other, the two measurements price streaming very differently. Under Artificial Analysis the gap between streaming and non-streaming is 1.4 percentage points, which against a 2.6% base means errors rise by a factor of 1.54. On FLEURS the same gap is 0.46 points, a factor of 1.09. How much accuracy real-time processing costs therefore depends heavily on which pool of speech is being measured.

That difference carries a practical consequence for adoption. A team designing live captioning or call assistance, where streaming is mandatory, has its quality expectation set by whether 4.0% or 5.50% is closer to its own audio. The heavier the multilingual and accented traffic, the safer it is to plan against the FLEURS figure. The presence of two benchmarks in a single announcement is itself a signal that this model does not reduce to one headline number.

"Smart transcription" sells editing, not accuracy

The feature Google leads with is not the error rate but smart transcription. When a speaker corrects themselves, saying they will meet Tuesday and then immediately switching to Wednesday, the model keeps only the final intent. Filler words like "ums" and "ahs" are removed and formatting is applied automatically. Custom vocabulary support lets the model recognize specialized jargon and unusual spellings supplied by the developer.

What deserves attention here is that this feature and the WER metric point in opposite directions. Word error rate counts the distance between a reference transcript and model output, and it rewards transcribing speech exactly as spoken. Smart transcription deliberately alters speech. The moment a retracted phrase is dropped and filler is stripped, the output stops being a record of what was heard and becomes an edited sentence. With both goals living in one model, it matters a great deal whether the published error rates were produced with smart transcription on or off. The announcement does not state that condition.

The feature flips character depending on the use case. For meeting notes or voice input, where the deliverable is text meant to be read, editing is pure gain. For domains that require the original utterance to survive, such as counseling records, statements, or compliance logs, every word the model silently removed is evidence that no longer exists. The first decision for an adopting team is therefore not a target accuracy but a question of kind: does our record have to be a copy of the sound, or a summary of the meaning?

The partner list says where this model is actually being placed

The developer partners named in the announcement are Agora, Fishjam, LangChain, LiveKit, Pipecat, Vercel, and Vision Agents. Companies cited as providing early feedback include Vivo, Intellitek Health, Lingopal, and Stream.

That roster leans hard in one direction. LiveKit, Agora, and Pipecat build real-time voice streaming and voice-agent pipelines, LangChain handles agent orchestration, and Vercel handles application deployment. Transcription services, subtitling houses, and media archive vendors are conspicuously absent. The reasonable reading is that Google positioned this model not as a tool for turning recordings into text, but as the first stage of a loop in which a person speaks and an agent responds.

The feature set points the same way. Function calling lets the model delegate complex work such as image generation and file analysis to other Gemini models, and that capability currently ships in the Gemini macOS app. So does the claim that the model performs well in noisy, real-world environments and accurately captures alphanumeric entities like postal codes and order IDs. Postal codes and order IDs are not the words that matter in a meeting transcript; they are values that immediately become arguments for the next action in a call center or an order flow. It also explains why a 70% improvement in time to final transcription is emphasized ahead of any accuracy gain. In a conversational voice agent, perceived quality is governed by how long the user waits for the last word to settle.

What a three-speaker ceiling means for the meeting-notes market

The announcement states that pre-recorded audio gets speaker attribution with timestamps for up to three speakers, and that support for more than three is experimental. Timestamps are provided at word level.

Three is a number that sorts use cases cleanly. One-to-one support calls, a customer and an agent, an interviewer and a respondent all fit inside the ceiling. Team meetings, seminars, and multi-party negotiations with four or more participants sit outside it. For a team evaluating this model with meeting-notes automation in mind, the first thing to check is not the error rate but this limit.

Read alongside the partner roster, the limit looks like a choice rather than an omission. If call centers and voice agents are the main stage, speakers are usually two and at most three. Multi-party meeting transcription is a separate technical problem and, on this evidence, not the market this release is aimed at. Since anything beyond three speakers is explicitly labeled experimental, any organization considering multi-party use should treat the published error rates as inapplicable and measure against its own recordings.

Three things a team working in a non-English language should check first

Access to Gemini 3.5 Transcribe splits by use case across two separate endpoints, each with its own model name. Real-time streaming runs through the Live API using the gemini-3.5-transcribe-live model, while pre-recorded audio runs through the Interactions API using gemini-3.5-transcribe. Both are in public preview through the Gemini API in Google AI Studio and through the Gemini Enterprise Agent Platform, and developers can also reach the model in Google Antigravity. Consumer surfaces are the Rambler feature in Gboard on Android and the Gemini app on macOS, with Chrome and Gemini Enterprise for Customer Experience listed as coming soon.

The first item to check is Rambler's footprint. Google says only that it ships in select countries and languages, without listing them, so language coverage cannot be settled from the announcement and has to be confirmed on the device. The second is code switching. The announcement claims support for live language switches, and business conversations that mix a local language with English product names and technical jargon are an excellent test of whether that claim holds in practice. The third is custom vocabulary. Company names, personal names, and product names are exactly where standard speech models fail most often, and how much ground the custom vocabulary feature recovers there is the practical criterion for adoption.

All three share one property: the published numbers do not answer them. FLEURS was measured across a set of top languages and locales with no per-language breakdown, so the right move is not to infer local performance from an 85-language average but to measure roughly a hundred of your own recordings directly.

What the announcement does not answer: price, per-language performance, and the comparison baseline

Google's Gemini 3.5 Transcribe announcement leaves three items unaddressed: price, per-language performance, and the baseline behind its comparison claims. The first is price. Public preview is stated, but no per-minute or per-token rate is given. Speech workloads scale linearly with call volume, so until a rate exists, pilot results cannot be carried straight into an operating budget.

The second is per-language breakdown. The claim of support for over 85 languages and the FLEURS condition of a set of top languages and locales have to be read together. A single average is thin evidence that quality is uniform across 85 languages, and the announcement does not say which languages lifted the mean.

The third is the comparison baseline. The sentence stating that time to final transcription improves by 70% attributes the measurement to Artificial Analysis but does not specify, within that sentence, what it improves against. The FLEURS result is described as an improvement over Chirp 3, yet Chirp 3's own WER figures are not tabulated. No comparison to competing speech models appears at all. For an organization that needs this model's relative position, reading the announcement does not close the question, and running the same audio files through several models remains an open step.

Source: Google's official blog announcement of Gemini 3.5 Transcribe (August 26, 2026) and the identical Google DeepMind blog post, compiled by ASAP