Two Independent Utilities Now Build on Gemini 3.5 Transcribe, and the One Calling Google’s Live Variant Is Named After Whisper

Evidence note: This article rests on two kinds of material, and keeps them apart. The first is primary self-description — a vendor announcement page and the public descriptions attached to two open-source projects, which establish what the publishers say about their own work. The second is independent corroboration, and this record has none: nothing below has been confirmed against a second source, and no audio has been run through either model name here. Every specific identifier, model string and project claim carries its evidence level at the point it appears.

What Google Announced: A Speech-to-Text Model Named Gemini 3.5 Transcribe

The starting point is a single page on Google’s own blog, presenting a speech-to-text model under the name Gemini 3.5 Transcribe (announcement page). [Evidence: vendor’s own announcement as listed in this record; the page’s contents have not been independently reviewed or corroborated here, and whether such a page was in fact published on the official blog is an open question in this record.]

What matters for a developer is narrower than the model’s capabilities. The name on an announcement page is a marketing surface. The thing a client library actually sends over the wire is a model identifier string, and that string is what pins behaviour, pricing and availability. The gap between those two — one announced name, more than one callable identifier — is the whole subject here.

The Announcement Page Is the Only Primary Source in This Record

No benchmark, no independent test, no third-party write-up, and no vendor documentation beyond the announcement itself sits behind the model claims in this article. That is a hard limit on what can be said about accuracy, latency, language coverage or cost: nothing. Sources available here do not establish a word error rate, a supported-language list, a streaming latency figure, or a price per minute of audio for either identifier discussed below.

That absence is worth stating plainly rather than filling. A reader deciding whether to adopt a wrapper around this model should treat the model’s own performance as unmeasured in this record, and look to the vendor’s documentation for figures. This article answers a different and more tractable question: which identifier does each existing community project call.

The First Utility on Record: An Application That Transcribes Audio Files With the Base Model

The first of the two projects is published as maks-mk/gemini35transcribe, described by its own repository as an application that transcribes audio files using Google’s gemini-3.5-transcribe model (project repository). [Evidence: the project’s own public description; independent corroboration is open, and this record has not verified the described behaviour by running the code.]

Two details in that description carry weight. It is file-oriented — audio files in, text out — rather than a streaming client. And the identifier it names is the base one, gemini-3.5-transcribe, with no suffix. For a batch job that walks a directory of recorded captures, that is the shape most likely to drop in without redesign.

A Second Model Name in the Same Family: gemini-3.5-transcribe-live

The second project introduces a different string. A variant named gemini-3.5-transcribe-live is described as the model used by the nippur72/whisper-gemini transcribe utility (project repository). [Evidence: the project’s own public description; independent corroboration is open. Whether the -live identifier is a separate deployed endpoint, an alias, or a differently tuned model is not established by anything in this record.]

The -live suffix conventionally signals a streaming or realtime surface in model naming across vendors, but that is an inference from naming convention, not a documented fact about this identifier. Sources available here do not confirm what the suffix changes — whether it alters the transport, the latency profile, the maximum audio length, the output format, or the billing unit. A team that needs realtime transcription should treat the suffix as a lead to verify in vendor documentation, not as a specification.

Two Independent Projects, Neither of Them Google’s Reference Implementation

Taken together, the record contains at least two separately published open-source utilities built on Gemini 3.5 Transcribe models. [Evidence: inferred from the two project descriptions above; the broader claim that at least two independent community utilities exist is uncorroborated in this record and remains open — there may be more, and the independence of these two has not been audited.]

Neither is a Google-maintained client. Both are community work, published under individual accounts, and nothing in this record indicates vendor review, support commitment, or a compatibility guarantee against future changes to either model identifier. That is the ordinary condition of an early ecosystem around a new model, and it is the condition a small team is actually choosing when it adopts a wrapper instead of writing a thin client of its own. The cost of writing that thin client is usually a day; the cost of discovering six months later that an unmaintained wrapper pins a deprecated identifier is harder to bound.

