Prompt-to-voice makes voice design look like a prompt-writing task: describe the sound you want, create a saved voice, and reuse its ID in a live session. The API call is simple. The release decision is not.
OpenAI made prompt-to-voice generally available to all API customers on October 16, 2026. Its custom voices guide documents a text-description path for GPT-Live and a separate recording-based path for eligible customers. A production team still owns the product questions around identity, disclosure, evaluation, data handling, rollback, and whether a generated voice is appropriate for the audience.
This guide focuses on the prompt-generated path. It does not treat a synthetic voice as a human identity, and it does not replace legal, accessibility, localization, brand, or safety review.
Separate voice design from agent behavior
A voice-description prompt controls perceived vocal qualities such as accent, pitch, timbre, texture, loudness, pace, presentation, and distinctiveness. It does not define what the assistant may do.
Keep two contracts:
- Voice contract: the intended adult voice, listening conditions, languages, pronunciation rules, synthetic-voice disclosure, and prohibited resemblance targets.
- Conversation contract: the assistant's role, allowed actions, tool policy, confirmation requirements, escalation path, interruption handling, and response style.
The current GPT-Live guidance recommends keeping the live conversation prompt short and placing detailed workflows in the backend. Include the original voice description in session.instructions to reinforce performance, but do not bury authorization or business rules inside a paragraph about tone.
Record a voice intent before generating
Start with a small release brief rather than an adjective pile.
voice_intent:
use_case: "Order-status assistant"
audience: "Adults calling a US support line"
languages: ["en-US"]
qualities:
accent: "light American English"
pitch: "mid-range"
timbre: "warm and clear"
pace: "steady and conversational"
effort: "moderate"
must_avoid:
- "Imitating a named person or fictional character"
- "Sounding like a child"
- "Masking that the caller is hearing synthetic speech"
disclosure: "Say that this is an AI-generated voice at the start of the call."
Use observable qualities. "Trustworthy" is a product aspiration, not an acoustic specification. A clearer request names pace, pitch, timbre, vocal effort, accent, and the setting in which listeners must understand the result.
OpenAI's current rules say prompt-generated voices must be adult voices, must not imitate named people, and should be disclosed as AI-generated speech. They are not guaranteed to be unique. Similarity testing therefore belongs in the release process even though the prompt path does not use a reference recording.
Create a candidate without turning generation into approval
The API accepts type: "prompt", a name, a plain-language prompt, and model: "auto". An optional script_hint can provide up to 2,000 characters of representative speech.
curl --fail-with-body https://api.openai.com/v1/audio/voices \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"type": "prompt",
"name": "Order status assistant candidate 03",
"prompt": "A warm adult voice with a mid-range pitch, clear timbre, moderate vocal effort, and a steady conversational pace. Speak American English with a light accent and avoid exaggerated character performance.",
"script_hint": "Thanks for calling. I am an AI-generated voice assistant. I can check an order, explain a delivery update, or connect you with a person.",
"model": "auto"
}'
Each successful request creates a new saved voice. The response returns metadata and a voice ID, not a preview. OpenAI currently limits prompt-generated voices to 100 per organization. Treat the voice ID as a deployable configuration value: keep it out of client-controlled input, map it to an approved release record, and remove abandoned candidates deliberately.
Creating a prompt-generated voice is currently free, while listening to it uses a billed GPT-Live session. Pricing and limits can change; read the live documentation instead of embedding them as permanent product assumptions.
Bind the approved voice to a new session
Prompt-generated voices currently work with GPT-Live. They do not work with the Text to Speech API, Realtime API, or Chat Completions audio output. Choose the voice when the live session starts; after audio has been emitted, start a new session to try a different voice.
{
"model": "gpt-live-1",
"instructions": "You are an order-status assistant. Tell the caller that this is an AI-generated voice. A warm adult voice with a mid-range pitch, clear timbre, moderate vocal effort, and a steady conversational pace. Speak American English with a light accent and avoid exaggerated character performance.",
"audio": {
"output": {
"voice": { "id": "voice_approved_2026_10_20" }
}
}
}
Keep the approved voice ID, voice prompt, conversation-prompt version, backend workflow version, and disclosure copy in one release manifest. A voice change can affect perceived meaning even when the words and backend remain unchanged.
Evaluate the listener experience
Do not approve a candidate from one polished sample. Use fixed scenarios and repeat them across listening conditions.
| Scenario | What to inspect |
|---|---|
| Opening disclosure | Audible, early, understandable, and not rushed |
| Names, dates, addresses, and numbers | Pronunciation, grouping, correction, and confirmation |
| User interruption | Stops cleanly, listens, and resumes without talking over the caller |
| Long backend wait | Gives an honest acknowledgment without inventing progress |
| Tool failure | Keeps the same identity and escalates without sounding falsely certain |
| Emotional user | Remains clear without imitating or manipulating the caller's emotion |
| Noisy or low-bandwidth audio | Preserves intelligibility and does not accelerate unpredictably |
| Locale change | Uses only supported languages and does not drift accent into language choice |
Use the same scripts and representative conversations for every candidate. Change one vocal quality at a time when refining the description. Collect structured ratings for intelligibility, consistency, appropriateness, disclosure recall, unwanted resemblance, pronunciation, interruption recovery, and task success.
Voice quality is only one gate. Run the ordinary agent evaluation suite for tool correctness, confirmations, authorization, refusal, escalation, latency, and task completion. The voice surface changes the interaction; it does not relax the backend's safety contract.
Test identity and disclosure risks
Have independent reviewers answer these questions before release:
- Does the voice resemble a known person, employee, customer, celebrity, or protected character closely enough to create confusion?
- Could the name, avatar, script, or marketing copy imply a human speaker even when the audio alone does not?
- Is the synthetic-voice disclosure present at the first meaningful interaction and repeated when context requires it?
- Are provenance metadata, watermarks, or other origin indicators preserved wherever the product can retain them?
- Can a user reach a human or switch to a non-voice channel when the voice interaction is unsuitable?
Treat a credible resemblance concern as a stop condition. A prompt that avoids a named person can still produce an output that listeners associate with one.
Review data handling before the first production call
OpenAI documents an important boundary: creating voices through /v1/audio/voices is not compatible with Zero Data Retention. GPT-Live speech generation can be eligible for Zero Data Retention when enabled, while stored session recordings, recording downloads, and session forking are not available under that setting.
Map the whole flow rather than labeling the product "zero retention" based on one stage:
- voice-description prompt and optional script hint
- saved voice metadata and ID
- live audio and transcript events
- application logs, analytics, support exports, and recordings
- backend requests, tool results, and side-effect receipts
- reviewer notes and evaluation artifacts
Do not put secrets, customer records, or unnecessary personal data in a voice description or script hint. Set retention and access rules for evaluation audio before collecting it.
Release with a reversible manifest
A production voice release should identify:
- approved voice ID, name, creation date, and owner
- exact voice prompt and script-hint hash
- intended products, locales, audiences, and environments
- conversation prompt and backend workflow versions
- disclosure copy and where it is emitted
- evaluation suite, reviewer sign-off, and known limitations
- data-retention decision and recording policy
- rollout percentage, monitoring thresholds, rollback voice, and kill-switch owner
Canary the voice with a narrow audience. Watch task success, escalation rate, abandonment, interruption failures, latency, complaints, disclosure recall, and unexpected resemblance reports. Roll back by starting new sessions with the prior approved voice; do not try to change the voice inside an active session.
Know when recording-based custom voices are different
The recording path is a separate product and governance decision. OpenAI currently requires an approved consent recording and a matching short sample, limits access to eligible customers, and supports those voices on more audio surfaces than prompt-generated voices.
Do not reuse the prompt-generated release record as proof of speaker consent. A description-generated voice has no source speaker to consent; a recording-based voice does. Preserve the consent artifact, actor identity verification, permitted uses, revocation process, and sample lineage for the recording path.
Release checklist
- The product has separate voice and conversation contracts.
- The voice description uses observable adult vocal qualities and names prohibited resemblance targets.
- The candidate voice ID is tied to an approved, versioned release manifest.
- Prompt-generated voice use is limited to a supported GPT-Live session.
- Disclosure is audible, early, tested, and consistent with surrounding product identity.
- Fixed listening tests cover pronunciation, interruption, noise, failures, and escalation.
- Independent reviewers checked unwanted resemblance and accessibility concerns.
- Data retention is mapped separately for voice creation, live sessions, application logs, and recordings.
- A canary, monitoring thresholds, fallback voice, and kill switch are ready.
- Recording-based voices use their own consent and provenance evidence.
Prompt-to-voice shortens the distance between an idea and a usable synthetic voice. A trustworthy release still depends on the work around that API call: explicit intent, honest disclosure, repeatable listening tests, backend safety checks, careful retention choices, and a rollback path listeners never have to discover the hard way.
