Gemini 3.5 Transcribe Goes GA—85+ Locales, With Feature Tradeoffs

Publication status: rejected. Google introduced Gemini 3.5 Transcribe on August 26, 2026, with automatic detection for more than 85 languages, but developer and enterprise access launched in public preview rather than general availability, as contemporaneous release coverage confirms.

The selected headline’s central claim—“Goes GA”—therefore conflicts with the documented release status. The launch did establish two developer routes and a broad feature set, but availability alone does not turn a preview model into a generally available service.

The August 26 release was a public preview

The developer release consists of gemini-3.5-transcribe for completed recordings and gemini-3.5-transcribe-live for streaming audio. The first uses the Interactions API after a file upload; the second uses the Live API for text that changes while speech is still arriving.

The status distinction matters because GA normally signals a different production commitment from a public preview. Neither the existence of callable model IDs nor availability in Google AI Studio supplies evidence for the stronger status stated in the headline. Publishing the story as written would consequently mischaracterize the event rather than merely simplify its terminology.

File and live transcription have different contracts

Google’s current transcription documentation specifies automatic recognition across 85-plus locales, files of up to one hour, a 30-minute ceiling when diarization or word timestamps are enabled, live sessions of 10 minutes, diarization for up to eight speakers with attribution for three or more marked experimental, and custom vocabulary containing up to 1,000 terms, with best results typically reported for no more than 100.

• Recorded audio: use gemini-3.5-transcribe when a complete file already exists or the result requires speaker labels, word offsets or a stable post-processing step.
• Live audio: use gemini-3.5-transcribe-live when incremental captions are essential. It does not provide speaker diarization or word-level timestamps.
• Audio reasoning: neither route is a general audio-analysis model. Summaries, question answering, tool use and spoken responses require another model or processing stage.

This is an architectural split, not a choice between two interchangeable model names. A recorded workflow uploads media and receives a completed result; a live workflow must handle streaming audio, changing hypotheses, finalized segments, connection state and session renewal. A product that needs immediate captions and a speaker-attributed archive may need a live pass followed by a separate recorded-file pass.

The feature matrix contains hard conflicts

The recorded route exposes diarization, word-level timestamps, vocabulary biasing and two transcription modes, but those capabilities cannot all run together. Verbatim mode preserves disfluencies and supports structural annotations. Smart mode instead removes filler words, resolves spoken corrections and restructures the result for readability.

• Diarization: recorded endpoint only; compatible with word timestamps, but incompatible with smart mode and custom vocabulary.
• Word timestamps: recorded endpoint only; compatible with diarization, but incompatible with smart mode and custom vocabulary. Google also warns that enabling them may reduce transcription accuracy.
• Vocabulary hints: supported by recorded and live transcription, but cannot be paired with diarization or word timestamps on the recorded route.
• Smart cleanup: supported by both routes, but cannot produce diarization or word-level timestamps because those annotations require verbatim mode.

The practical consequence is that a single recorded request cannot simultaneously deliver polished prose, custom terminology, speaker labels and word-level alignment. Developers must prioritize readable cleanup, vocabulary biasing or traceable annotations—or create separate processing stages when the product requires more than one of those outcomes.

Documented features are not independent accuracy results

Google’s launch claims include low word-error rates and faster final transcription than Chirp 3, but those figures are vendor-presented measurements rather than independent evidence for every accent, microphone, codec or specialist vocabulary. The feature list establishes what developers can configure; it does not guarantee a particular accuracy level for an application’s own audio.

The Gemini 3.5 Audio model card adds that Transcribe and Transcribe Live may hallucinate and may occasionally be slow or time out. That caveat is materially different from an ordinary substitution error: a transcript may contain content that is not supported by the recording.

Smart transcription introduces a separate fidelity tradeoff because it intentionally changes the spoken form. Removing hesitations and resolving self-corrections can produce cleaner dictation, but the output is not equivalent to a verbatim record. Workflows that depend on exact wording, speaker attribution or alignment with source audio need the recorded endpoint in verbatim mode and must preserve the original recording.

The confirmed story stops short of GA

The verified August 26 event is a public-preview launch of two transcription endpoints with broad language coverage and consequential configuration limits. The “85+” portion of the selected title is supported, as are the promised feature tradeoffs; the GA claim is not.

A publishable GA story requires an explicit subsequent notice changing the developer release stage to generally available. Until such a status change is documented, the feature analysis can support a public-preview article, but it cannot validate publication under the contracted headline.

Also read:

• Gemini’s Personal Intelligence Goes Global—but Access Still Has Gaps
• Gemini Canvas: The AI That Builds Entire Presentations While You Watch
• Trial Reels Let Creators Test the Hook Before an Instagram Contest Goes Live