Google launched Gemini 3.5 Transcribe on August 26 with two endpoints that look similar enough to invite the wrong comparison.
The useful distinction is not “basic versus premium.” It is recorded audio versus real-time interaction.
Use gemini-3.5-transcribe when you already have an audio file and care about lower cost, speaker labels, word-level timestamps, or longer recordings. Use gemini-3.5-transcribe-live when the product needs text to appear while someone is speaking and sub-second interaction matters more than those post-processing features.
At Google’s current published effective rates, that difference is also measurable: roughly $30 versus $54 for 100 hours of audio before your own storage, networking, observability, and application costs.
Feature and pricing check — August 28, 2026: Google’s Gemini API release notes label both 3.5 Transcribe endpoints generally available. Google’s August 26 launch article still contains “public preview” wording near the bottom, so teams that depend on a specific support commitment or lifecycle status should verify the current product terms for their account rather than relying on one launch-page label.
The quick answer
| Requirement | gemini-3.5-transcribe | gemini-3.5-transcribe-live |
|---|---|---|
| Recorded audio files | Best fit | Possible only by building a streaming path you probably do not need |
| Real-time interim text | No | Yes |
| Published effective paid rate | ~$0.005/min | ~$0.009/min |
| 100 hours at published effective rate | ~$30 | ~$54 |
| Word-level timestamps | Yes | No |
| Speaker diarization | Yes, up to 8 speakers | No |
| Custom vocabulary | Yes, up to 1,000 terms | Yes, up to 1,000 terms |
| Smart dictation / filler cleanup | Yes | Yes |
| Language auto-detection | 85+ languages | 85+ languages |
| Maximum audio duration | Up to 1 hour per request | 10 minutes per session |
| With diarization or word timestamps | Up to 30 minutes | Not supported |
This makes the first decision surprisingly simple:
If nobody needs to see the transcript before the audio ends, start with the file endpoint.
Live transcription earns its higher cost when latency is part of the user experience.
What Google actually launched
Gemini 3.5 Transcribe is one speech-to-text family exposed through two different operating modes.
File transcription: gemini-3.5-transcribe
This endpoint is designed for audio that already exists: meetings, interviews, call recordings, voice notes, podcasts, support calls, and other post-processing workflows.
Google currently documents:
- automatic detection across 85+ languages;
- word-level timestamps;
- custom vocabulary biasing;
- speaker diarization for up to 8 speakers, with attribution for three or more still described as experimental;
- Smart transcription that can remove filler words and format spoken content;
- up to 1 hour of audio per request, reduced to 30 minutes when diarization or word timestamps are enabled.
Live transcription: gemini-3.5-transcribe-live
The Live endpoint uses the Gemini Live API over WebSockets and returns interim and final transcription events while audio is still arriving.
Google positions it for voice interfaces, live captioning, interactive applications, and other cases where waiting until the end of a recording would break the experience.
The trade-offs are concrete:
- sessions are currently limited to 10 minutes;
- word-level timestamps are not supported;
- speaker diarization is not supported;
- the published effective per-minute cost is higher.
So Live is not “the same transcript, but faster.” It is a different product shape.
The $30 vs $54 calculation
Google publishes both token prices and approximate effective per-minute rates.
For the file endpoint, Google lists:
- audio input: $2.00 per 1M tokens, approximately $0.003/min;
- text output: $12.00 per 1M tokens, approximately $0.002/min;
- effective blended rate: about $0.005/min.
For Live Transcribe:
- audio input: $3.50 per 1M tokens, approximately $0.005/min;
- text output: $21.00 per 1M tokens, approximately $0.004/min;
- effective blended rate: about $0.009/min.
Using those published approximations:
| Audio processed | File endpoint | Live endpoint | Difference |
|---|---|---|---|
| 10 hours | ~$3 | ~$5.40 | ~$2.40 |
| 100 hours | ~$30 | ~$54 | ~$24 |
| 1,000 hours | ~$300 | ~$540 | ~$240 |
| 10,000 hours | ~$3,000 | ~$5,400 | ~$2,400 |
The formula is deliberately boring:
minutes × Google's approximate effective rate
Those are model-cost estimates, not a quote for an entire transcription product. A real system may also pay for object storage, bandwidth, queues, databases, monitoring, retries, downstream summarization, or a streaming-media layer.
The useful takeaway is the ratio: Live is about 1.8× the published effective model cost per minute.
If the product needs live text, that premium may be trivial. If the job is simply “transcribe 50,000 uploaded recordings overnight,” paying it buys very little.
Live is not a quality tier
A common product-design mistake is to see two endpoints and assume the more expensive one is the “better” model.
Google’s own launch material points in the opposite direction. It cites Artificial Analysis measurements of roughly 4.0% word error rate for streaming and 2.6% for non-streaming on the evaluated workloads.
Those vendor-cited numbers should not be treated as a guarantee for a particular application. Accuracy can change dramatically with accents, microphones, overlapping speakers, jargon, phone compression, background noise, language switching, and the exact scoring method.
But they reinforce the architecture decision:
- Live buys responsiveness.
- File processing buys richer transcript structure and lower published cost.
The right benchmark is therefore not “which model has the lower WER on Google’s launch page?” It is “which endpoint satisfies the product requirement with acceptable errors on our own audio?”
Smart transcription can be the wrong choice for an exact record
Gemini 3.5 Transcribe does more than literal speech recognition.
Google’s Smart transcription mode can:
- remove filler words such as “um” and “ah”;
- handle self-corrections;
- add punctuation and formatting;
- format alphanumeric content more intelligently.
That is excellent for dictation, notes, support summaries, and text that a person wants to read.
It can be undesirable when the transcript is supposed to preserve exactly what was spoken.
Imagine this audio:
“Ship it Tuesday—uh, no, Wednesday.”
For a polished note, returning the corrected intent may be helpful. For linguistic analysis, QA review, a verbatim interview record, or any workflow where the disfluency itself matters, cleanup changes the artifact.
Google’s transcription documentation separates Smart transcription from more literal modes, and richer timestamp/diarization workflows belong on the recorded-audio path.
A good design question is therefore:
Are we creating readable text, or are we preserving evidence of speech?
Those are different products even when they start from the same audio file.
When the file endpoint is the better default
Meeting and call archives
Recorded meetings usually need speaker attribution more than they need sub-second text. Diarization and timestamps make later search, clipping, QA, and summarization much easier.
Podcast, interview, and research workflows
If the audio is already complete, a WebSocket session adds infrastructure without adding user value. File processing is cheaper and supports transcript metadata Live currently lacks.
High-volume asynchronous jobs
Queues of uploaded voice notes, call-center recordings, or media libraries benefit directly from the lower published rate. At 10,000 hours, the model-price difference is about $2,400 using Google’s current effective estimates.
Any workflow that needs word-level timestamps
This is a hard feature gate today. Live Transcribe does not support them.
Multi-speaker recordings
The file model supports diarization for up to eight speakers. Live currently does not support speaker diarization at all.
When Live is worth paying for
Live captions
A caption that appears after the conversation ends is not a captioning product. Responsiveness is the requirement, so Live is the natural fit.
Voice-controlled interfaces
If a user speaks and expects the application to react immediately, waiting for an uploaded recording breaks the interaction loop.
Dictation boxes and voice composition
The user benefits from seeing partial text, catching errors, and continuing without manually ending and uploading each recording.
Voice agents that need transcription events upstream
A system may use the transcript to trigger intent detection, UI changes, retrieval, or other application logic while a session is active. Live is built for that kind of streaming pipeline.
The 10-minute session limit still has to be designed around. A product with longer conversations needs explicit session management rather than assuming one permanent socket can run all day.
The hybrid architecture is often better than choosing one
Some products need both a responsive transcript and a high-quality final record.
A support-call application is a good example.
During the call:
microphone
↓
Gemini 3.5 Transcribe Live
↓
interim captions / live UI / agent context
After the call:
saved recording
↓
Gemini 3.5 Transcribe
↓
final transcript + speakers + timestamps
↓
archive / QA / search / downstream analysis
This avoids forcing the streaming transcript to do a job it was not designed for.
The trade-off is obvious: if every minute is processed twice, model cost is roughly the sum of both paths. Using Google’s current effective estimates, 100 hours processed once live and once as a file is about $84 in transcription-model charges.
That can still make sense when the live transcript is disposable UX and the final transcript is the durable record.
The better optimization question is not “How do we avoid paying twice?” It is:
Do we actually need both artifacts?
If the final record never uses speakers or timestamps, reprocessing may be unnecessary. If the live UI is not valuable, streaming was unnecessary in the first place.
A practical evaluation before switching providers or endpoints
Do not benchmark speech-to-text with five clean studio clips. Build a small test set from the audio the application actually receives.
1. Collect 20–50 representative clips
Include the ugly cases:
- phone audio;
- background noise;
- quiet speakers;
- overlapping speech;
- names, product codes, postcodes, and acronyms;
- multiple languages or code-switching if relevant;
- the microphones users actually have.
Remove or appropriately handle sensitive data before putting samples into a new service.
2. Measure the errors that matter
Raw word error rate is useful, but product-specific errors may matter more.
Track separately:
- names and domain terms;
- numbers and IDs;
- missing negations;
- speaker assignment errors;
- timestamp drift;
- punctuation/formatting changes;
- disfluencies removed when they should have been retained.
A transcript can have a low overall WER and still fail the one entity the workflow needs.
3. Test custom vocabulary
Both endpoints support up to 1,000 terms, although Google says customers typically see the best results with up to around 100.
Use this for genuinely domain-specific names and jargon rather than dumping an entire database into the hint list.
4. Measure end-to-end latency, not model marketing latency
For Live, measure from speech arriving at the client to usable text appearing in the UI. WebSocket setup, network distance, buffering, client audio processing, and your own application pipeline all matter.
For file processing, measure queue-to-finished-transcript time at realistic file sizes and concurrency.
5. Compare cost per usable hour
Retries, failed sessions, post-processing, human corrections, and duplicate hybrid runs can matter more than the headline per-minute rate.
A useful metric is:
(total transcription + retry + correction cost)
÷
hours of transcript accepted for its intended use
That makes a model that needs less cleanup potentially cheaper even when its unit price is higher.
One documentation wrinkle to watch
Google’s current Gemini API release notes call the two Transcribe endpoints generally available as of August 26.
Google’s launch blog published the same day still says developers and enterprises can access the model in public preview.
That is an official-documentation inconsistency, not something an application should guess around.
For experiments and ordinary development, the endpoints are available now. For contracts, support commitments, regulated deployments, or internal policies that distinguish GA from preview, verify the status shown in the current console, API documentation, and applicable Google agreement before treating either wording as authoritative.
The broader technical facts are much clearer: the model IDs, feature matrix, duration limits, and current prices are all documented in the developer pages.
What to watch next
The most useful changes would be straightforward rather than flashy.
Longer Live sessions would simplify call and meeting products that currently need session rotation. Speaker diarization in Live would reduce the need to run the same audio twice. And word-level timestamps in streaming would make live caption output more reusable downstream.
Google also says Gemini 3.5 Transcribe is coming to Chrome for talk-to-type, which may expose the model to a much larger set of real-world microphones, accents, and noisy environments.
For developers, however, the next product announcement matters less than one thing: whether the endpoint continues to perform on the application’s own error cases after traffic scales.
Conclusion
Gemini 3.5 Transcribe and Transcribe Live are not competing quality tiers. They solve different timing problems.
Choose the file endpoint when the audio already exists, especially if speaker labels, word timestamps, longer recordings, or lower model cost matter. Choose Live when the user needs text while speaking and that responsiveness is worth roughly the current 1.8× per-minute premium.
For products that need both live interaction and a durable structured transcript, use both deliberately: Live for the moment, file processing for the record.
The most useful number is not the advertised WER or even $0.005 versus $0.009 per minute. It is cost per usable hour on the audio your product actually receives.
Sources
Checked August 28, 2026: