Gemini 3.5 Transcribe: Google’s Speech-to-Text Model, Its Live Variant, and the Dictation, Captioning, and Meeting Projects Built on It

Evidence note: This article rests on two kinds of evidence. The first is Google’s own announcement material, namely a DeepMind blog post and a companion post on Google’s Keyword blog, which establish that Google introduced a model it calls Gemini 3.5 Transcribe. The second is a set of public GitHub repositories whose names and self-descriptions reference the model. Repository self-descriptions are not independent corroboration of what the model can do, of how it is exposed in the Gemini API, or of whether each project works as described. Where a claim below comes only from a project’s own description, it is presented as what that project says, not as an established fact.

What Google announced: "Intelligent transcription with Gemini 3.5 Transcribe" on the DeepMind blog

Google published a post titled "Intelligent transcription with Gemini 3.5 Transcribe" on the DeepMind blog, and a companion post appeared on Google’s Keyword blog. The framing in both titles is that this is a transcription model, positioned as part of the Gemini model family rather than a standalone speech product.

The word "intelligent" in the DeepMind title signals that Google is pitching the model as something more than raw speech-to-text, but the announcement titles alone do not settle what that means in practice. Readers looking for a walkthrough of the model’s stated capabilities can consult the site’s earlier explainer on what Gemini 3.5 Transcribe is designed to do. This article instead focuses on what has appeared around the model since the announcement.

Two model identifiers in the Gemini API: gemini-3.5-transcribe and gemini-3.5-transcribe-live

Several of the repositories discussed below refer to a model identifier written as gemini-3.5-transcribe, and some also refer to a second identifier, gemini-3.5-transcribe-live, which their descriptions present as a streaming or real-time variant. Whether both identifiers are exposed through the Gemini API in exactly that form has not been independently confirmed for this article, so the existence of two distinct API models should be treated as reported by developers rather than as verified.

The distinction matters if it holds. A batch identifier would suit uploaded audio files, where the whole recording is available before transcription starts. A live identifier would suit microphone or stream input, where text needs to come back while audio is still arriving. The projects below split roughly along that line, which is at least consistent with the two-identifier account, but consistency is not confirmation.

Google’s official macOS dictation demo "jot": hold a key, speak, and the text is typed

A repository named jot-gemini-transcribe-macOS is published under the google-gemini GitHub organization. Its name and description present it as a macOS dictation demo in which the user holds a key, speaks, and has the recognized text typed into whatever application is in focus.

The presence of the repository under the google-gemini organization is verifiable by visiting it, but this article has not independently confirmed that the demo is an official Google product in the sense of being supported, nor that it behaves as described on a given machine. The google-gemini organization hosts a mix of samples and demos, and a demo published there is best read as a reference implementation rather than a shipped feature of macOS or of Gemini.

If the demo works as its description states, it is a compact illustration of the live-transcription use case: audio captured while a key is held, sent to the model, and returned as text fast enough to feel like typing.

Third-party system-wide voice typing and dictation on macOS

Beyond Google’s own demo, at least one third-party repository targets the same idea. A project named quill describes itself as a system-wide voice typing tool for macOS built around Gemini 3.5 Transcribe. The claim that the model is used for system-wide dictation rests on that project’s own description and has not been cross-checked against a working installation for this article.

The pattern is worth noting even with that caveat. Dictation tools live or die on latency and on how they handle punctuation, capitalization, and corrections. The Google demo and the third-party tool both appear to bet that a general-purpose Gemini model can deliver those properties without a separate post-processing pass, which, if true, would be a notable difference from the classic pipeline of acoustic model plus language model plus formatting rules. Whether that bet pays off is not something the repositories’ descriptions can establish.

Real-time AI captions for live sports and esports streams with Agora RTC

A repository named agora-matchcast describes a system that produces real-time AI captions for live sports and esports streams, pairing Gemini 3.5 Transcribe with Agora’s real-time communication infrastructure. According to the project’s own description, Agora handles the media transport and the model handles the speech-to-text step.

This is the most demanding of the use cases in this article, and also the least corroborated. Live sports commentary involves crowd noise, overlapping speakers, proper nouns such as player and team names, and a low tolerance for delay. The repository’s description does not, on its own, show how the model handles any of that, and no independent latency or accuracy figures for this pairing were available to cite. The project should be read as evidence that a developer attempted the integration, not as evidence that it performs at broadcast quality.

Meeting transcription with speaker diarization

A project named MeetingProcessor presents itself as a meeting transcription tool that produces transcripts with speaker diarization, that is, with each utterance attributed to a distinct speaker. Its description references Gemini 3.5 Transcribe as the transcription backend.

Whether diarization is performed by the model itself or by a separate component in the project’s pipeline is not clear from the description alone, and this article has not confirmed either reading. That distinction is important for anyone evaluating the model for meeting use: a model that labels speakers natively is a different proposition from one whose output is post-processed by a separate diarization library. Readers should check the project’s code, not its summary, before drawing a conclusion.

Voice-note applications built with the Vercel AI SDK

Another repository, gemini-transcribe, describes a voice-note application built with the Vercel AI SDK and Gemini 3.5 Transcribe. The claim that the model can be used through the Vercel AI SDK comes from that project’s description and has not been independently verified for this article.

If the integration works as described, it lowers the barrier for web developers considerably, because the Vercel AI SDK already abstracts over several model providers and handles streaming responses in the browser. A voice-note app is also a forgiving first use case: a single speaker, a quiet room, and no requirement for real-time output. That makes it a reasonable place for a developer to start, and a poor place to draw conclusions about harder scenarios.

Audio-file transcription in open-source tools and demos across Chinese-, Russian- and English-language projects

The largest group of repositories referencing the model are straightforward audio-file transcription tools. Among those available to cite:

• gemini35transcribe, whose description suggests a Russian-language project.
• gemini_Transcribe, whose description suggests a Chinese-language project.
• whisper-gemini, whose name suggests a comparison with or migration from OpenAI’s Whisper models, though the article has not confirmed that reading.
• gemini-transcribe-ai, an English-language tool.
• gemini-transcribe-demo, a demo whose author’s handle suggests a Google affiliation, though the repository is under a personal account rather than a Google organization and its official status is not established.

The language attributions above are inferred from repository names and descriptions and should be treated as approximate. What the group shows, with that caveat, is geographic spread: developers writing in at least three languages have published tools around the model within a short period after the announcement. That spread says something about interest. It says nothing yet about accuracy in any of those languages, and no independent multilingual benchmark for the model was available to cite.

What the ecosystem so far tells us about where the model fits

Taken together, the repositories sketch a model being tried across the full range of speech-to-text scenarios: batch file transcription, near-real-time dictation, meeting notes with speaker labels, and live captioning under difficult acoustic conditions. The distribution of projects is skewed toward the easier end. File transcription tools and voice-note apps are the most numerous, dictation demos come next, and the live captioning and diarization projects each appear once in the sources available.

Two cautions follow from that. First, a cluster of GitHub repositories is a measure of developer curiosity, not of production adoption or of quality. Most of these projects are described as demos or personal tools, and none of the sources cited here reports independent accuracy, latency, or cost figures. Second, the split between a batch identifier and a live identifier, if it is real, means the model’s fit for a given task depends on which variant a developer reaches for, and the repositories do not always make clear which one they use.

For readers following Google’s broader model line, the transcription model sits alongside other recent DeepMind releases such as the Gemini 3.8 Flash models and the company’s work on agentic video understanding, which together suggest a strategy of pushing Gemini into modality-specific roles rather than shipping separate specialist systems. Whether Gemini 3.5 Transcribe holds its own against dedicated speech models in that role is an open question that the current ecosystem evidence cannot answer. The projects above are the places to watch for the first measured comparisons.