Reading Each Project’s Name Against the Model Identifier It Actually Calls

Laid side by side, the mapping inverts the expectation a name sets up:

[Evidence for both rows: each project’s own public description, as cited in the sections above; not independently verified by reading the source.]

The first row is unremarkable: the repository name tracks the model name, and the identifier is the plain one. The second is the interesting case. The project carries whisper in its name — the name of OpenAI’s open speech-recognition model, an unrelated system — while the model it is described as calling is Google’s live Gemini variant. Nothing in this record establishes why the name was chosen; a borrowed name in this space often signals interface compatibility, a drop-in replacement for an existing Whisper-based call site, or simply familiarity, and sources here distinguish none of those.

Why the Name on the Repository Cannot Tell You Which Model Surface It Uses

Three independent failure modes show up in just this two-project sample.

A name can borrow an unrelated model’s identity. whisper-gemini reads as a Whisper project to anyone scanning a dependency list, and the identifier described behind it is a Gemini one.

A name can omit the variant. gemini35transcribe names the family but not which of the family’s strings it pins; the base identifier is known here only because the project states it, not because the name encodes it.

A name is fixed at publication; the model string is a line of code. A repository name does not change when a maintainer swaps gemini-3.5-transcribe for gemini-3.5-transcribe-live, or pins a dated snapshot, or moves to a successor model. The name that was accurate at the first commit carries no obligation to stay accurate.

The practical consequence: in this ecosystem, the repository name is a label on the box, not a bill of materials. This is the same pattern visible elsewhere in the current agent-tooling wave, where a project’s stated category and its actual mechanism diverge — see this site’s earlier reading of what the public Gemini 3.5 Transcribe projects actually build, and a comparable mismatch between naming and function across a set of agentic security projects.

What to Check Before Adopting Either Utility: Which Model String It Pins

The check is short, and it does not require benchmarking the model.

Find the literal identifier. Search the repository for gemini-3.5-transcribe and read every hit. A project built on the base model and one built on the live variant differ by one suffix in one string, and that string is usually in a config file, an environment-variable default, or a single constant.

Determine whether it is configurable or hard-coded. A wrapper that reads the model name from configuration can follow the vendor’s naming as it changes. One that inlines the string requires a fork or a patch to move.

Match the surface to the job. A file-at-a-time batch job and a realtime stream are different integration shapes. The file-oriented project is described as taking audio files; the other is described as calling the live variant. Adopting the wrong shape means either simulating streaming over a batch API or buffering a stream to disk — both workable, both avoidable by reading the identifier first.

Check the last commit date and open issues before the README. For an unmaintained wrapper around a new model, a stale pin to a retired identifier is the most likely way it breaks, and that risk is legible from the commit history rather than the documentation.

Price the alternative honestly. If the wrapper’s value is a thin HTTP call plus audio-file handling, writing it directly against the vendor’s documented identifier removes a dependency whose naming, as shown above, does not describe its contents.

A Comparison Not Yet Run: The Same Audio Through Both Model Names

The obvious experiment has not been performed here, and nothing above should be read as if it had. That experiment: take one fixed audio set — a few minutes of game-capture voice, a few minutes of clean narration, a few minutes with background music under speech — and send the identical files to gemini-3.5-transcribe and to gemini-3.5-transcribe-live, then compare transcript text, timing metadata, failure behaviour on long inputs, and cost per minute.

That design is a proposal, not a result. It would establish whether the two identifiers are the same weights behind two transports or genuinely different models, which is the question a developer choosing between the two wrappers most needs answered and which no source in this record addresses. Until it runs, the honest summary is the mapping and the warning: two model names exist in this family, two community utilities are on record calling one each, the project whose name points at Whisper is described as calling Google’s live variant, and the identifier string in the source is the only part of any of this that tells a reader which surface they are about to depend on.