Google shipped two text-to-speech models on 23 September 2026, Gemini 3.8 Flash TTS and Gemini 3.8 Flash-Lite TTS. The announcement is a good one: voices designed from a natural-language prompt, performance directed line by line, consent verification on voice replication, and a watermark on every clip.

This is a capability-versus-card reading. The announcement post and the developer documentation were published by the same company about the same models, and where they disagree, the documentation is the one you will be held to. Four places are worth knowing before you plan a project around either model.

What actually shipped

Two models, same API schema and prompting format, switchable with one parameter.

Flash TTS is the creative tier: “studio-grade voice fidelity, expressive acting, authentic regional accents, and rock-solid long-form multi-turn stability.” Flash-Lite is “built for high-volume, cost-efficient scale.”

The genuinely new capability is voice design. You describe a voice in words and get one, rather than picking from a list. Google’s examples are a high-energy DJ from Melbourne, a “super-tinny, monotone robot”, and a Japanese dragon. Alongside it, voice replication recreates a voice from “just a 30-second audio sample”, gated on consent: “users must provide a verbal consent recording from the voice owner that matches the reference speaker before a voice can be created.”

Every generated clip carries a SynthID watermark, described as “woven directly into the audio output”. Both claims are in the announcement and both are unambiguous, which is worth saying plainly before the rest of this piece gets sceptical.

One: infinite, then 200

The announcement’s framing is “Scale up from 30 original voices to an infinite library.”

The documentation sets the actual ceiling. Stateful voices, which covers both designed and replicated ones, are capped at “Maximum of 200 voices per project with a 1-year TTL”. Stateless voice keys get a 7-day TTL.

Both statements are true about different things. You can generate an unbounded number of voices; you can keep 200 per project, and only for a year. For a games studio with a large cast, or a dubbing house with a voice per client, that is the number that matters, and it is not in the announcement.

Two: 100 languages or 130

The announcement says the models work “across more than 100 languages and dialects”, and repeats “With support for over 100 languages”.

The model documentation is more specific, and higher for one model: Flash TTS “supports over 130 languages”, Flash-Lite “over 100”. The model comparison table states 130 and 101.

This is the rare case where the marketing figure understates the product. Worth noting because it cuts against the assumption that the announcement always rounds in its own favour. It also means anyone quoting “100 languages” for the flagship is quoting the conservative number.

Three: two-speaker staging, with a condition

“Native two-speaker scene staging” is listed as a feature: direct multi-turn conversations “seamlessly from a single script”.

The documentation’s limitations section adds the qualifier that decides whether this fits your use case. Single-request multi-speaker generation “supports up to 2 speakers using prebuilt voices”. Custom or replicated voices are excluded from that path: to use them in multi-character dialogue you “synthesize each speaker’s turn individually”, then handle the audio yourself, because “unary requests return audio/wav with a 44-byte RIFF header by default”, so you must “request raw PCM” or “strip the WAV header from each turn before concatenating the 24kHz PCM audio frames”.

So the two headline features, designed voices and two-speaker scenes, do not compose in a single request. A podcast with two custom voices is a stitching job, at the level of stripping RIFF headers. That is an afternoon of work rather than a blocker, but it is not what “seamlessly from a single script” suggests.

Four: the prompting style that used to work now reads aloud

This is the change most likely to break existing code, and it appears only in the migration notes.

Gemini 3.8 TTS “treats input text strictly as a verbatim transcript.” Directions written inline, the way earlier models accepted them, are no longer interpreted: “Inline text directions like ‘Say cheerfully: Hello!’ or ‘Speaker 1: Hello!’ may be spoken aloud.” Sustained delivery instructions now belong in a structured speech_metadata field instead.

The documentation goes further and says the old habit actively degrades output. Long “Audio Profile” paragraphs and multi-bullet “Director’s Notes” carried over from earlier models “are the most common cause of voice drift”. Instructions intended to stabilise the voice make it worse: do not tell the model to hold the voice steady, because “extra prompt text increases drift”.

That is a real inversion. Prompt engineering for stability, which is what a careful user would try first, is the thing to stop doing.

The benchmark claims, and who owns them

The announcement reports Flash TTS taking “the #1 overall spot on Hume AI’s Voice Design Benchmark (71.4)” and leading accent modeling at 60.8, with both models at #1 and #2 on Hume AI’s Overall Quality Index. It also cites “blind human preference evaluations on Voice Arena” placing them top in Japanese, Brazilian Portuguese, Vietnamese, Modern Standard Arabic, Mexican Spanish and Hindi.

These are third-party benchmarks, which is better than an internal eval, and they are named rather than gestured at. Two limits on how far they carry. The numbers are quoted from Google’s post and were not independently confirmed against Hume AI’s or Voice Arena’s own published results for this piece, so they are reported here as Google’s claim. And a voice-design benchmark scores whether a model produces the voice a prompt asked for, which is not the same question as whether a listener finds it pleasant over a two-hour audiobook.

The long-form stability claim, “minimal speaker drift” across “hours of continuous audio”, is the one most worth testing yourself, because it is the one the documentation immediately qualifies with advice about what causes drift.

What to do with this

If you are choosing a model: Flash TTS for dialect coverage and acting, Flash-Lite for volume. The API is identical, so the decision is reversible.

If you are planning a catalogue of voices: design against 200 stored per project and a one-year TTL, not against “infinite”.

If you are building multi-speaker audio with custom voices: budget for per-turn synthesis and audio concatenation.

If you are migrating: strip inline stage directions before they get read out loud to your users, and delete the paragraphs of vocal guidance that earlier models rewarded.

The announcement and the documentation are both honest. They are written for different readers, and only one of them tells you where the walls are.