The Voice Design docs say stored voices have “a 1-year TTL” (Voice design), but not what happens at expiry or whether a voice can be kept longer. For any long-lived use (audiobooks, games, series, a brand voice), a voice has to stay identical for years, since new lines are added long after the first ones.
I tested what the API currently allows on gemini-3.8-flash-tts:
Using a voice does not extend it. A prompted voice’s expire_time was exactly create + 365 days. Reads (GET /v1beta/voices/{id}) and synthesis with the voice (generateContent, voiceConfig.voice) left expire_time unchanged, to the nanosecond: immediately, and again 24 hours later.
It can’t be renewed or set. The Voices API has only Create / List / Get / Delete, and expire_time is output-only. store: false is refused for prompted voices.
The same brief does not recreate the voice. Designing the identical brief (same model, gender, language, description) three times gave three different voices. One line spoken with a fixed seed and temperature is byte-identical twice on the same voice, but differs on each of the three, with a clearly different timbre.
Voice design takes no seed.voice.prompted.seed and voice.seed both return 400 Unknown parameter 'seed'.
Nothing portable is returned.GET gives the brief, model, gender, language, sample audio and expire_time, and no embedding or other representation that could be stored and reused.
Replication doesn’t cover it, since it requires a real speaker’s consent recording.
So a designed voice appears to be guaranteed to disappear after a year, with no supported way to bring it back.
Questions
What happens at expire_time? Is the voice deleted, or does synthesis just stop? Is it recoverable?
Is there, or will there be, a way to extend or renew a stored voice (an update method, renewal on use, a longer TTL)?
Is longer or non-expiring retention available on paid tier, Vertex AI or Enterprise?
Will voice design get a seed, so the same brief + seed reproduces the same voice?
Until one of 1–4 has an answer, prebuilt voices (which don’t expire) seem like the only safe choice for anything long-lived, which is a pity given how good Voice Design is.
Hi @Awendel! Thank you so much for your feedback on the newest TTS models. Here to answer your questions and please let me know if there are any other that come up.
The created voices will expire after 1 year of non-use. So as long as you are using the voices, they should not expire. Non-use is defined as:
No Downloads: The synthesized audio files generated by the Voice ID (or the base model weights, if applicable) have not been downloaded, exported, or streamed.
No API Reading: There have been no successful GET requests to retrieve the Voice ID’s profile, status, or structural metadata
We will get the API docs updated to make this clear.
As long as the voice is used, then you should be able to continue extending the TTL.
Not at the moment, but base on 1 and 2, let us know if that doesn’t satisfy you requirement
Voice design is non-deterministic, though should be consistent most of the time. I will put the seed parameter on our roadmap for consideration.
The saved voice should continue to work as long as it’s saved
Thanks so much, @Alisa_Fortin ! That’s great news, and a lot better than I’d feared.
One thing confused me, though. I’ve been keeping an eye on a test voice (voice_zgrkkm048eb1, created on 24 September). I’ve fetched it and used it several times since, but its expire_time hasn’t changed at all. It still says exactly one year after the day I created it. So I’m not sure which to believe: the field, or the “one year of non-use” rule.
A few follow-ups, if that’s okay:
Can we see the renewal? It would be really reassuring if expire_time moved forward when a voice is used, or if there were a “last used” field. Then we could check that our voices are safe instead of just hoping.
What happens if a voice does expire? Is it gone for good straight away, or is there a warning or a grace period first?
What about future models? When gemini-3.8-flash-tts is eventually replaced, will voices designed on it carry over and sound the same? If not, the obvious fallback would be to record a sample of the voice on 3.8 and replicate it on the new model. But replication currently rejects synthetic audio (I tried it with a designed voice and got “Voice replication failed safety checks”). Could replication accept voices that Gemini itself designed, at least within the same project?
Can the limit of 200 voices per project be raised? I imagine it would be a blocker for companies that want to let their users design their own voices.
And thanks for putting the seed on the roadmap. When I designed the same description three times I got three quite different voices, so right now a lost voice can’t be brought back. A seed would fix that.
Expire time: Would you be able to check again? We’ve actually just deployed a fix for this a couple of days ago so now you should see the expire time change.
For the follow ups:
This should move forward now
It would be gone, there isn’t a grace period. I think the grace period is the year of non-use, but we’ll look into providing some warning.
The voices will carry over from model to model.
Can you help me understand the use cases for more than 200 voices per project? We have 2K presets voice library, but 200 voices we’re limiting for more personal/startup use right now - we will look into extending that later as we see clear demand.
Thanks, @Alisa_Fortin ! I checked again and it works now. After generating one line with the voice, expire_time jumped to exactly one year from that moment.
One small thing: plain GETs don’t seem to move it. I read the voice before and after generating, and only the generation reset it. Does a GET still count as use, or is generating audio the way to keep a voice alive?
Thanks also for the answers on expiry and model carry-over, that clears up a lot. A warning before a voice expires would be great.
On the 200 limit: it’s mainly any app whose end users would want to design their own custom voices. With many users, 200 per project would run out quickly.
Related idea: exportable designed voices. Once an app ships a designed voice (a character, a narrator, a brand voice), it becomes part of the product. Today, losing it is permanent: there’s no grace period, the same description designs a different voice, and replication refuses synthetic audio. That risk is likely the main thing that makes companies hesitate to build products on designed voices.
A simple fix: let designed voices return an opaque, encrypted voice key, the way replication already does with store: false. Ideally the key wouldn’t expire, and it would work in other projects, at least within the same organization (say, moving from a development project to production, or to Vertex).
Cheap to build: the mechanism already exists for replication.
Safe: the key only works through the Gemini API, so no voice data leaves Google, and safety checks still apply when audio is generated.
Good for Google too: exported voices need no storage, so the 200 limit matters much less. They also need no expiry warnings or support around lost voices, and designed voices become much safer for developers to adopt. Other providers already let you reproduce a designed voice from a seed, so this would close that gap.
Smallest useful version: being able to restore a voice into the same project after it expires, or copy it into another project, would already cover most cases.