On August 26, 2026, Google released Gemini 3.5 Transcribe, a dedicated speech-to-text model, into public preview. It splits into a Live API for processing real-time audio and an Interactions API for handling pre-recorded files, and it automatically detects more than 85 languages. Both APIs let developers choose between a verbatim mode that preserves speech exactly as spoken and a Smart mode that cleans up spoken language into readable text.
However, you cannot get polished formatting and a high-evidentiary record at the same time. That's because Smart mode, which removes filler words and false starts, cannot be used alongside speaker diarization or word-level timestamps. Developers must first decide: do they want clean prose, or a record of who said what and when?
Transcription splits into "record" and "edit"
The default for both Live and the recorded-audio version is verbatim. It returns speech literally, preserving fillers like "um" and "uh," repetitions, and false starts. The recorded-audio version can additionally add speaker labels and word-level start/end timestamps to this mode. The design suits use cases like confirmatory meeting records, post-editing for subtitles, and audits that need to trace back to the original audio.
The other option, smart, hands post-processing of the transcript over to the model as well. It removes fillers and stutters, and consolidates self-corrections—like "Tuesday, no, Wednesday"—into the speaker's final intent. It also organizes text into paragraphs or bullet points and formats dates, currencies, and numbers consistently. Available in both Live and recorded-audio versions, this can reduce the initial editing humans would otherwise do for voice memos or email drafts.
However, smart mode in the recorded-audio version does not support speaker diarization or word-level timestamps. If you want a speaker-attributed meeting record, you need to first transcribe in verbatim mode, then handle summarization or formatting in a separate step. Live mode never returns speaker diarization or word-level timestamps, regardless of which mode is selected. This isn't an API designed to produce a finished, audit-ready transcript in a single call.
10 minutes for Live, one hour for recorded audio
The two APIs aren't simply the same functionality at different speeds—they differ in their limits and in the information they can return.
| Item | Real-time version | Recorded-audio version |
|---|---|---|
| Model ID | gemini-3.5-transcribe-live |
gemini-3.5-transcribe |
| API | Live API | Interactions API |
| Max audio length | 10 min per session | Typically 1 hour |
| Speaker diarization | Not supported | Up to 8 speakers; 3+ is experimental |
| Word-level timestamps | Not supported | Supported, may reduce accuracy |
| Smart formatting | Supported | Supported |
| Custom vocabulary | Up to 1,000 terms | Up to 1,000 terms |
The real-time version sends raw 16-bit PCM audio over WebSocket and returns both interim and final results. Google touts sub-second latency, positioning it for voice input, live captioning, and the recognition layer of voice agents. On the other hand, each session is capped at 10 minutes, diarization isn't available, and timestamps are limited to the utterance level. If you're handling broadcasts longer than 10 minutes, you need to work out how to sustain the connection before implementation.
The recorded-audio version can typically process up to one hour. However, enabling speaker diarization or word-level timestamps shortens that to 30 minutes. While the API documentation states it accepts up to 8 speakers, attribution for 3 or more speakers is experimental. Google's announcement blog mentions "up to 3 speakers," but that doesn't mean attribution for a third speaker has become a stable feature. It would be premature to judge scenarios with overlapping speech in a conference room based solely on the "supports 8 speakers" spec.
Both versions accept up to 1,000 custom vocabulary terms—a feature for prioritizing recognition candidates like product names, abbreviations, or personal names. However, Google notes that good results are typically achievable with around 100 terms. Rather than dumping in a large internal glossary wholesale, it's more practical to narrow candidates down for each meeting or task.
A WER of 2.6% isn't a score for Smart mode's quality
Google cites Artificial Analysis measurements showing an average word error rate (WER) of 4.0% for streaming and 2.6% for non-streaming. Artificial Analysis's published AA-WER v2.0 uses roughly 8 hours of audio, weighting voice-agent-oriented data at 50% and congressional speeches and corporate earnings calls at 25% each. WER measures how many word substitutions, deletions, and insertions occur relative to a reference transcript—the lower the number, the more accurate the verbatim recognition. Google also states that the time to finalize a transcript has been shortened by 70% compared to the previous Chirp 3.
A separately presented FLEURS evaluation of "major locales" showed a streaming WER of 5.50% and a non-streaming WER of 5.04%. This is a different evaluation focused on multilingual performance, distinct from the averages of 4.0% and 2.6%. Google's announcement page doesn't disclose which locales were included in the FLEURS evaluation or a breakdown by language. You cannot take the 2.6% figure as the error rate for Japanese.
WER has another limitation. Whether smart correctly consolidated "Tuesday, no, Wednesday" into Wednesday, or whether converting text into bullet points dropped meaning, can't be fully captured by word-level differences alone. If you're bringing Smart mode into business use, you should measure not just WER but also the rate at which numbers and proper nouns are preserved, the rate at which self-corrections are resolved correctly, and the frequency of unintended deletions.
Google itself states explicitly that enabling word-level timestamps may reduce recognition accuracy. You shouldn't apply a benchmark's minimum figure directly to the quality of a meeting transcript with every feature turned on.
$5 per 1,000 minutes; low-priority batch processing is cheaper with Chirp
Under the Gemini API's paid tier, the estimated effective rate is about $0.005 per minute for the recorded-audio version and about $0.009 per minute for Live. Processing 1,000 minutes would cost roughly $5 for the recorded-audio version and $9 for Live at the published unit rates. Actual billing is determined by the number of audio input and text output tokens, so these are standard conversion figures Google provides for reference.
The existing Cloud Speech-to-Text V2, which includes Chirp, charges $0.016 per minute for standard recognition up to 500,000 minutes per month, coming to $16 for 1,000 minutes. The Gemini recorded-audio version, which formats audio with Smart mode, costs about $0.005 per minute, and the low-latency Gemini Live costs about $0.009 per minute—both published estimated rates undercut Chirp's standard recognition. However, since Live and the recorded-audio version return different timestamp and speaker information, you can't simply swap one for the other based on price alone.
Meanwhile, dynamic batch processing for non-urgent tasks costs $0.003 per minute, or $3 for 1,000 minutes. You could use Chirp's low-priority batch for processing large archives overnight, and Gemini for voice input or meeting minutes that need to come back quickly. This isn't a pricing structure where the new model completely replaces existing APIs.
A free tier is also available, but according to the pricing page, free-tier input may be used to improve Google's products—a category the paid tier is excluded from. Companies handling customer calls or confidential meetings need to check contractual data-processing terms before worrying about whether something is free.
For Japanese, test meaning preservation on the same audio source
Gemini 3.5 Transcribe is in public preview on the Gemini API and Gemini Enterprise Agent Platform. On the consumer side, similar functionality has been added to the English-language Gemini app for macOS and to Rambler in Android's Gboard. A feature to dictate into any text field in Chrome is also planned.
Japanese is listed among the API's supported languages and among Rambler's supported languages as well. However, the published average WER figures don't allow you to judge quality for Japanese. You'll need to prepare recordings featuring technical jargon mixed with alphanumerics, multiple overlapping speakers, and frequent self-corrections, and run the same audio through both verbatim and smart modes. After counting errors, you should also check whether you can trace the words Smart mode removed—and the numbers it kept—back to the original audio. That's the condition under which you can trust formatting decisions to the model in actual business use.