Gemini 3.8 Flash TTS models go GA with voice design, cloning and per-sentence control

Google ships two new speech models

According to a dev.to post, Google's Gemini API release notes dated September 22 mark Gemini 3.8 Flash TTS and Gemini 3.8 Flash-Lite TTS as generally available. The pair splits the workload: gemini-3.8-flash-tts is the flagship, aimed at vocal performance and character work with control over delivery on individual sentences, while gemini-3.8-flash-lite-tts is positioned for cheap, fast generation at high volume.

Voice design, cloning and line-level direction

The author singles out three additions that matter in practice:

• Voice design describes a speaker in plain language — the post's example is a warm-toned older astronomer with a British accent — and returns a persistent voice_id for reuse.
• Voice replication clones a person from a 10 to 30 second recording. The owner must record a consent statement, and generated audio carries a SynthID watermark and C2PA provenance markers.
• Performance control attaches a style instruction to each chunk of text, such as slowing the pace and enunciating every syllable, alongside inline tags for laughs and sighs, and it can voice a two-person dialogue.

The call structure has moved on from generate_content. Speech now runs through two API surfaces: voices, which creates and stores a voice once, and interactions, which turns text plus style metadata into audio referencing that voice.

Specs, limits and unknowns

Details from the post worth checking before a build:

• Output is 16-bit mono PCM WAV at 24 kHz, with streaming supported.
• Over 100 languages are covered, including Simplified Chinese, Traditional Chinese and Cantonese; Taiwanese was not listed.
• A project can keep up to 200 custom voices for a year, or use a self-managed voice key valid for seven days.
• Voice replication is unavailable in Illinois, Texas, the EEA, the UK, Switzerland and India.
• No pricing appears in the announcement or the documentation.
• Tier 1 accounts are capped at 100 requests per day, which became the binding constraint during the author's testing.

A language-learning app as stress test

Rather than demo the TTS in isolation, the author built a web app for learning Japanese and Korean from music videos, with three Python scripts behind a Next.js front end.

transcribe.py hands a YouTube music video URL to the standard gemini-3.8-flash model and requests structured output: start and end times, the original text, hiragana readings and an uncertainty flag per line. The key prompt instruction is to prefer on-screen lyric subtitles over the audio, since transcribing singing — with accompaniment, held notes and harmonies — is far harder than speech, and Japanese homophones add ambiguity. Tests on Yuuri's Betelgeuse and Christmas Eve and Take That's Back for Good produced clean structure — no empty lines, no backwards timestamps, no endlessly repeated sentences — though every line was flagged as certain even when transcribed from audio alone.

annotate.py adds translation, word-by-word breakdowns, grammar notes and pronunciation tips, calling the model only for unique sentences and cutting roughly 30 to 40 percent of requests because choruses repeat. speak.py then demonstrates each sentence at normal and slow speed using the new TTS voices.

Where libraries beat the model, and where they fail

The phonetics pipeline exposed weaknesses in established tools. pykakasi transliterates the Japanese particle は as ha when it is pronounced wa, because kana alone does not reveal its grammatical role. A Korean romanizer produced gamsahapnida for 감사합니다, missing the nasalization that the official revised standard renders as gamsahamnida. The compromise splits duties: the language model handles segmentation and part-of-speech tagging, while the program converts readings to romaji and corrects the particles は, へ and を based on those tags.

Copyright handled up front

The lyrics flow received deliberate legal treatment. The author reasons that transcribing lyrics with AI does not change their status as protected text, and publishing them alongside translations — legally a derivative work — would carry infringement risk. The app therefore keeps lyric files in a local output folder excluded from version control from the first commit, and the coding assistant was instructed to print only statistics, never the lyrics themselves, during development.

Why it matters

The release reframes text-to-speech as a directing problem rather than a narration one: cast a voice from a description, clone a consenting speaker, script the tone of each line. The mandatory consent recording, watermarking and regional carve-outs suggest Google is trying to make cloning auditable, not merely available. For developers, the open questions are practical — undocumented pricing and a 100-request daily cap make production costs unknowable from the docs. The dev.to build also shows a pattern likely to recur in speech apps: use language models for understanding and generation, but keep deterministic tools and explicit corrections in the loop where both libraries and model confidence fall short.