Gemini 3.5 Transcribe is Google’s newest speech-to-text model—public preview as of 26 August 2026—aimed at polished, real-time and recorded transcription rather than another general chat model that happens to accept audio. For US SMB founders and product leads, the useful question is not “should we add voice everywhere?” It is: where does transcription belong in our product—on the user’s keyboard, inside our app, or only in an ops pipeline—and how do we ship it without leaking call recordings?
This guide is a decision brief for teams building custom software, web apps, and mobile products. It is not a low-latency voice-agent architecture deep dive; Softix already covered OpenAI-oriented voice stacks separately in the May 2026 technical post. Here the focus is Gemini Transcribe’s consumer surfaces versus APIs, a Softix decision framework, privacy defaults, and a 90-day plan that assumes preview-status risk.
What Google shipped on 26 August 2026
According to Google’s announcement, Gemini 3.5 Transcribe is described as Google’s most precise speech-to-text model yet. It is in public preview for developers in the Gemini API via Google AI Studio and Google Antigravity, and for enterprises via Gemini Enterprise Agent Platform, with Gemini Enterprise for Customer Experience listed as coming soon. Do not treat the APIs as generally available.
Google exposes two API paths:
| API path | Model ID (as named by Google) | Best for |
|---|---|---|
| Live API | gemini-3.5-transcribe-live |
Real-time bidirectional streaming; Google claims sub-second latency for interactive voice UX |
| Interactions / unary | gemini-3.5-transcribe |
Pre-recorded audio (meetings, call logs, voice notes) with speaker attribution and word-level timestamps |
Capabilities Google highlights include smart transcription (self-corrections, filler-word removal, auto-format), custom vocabulary, 85+ language auto-detect, and multi-speaker attribution. The official model card supports diarization on unary (3+ speakers experimental) and word-level timestamps on unary only; caching, Batch API, Flex/Priority inference, thinking, and function calling are not supported on the Transcribe API models. Function calling in the Gemini macOS app is a product feature—do not assume it in your API build.
Google-cited accuracy (Artificial Analysis / FLEURS): average WER 4.0% streaming / 2.6% non-streaming, FLEURS top-locale set 5.50% / 5.04%, and 70% faster time-to-final versus Chirp 3. Those are vendor-reported—not Softix measurements for your noise floor or accents.
Consumer surfaces (Google plus Ars Technica and 9to5Google): Gboard Rambler on Android (rolling out; Ars notes Pixel 11 first), Gemini app on macOS (English), Antigravity with screen context when permitted, AI Studio Build mode, and Chrome talk-to-type coming soon.
The Softix Voice Surface Stack
Before you open a ticket for “add Gemini Transcribe,” place the work in one of three layers. Softix calls this the Voice Surface Stack—a simple filter so SMBs do not rebuild what the OS already ships, or stream regulated audio into a preview API by accident.
Layer 1 — Consumer surface (keyboard / browser / Gemini app)
Use when: staff or end users only need to dictate into fields already on their devices—notes, CRM comments, email drafts, ticket replies.
Prefer: Rambler / Gboard, Gemini on macOS, and Chrome talk-to-type when it ships. You ship almost no backend, no recording store, and no transcription vendor contract.
Do not use Layer 1 when: you need branded voice UX, custom vocabulary tied to your SKUs, speaker labels in a multi-party call you own, retention policies you control, or offline/air-gapped constraints.
Layer 2 — Product feature (voice UX inside your app)
Use when: voice is part of the product: in-app dictation with your glossary, live captions, field-service voice notes that must land in your system of record, or a guided workflow where partial transcripts drive UI state.
Prefer: Live API (gemini-3.5-transcribe-live) for interactive flows; unary gemini-3.5-transcribe when the user finishes a recording first. The model card lists a 10-minute Live session max and up to 1 hour unary (30 minutes when diarization or word timestamps are on)—design chunking around those limits.
Build work: consent UI, mic permissions, streaming vs upload, custom vocabulary, empty-transcript fallback, and store transcripts by default—not raw audio—unless you have a documented reason to keep recordings.
Layer 3 — Ops pipeline (meetings / support / QA analytics)
Use when: you already record calls or meetings under a lawful basis and need searchable text, speaker labels, or QA sampling—not a live mic button in the customer UI.
Prefer: unary transcription on files you already store (or that never leave your VPC except as a short-lived upload). Keep Layer 3 out of the product critical path until preview stability and contracts catch up.
If you are choosing between “teach users Rambler” and “rebuild half your product around Live API,” start at Layer 1 unless Layer 2 is a named roadmap bet with budget for privacy review.
Consumer surface vs product API vs ops: a quick comparison
| Decision | Layer 1 Consumer | Layer 2 Product API | Layer 3 Ops pipeline |
|---|---|---|---|
| Who owns the mic UX | Google / OS | Your app | Recorder / CCaaS / meeting tool |
| Custom vocabulary for your catalog | Limited / none | Supported (biasing; Google suggests best results with up to ~100 of the allowed terms) | Supported on unary |
| Speaker labels | N/A for single-user dictation | Live: not supported; Unary: yes (3+ experimental) | Unary |
| Latency need | Human typing replacement | Sub-second interactive (Google’s claim for Live) | Batch / async OK |
| Preview risk in your SLA | Low (user’s device) | High—own fallback | Medium—queue and retry |
| Typical Softix build size | Docs / training | App + API + privacy | ETL + retention + access control |
Google-named Live API partners (Agora, Fishjam, LangChain, LiveKit, Pipecat, Vercel, Vision Agents) help if you already run real-time media through one of them—they are optional for a direct Gemini API call.
Pricing: use Google’s list, then re-check before you budget
On the Gemini API pricing page (paid tier, per 1M tokens, USD, as published for these models):
gemini-3.5-transcribe-live: input $3.50 (or Google’s ~$0.005/min audio estimate); output $21.00 (or ~$0.004/min text). Google’s footnote blends those to about ~$0.009 per audio minute (25 audio tokens/sec in, 175 text tokens/min out).gemini-3.5-transcribe: input $2.00 (or ~$0.003/min); output $12.00 (or ~$0.002/min); blended about ~$0.005 per minute.
Free tier is listed as free of charge. Google states data may be “used to improve our products” on Free and not on Paid—confirm current wording before putting customer audio on a free key. These are published list prices; re-check before budgeting. Softix is not quoting your monthly cost.
Privacy: ship voice without leaking recordings
Treat every recording as sensitive by default. Practical SMB defaults (not legal advice—confirm with counsel and your Google contract):
- Prefer transcripts over audio retention. Discard or never persist WAV/MP3 after a successful job unless you have a documented reason to keep recordings.
- Files API lifetime. Google’s Files API docs: uploads are temporary and expire after 48 hours (delete earlier when done). Do not use Files API as your system of record.
- Interactions
storeand Live resumption. Google’s ZDR guidance: setstore=falseto opt out of default Interactions state retention; leave Live session resumption off unless you accept up to 24 hours of retained session state (including audio). - Paid vs free. Prefer paid/enterprise for customer or employee call audio; avoid free-tier keys for regulated recordings.
- HIPAA / PCI / BAA. Do not assume this preview model is certified for your workload. Confirm current Google terms and BAAs; redact before egress when required. Softix will not invent a compliance badge.
- Consent and verbatim needs. Clear mic notice; call analytics need an agreed recording policy. Smart transcription rewrites disfluencies—Ars notes cleaned wording may be wrong for legal/clinical verbatim use. Offer verbatim when the use case demands it.
Preview reality: plan for silent failures
Public preview means quotas, docs paths, and edge cases will move. A Google AI Developers Forum thread dated 28 August 2026 reports HTTP 200 responses with empty transcriptions and zero output tokens on some REST / Interactions paths, while the same audio transcribed via other Gemini models. Treat that as a developer-reported issue, not a Google confirmation—and still design for it: check output length, retry with backoff, and keep a fallback (second model, human review queue, or “type instead” UI) before you put Live Transcribe on a revenue path.
90-day SMB plan
Days 1–30 — Pick one workflow and one layer
- One-sentence workflow (field-tech notes = Layer 2; support-call search = Layer 3; faster typing in Chrome = Layer 1).
- If Layer 1 is enough, stop building—train on Rambler / Gemini macOS / Chrome when available.
- If Layer 2 or 3, choose Live vs unary; document model-card audio limits.
- Privacy checklist: consent copy, paid billing,
store=falsewhere needed, Files API delete-on-success, no Live resumption unless required. - Spike in AI Studio; log empty-transcript rate for a week.
Days 31–60 — Harden
- Custom vocabulary for the 20–100 terms that actually break (SKUs, names)—not the whole catalog.
- Fallbacks: empty-output detection, alternate model/queue, “try again / type” UI.
- Retention in your DB: transcript TTL, who can access audio (ideally nobody), encryption, DSAR export.
- Add a realtime media partner only if it cuts your WebRTC burden—not because it was named in a press list.
Days 61–90 — Build vs buy
- Keep a thin integration if accuracy on your pilot audio and privacy posture are clear.
- Buy a voice/CCaaS vendor when you need contact-center packaging, on-prem, or SLAs preview cannot offer.
- Custom-build the app shell (web / mobile UX, permissions, glossary admin, audit log)—not a from-scratch ASR model.
- Revisit GA status, pricing, and residency before expanding past the pilot.
Risks and limits
- Preview ≠ production SLA. Silent empty responses can break UX without a 5xx.
- Smart cleanup changes wording. Good for dictation; bad for verbatim compliance.
- Diarization. Do not promise perfect labels on large calls; 3+ attribution is experimental.
- Live length. Design for the documented 10-minute Live cap (chunk/reconnect).
- Cost. Meter in staging; Google’s per-minute estimates are a starting point only.
- Not a full voice-agent stack. Tool use and barge-in are a different architecture—see Softix’s OpenAI voice deep dive when that is the problem.
FAQ
Should every SMB rebuild around Gemini 3.5 Transcribe?
No. Many teams only need Layer 1. Move to Layer 2 when voice is a multi-year product bet—not because a model launched this week.
Live API or unary?
Interactive mic/captions → Live. Existing files, speaker labels, word timestamps → unary. Use a second unary pass only if Live cannot supply the labels/timestamps you need.
Is it HIPAA-ready out of the box?
Softix will not claim that. Confirm Google’s current enterprise terms, BAAs, and your redaction pipeline before PHI audio leaves your systems.
How is this different from Softix’s OpenAI voice article?
The May 2026 post is an architecture deep dive for low-latency voice agents. This article is a where-to-put-it brief for Gemini 3.5 Transcribe’s preview APIs and Google consumer surfaces.
What to do next
Spike one workflow: paid API access, privacy defaults on, and a written empty-transcript fallback—not a six-month “voice transformation” program.
Softix builds the application layer around speech APIs—consent, capture, glossary admin, retention—without turning every announcement into a rebuild. Contact us with your stack, live vs recorded needs, and what must never leave your environment.
Share


