I would choose an AI voice for clarity before character. A reassuring sound helps only when listeners understand the words and the assistant handles their request correctly. OpenAI’s prompt-to-voice makes vocal style easier to configure, but a useful voice application still needs clear conversation rules, verified actions, and a deliberate data policy.
OpenAI’s October 16 release notes announced text-described voices for API customers. This guide explains how a description becomes reusable configuration, how to connect it to GPT-Live, and what to check before using it with callers. A fictional help desk provides the examples; the emphasis is on understanding the workflow rather than memorizing acoustic terminology.
- Create a voice configuration, then hear it through a live session.
- Describe sound separately from conversation and action procedures.
- Evaluate pronunciation and task outcomes using the same examples.
- Count active duration, backend usage, and application data separately.
First, understand what a voice ID represents
A voice ID is a reference to a saved voice configuration. Think of a reusable style preset: the application remembers which voice to select, while each new conversation brings different words and context. The analogy explains reuse; it does not describe OpenAI’s internal synthesis architecture.
Read Figure 1: follow creation from left to right, then distinguish the saved ID from the conversation that uses it.
The custom-voice guide documents a JSON creation request with type: "prompt". Its response contains metadata rather than an audio preview. The optional script_hint supplies representative speech to guide generation. This public interface explains what the application sends and receives; it does not expose the model’s internal acoustic processing.
For the fictional Harbor Help desk, an everyday goal might be “clear adult voice, warm tone, moderate pace.” Those words are design inputs. The practical question is whether a caller can distinguish “fifteen” from “fifty,” follow an address, and interrupt a long answer. A distinctive voice that fails those checks is a poor fit.
Separate how it sounds from what it does
Pitch means how high or low a voice sounds; timbre is its tonal character; cadence is the pattern of pacing and pauses. These are plain-language qualities in a description, not guaranteed numeric controls. “Warm” does not define a measurable frequency setting.
Read Figure 2: trace the two configuration inputs, then look at the separate action responsibility below them.
Keep the assistant’s role, short replies, interruption behavior and handoff conditions in session instructions. Put detailed task procedures and actual tool definitions in the backend—the part of the application that looks up records or changes them. OpenAI’s prompting guide assigns permission checks to the application.
For Harbor Help, “speak patiently” is a delivery choice. “Ask which booking the caller means” is a conversation rule. “Check authorization before changing that booking” is an application procedure. Putting all three in a voice description would make the configuration hard to review and would not establish that a requested change succeeded.
Choose a voice workflow before writing the integration
Read Figure 3: compare the required input and supported destination, rather than treating the options as a quality ranking.
An existing named voice is a useful baseline. A prompt-generated voice uses a written description and is supported in GPT-Live; it does not work in TTS, Realtime or audio Chat Completions. Recording-based custom voices use a separate eligible-customer workflow with consent and a matching sample. See the workflow requirements. Avoid assuming every custom voice ID works at every audio endpoint.
Named voices also have exact API names. The session guide identifies marin as the default and lists options including noeul for Korean. A language label is a starting point for listening, not proof that every product name or mixed-language sentence will be pronounced correctly.
A small configuration example
The following request body is an original example for POST /v1/audio/voices. Use a trusted application server for authenticated API calls. Keep the resulting ID with the description and a configuration version so a later change can be traced.
{
"type": "prompt",
"name": "Harbor clear guide",
"prompt": "An adult voice with a warm tone, clear articulation, moderate pitch, and a steady conversational pace.",
"model": "auto",
"script_hint": "Welcome to Harbor Help. I am an AI assistant. Which booking would you like help with?"
}Replace the placeholder below with the returned ID. Include the original voice description with your conversation instructions. Select the voice at session startup; changing to another saved voice requires a new session. WebRTC places this configuration in the creation request’s session field; WebSockets use the first session.start event. Follow the connection guide for the transport setup.
{
"model": "gpt-live-1",
"instructions": "You are Harbor Help, an AI assistant. Use an adult voice with a warm tone, clear articulation, moderate pitch, and a steady conversational pace. Keep replies brief. Ask for clarification when the booking is unclear. Refer booking changes to the application backend and wait for its verified result.",
"audio": {
"output": {
"voice": {
"id": "voice_REPLACE_WITH_SAVED_ID"
}
}
},
"store": false
}This fragment configures the conversation; implement the backend and connection as part of your application. Save the actual creation response, check startup errors, and verify that the selected voice is available to the application before accepting a call.
Full duplex makes interruptions a workflow concern
Full duplex means the model can listen and speak at the same time. That supports a more natural exchange when a caller interrupts. GPT-Live can delegate reasoning and tool use to a backend agent, as described on the model page. Smooth speech alone cannot confirm the state of a booking.
Read Figure 4: follow the event order across the speech and backend lanes. The waveform shapes are schematic.
Suppose the caller says “Tuesday—sorry, Wednesday” while an assistant is explaining Tuesday’s availability. The voice should yield and listen. Meanwhile, the backend must determine whether any operation is pending, completed or safe to change. A stopped audio stream does not answer that question. Have the assistant report the verified result and offer a clear escalation path when the request remains ambiguous.
Free creation does not make the conversation free
Creating a prompt-generated voice is free, and the documented organization limit is 100 such voices. A listening preview runs a billed GPT-Live session. For budgeting, use the actual session duration rather than the length of the assistant’s spoken clips.
Read Figure 5: the horizontal axis is active minutes; the vertical axis is only the duration charge, in US dollars.
The checked GPT-Live 1 rate is $0.05 per minute, billed per second. For a worked 600-second session, 600 ÷ 60 × $0.05 = $0.50 in voice duration charges. Backend models, tools and any other applicable service costs must be added from their actual usage. To calculate cost per resolved case, include failed attempts and retries as well as successful calls, then divide by the number of cases your review confirms were resolved.
The cost guide includes quiet time and backend waiting in active session time. It also describes a 15-second WebRTC initialization charge credited against running duration; do not add those seconds again to the same running session. Close completed sessions gracefully and collect final usage. A sensible idle policy should accommodate a caller reading a confirmation, while avoiding connections left open after the interaction has ended.
Follow the voice, recording and application data separately
Read Figure 6: the saved voice, optional recording and your own records have separate controls.
Zero Data Retention (ZDR) is an enabled data policy with endpoint-specific eligibility. Voice creation is not ZDR compatible; speech generation in GPT-Live can be eligible when ZDR is enabled. A reusable voice configuration is not the same object as a conversation recording.
The data controls say session storage is disabled by default. With permitted storage enabled for the project, store: true retains the completed recording for 30 days for downloading or forking. Under ZDR, store is treated as false and those recording functions are unavailable. Setting store: false by itself does not establish that every service log is absent or that your organization has ZDR.
Your application can still retain transcripts, analytics and tool records. Inventory those separately: what is collected, why, who can read it, and when it expires. Avoid personal details in a reusable voice description. A voice configuration should not quietly become a storage location for a caller’s account information.
A beginner-friendly listening and release plan
My proposed review uses a small fixed set of fictional booking conversations. It adds practical checks without claiming a universal benchmark or a quality score we have measured:
- Start with a named baseline. Use the same words and conversation turns for the candidate voice. Change one voice quality at a time.
- Check difficult words. Include dates, numbers, names and a clarification. Ask reviewers what they actually understood, not only whether the voice sounded pleasant.
- Exercise interruption and correction. Verify that the assistant yields and that backend state reflects the corrected request.
- Confirm disclosure playback. Tell listeners the speech is AI-generated. Check that the introduction is audible after connection delays or an interruption; sending text alone does not prove it was heard.
- Record outcome and usage. Count completed, corrected, escalated and failed tasks. Record final duration and backend usage once per operation.
- Keep a recoverable configuration. Record the voice ID, original description, session rules and backend version. Choose the previous approved voice at new-session startup if review reveals a regression.
Use adult voices, describe qualities rather than imitating a person or character, and preserve synthetic-origin indicators. Similar generated voices are possible, so treat the result as a reviewed product choice rather than a promise of exclusive vocal identity.
My decision rule is to adopt a custom voice when it improves understanding and task handling on the conversations the application actually serves. The useful advance is a reusable configuration path. The evidence for a good deployment still comes from listening, clear outcomes and a reviewable application.
Practical questions
Can I hear the creation response?
The creation response is metadata. Start a GPT-Live session, including a billed Playground preview, to listen.
Can a voice be changed halfway through a call?
Select another voice by starting a new session. Plan how application state and relevant conversation context will continue.
Does disabling recording enable ZDR?
No. Check the organization or project policy, endpoint eligibility, and your application’s separate records.
Sources and method — checked October 19, 2026. Product contracts and rates follow the linked official documents. Harbor Help, its configuration snippets, the review plan and the $0.50 calculation are explanatory examples. The waveforms show event relationships, not recorded audio or measured latency.