On October 16, OpenAI released prompt-to-voice to all API customers: you describe a voice in text, the API generates and saves it, and you reuse it in GPT-Live sessions. That is the whole feature, and it is worth understanding precisely, because one boundary decides whether it is relevant to your product at all. Prompt-generated voices work with GPT-Live. They are not supported by the Text to Speech, Realtime, or Chat Completions APIs. If your voice pipeline runs on any of those three surfaces, this release does not reach you, no matter how good your description is. The boundary, not the prompt, determines availability.
Everything below is drawn from the official API changelog and the custom voices guide, with the usual instruction to verify against those pages as they stand when you build.
What was announced
The changelog entry for October 16 is compact enough to quote:
Released prompt-to-voice for all API customers. Create a custom voice from a text description through the API or voice Playground, then reuse it in GPT-Live sessions. Creating a prompt-generated voice is free; speech generation uses regular GPT-Live session billing.
The entry lists the surfaces it touches: model gpt-live-1, and the APIs v1/audio/voices and v1/live/sessions. On billing, read the official sentence literally: creating a prompt-generated voice is free, and using it to generate speech in GPT-Live is billed at regular session rates. Nothing about that sentence promises what a session costs, and this article makes no price claims beyond it.
The same changelog entry adds nine natural voices for GPT-Live, grouped by language exactly as published: Nuri, Juni, and Flitz (German); Brise and Sillage (French); Nira (Hindi); Harema and Shida (Japanese); and Noeul (Korean).
The boundary, in the guide's own words
The custom voices guide states the limitation without hedging:
Prompt-generated voices work with GPT-Live. They aren't supported by the Text to Speech, Realtime, or Chat Completions APIs.
That sentence is the article. A team building a TTS pipeline, a Realtime voice agent, or audio output over Chat Completions cannot swap in a prompt-generated voice; the feature simply is not wired to those surfaces. If you were hoping to describe a voice once and use it across every audio endpoint, the answer today is no, and planning around "surely it will come" is not a migration strategy.
Two paths to a custom voice, and which one crosses the boundary
The guide describes two ways to create a voice, and they are not interchangeable:
| Path | What it needs | Where the voice works |
|---|---|---|
| From a description | A text description of the vocal qualities; no reference recording and no consent recording | GPT-Live only |
| From a recording | A consent recording and a short reference sample | GPT-Live, the Text to Speech API, the Realtime API, or the Chat Completions API with audio output |
The second row is the escape hatch for multi-surface products, and its requirement is not a formality: a consent recording is part of the deal. If your use case spans TTS or Realtime and you need a custom voice, that is the path to evaluate, with the consent workflow treated as a product requirement rather than paperwork.
How creation actually works
The mechanics are small enough to keep in your head. Send a JSON request to /v1/audio/voices with type set to prompt, a name, the voice description in prompt, and model set to auto in the official example. Optionally include script_hint, an example script that guides generation; if you omit it, the service generates a script from your description. Each successful request creates a new saved voice and returns metadata including its id, created_at, and the original description. The response contains no audio and no preview, so auditioning happens by using the voice, not by downloading a sample.
To use the voice, pass it at session creation as an object such as { "id": "voice_123" } rather than a named-voice string, with model set to gpt-live-1. The guide notes that gpt-live-1 supports custom voices with English accents, and that an accent is requested through session.instructions (for example, "Speak British English"). Save the returned ID and keep the original description: the description is what you would use to regenerate a similar voice, and the ID is what your sessions reference. Because each successful request saves a new voice, submitting the same description twice produces two saved voices rather than updating the first; keep the IDs straight in your configuration inventory.
What the voice will not do, by policy
The guide's Responsible use section is short and load-bearing, so here it is, restated faithfully:
- Use voices responsibly. Do not impersonate others or violate the Usage Policies.
- Use adult voices. Children's voices are not allowed.
- Be transparent. Tell listeners the speech is AI-generated, and preserve provenance metadata, watermarks, or other indicators of synthetic origin.
- Voices are not guaranteed to be unique. Others may generate similar voices or output; output ownership rights remain governed by your agreement with OpenAI.
- Terms apply to your and your end users' use of prompt-to-voice.
Two of these have engineering consequences. Transparency is not just a sentence in a policy document; if you strip provenance metadata on the way to your users, you have removed the indicator the guide asks you to preserve. And uniqueness is explicitly not promised, so a voice is an aesthetic choice, not a brand asset you can defend by having generated it first. Read the five points as compliance requirements your product has to satisfy, not as advice: the transparency obligation in particular lands on your interface and your pipeline, not on the model.
The Live context it lands in
One day before the prompt-to-voice release, the changelog recorded a native Decisions integration in GPT-Live: your app can act while the user is speaking or react to what Live says, either by letting Live call Decisions directly through native delegation, or by triggering decisions as input or output transcript deltas arrive. Put the two entries together and the shape of the product is clear: Live sessions are where the voice lives, and where the application can act on what is being said. The voice is one component of that session, not a standalone audio asset.
How to validate before you ship
Five checks cover the failure modes that matter, and the first one is the boundary check:
- Confirm the integration actually runs on GPT-Live. If it does not, stop here and evaluate the recording path or an existing TTS voice instead.
- Generate the same description more than once and compare the results; a saved voice should be reusable, but the description-to-voice mapping is not a specification you can rely on being identical across runs.
- Audition each target language with the published voices, and with your generated voice where the language is supported.
- Exercise the session behavior that matters: interruptions, overlapping speech, and long answers.
- Keep one non-generated fallback voice configured, so a voice problem never takes the whole session down.
The verification discipline for prompt and model changes, including golden sets and shadow runs, is the same one this site applies to any user-visible change, and it is collected in the testing guide.
The checklist
- Confirm the pipeline is GPT-Live before planning around prompt-to-voice.
- Write the description, create the voice, and save the returned ID with its original prompt.
- Generate the same description multiple times and compare stability.
- Audition the target languages.
- Keep a fallback non-generated voice.
- Wire the transparency notice and preserve provenance metadata.
- Record the voice ID and description in your configuration inventory.
- Watch session behavior after launch, with the logging discipline from the observability guide.
One release, one sharp boundary, and a small set of obligations that follow the voice into production. For teams already on GPT-Live, October 16 added a way to shape the voice with language instead of samples; for everyone else, it added a reason to read the endpoint list before the announcement. Endpoint-level specifics for the compatible service this site documents live in its documentation, and the compatibility checklist is the right frame for asking which surfaces an endpoint actually implements. The operational side of running agent pipelines is covered in the CI guide, and as always, verify every behavior against the official pages current at build time.