GPT-Live-1 lets a voice application keep listening and speaking while a separate backend works on the user’s request. For a business voice agent, the important change is the division of responsibilities: the voice layer manages conversation, while the backend reasons, uses tools and returns facts the voice layer can communicate.
OpenAI’s September 10 API announcement makes the product available to developers after its earlier ChatGPT introduction. The documentation and pricing discussed here were checked on September 12, 2026. Evaluate conversational behavior and task execution separately before deciding whether to migrate an existing voice application.
- 01Conversation and work are separate.Choose the backend independently of the full-duplex voice model.
- 02There are two delegation paths.Responses delegation manages the model handoff; client delegation gives your application control.
- 03Voice is one cost line.Duration billing excludes backend model and tool usage.
- 04A startup event is not a working call.It confirms the session started; intelligible input, a correct backend result and played audio are separate checks.
01 — Practical guideUnderstand what full duplex changes
Full duplex means the model can listen while speaking. A caller can add a detail, pause to think or interrupt without the application treating every exchange as a rigid sequence of complete turns. It does not mean the backend instantly knows the correct action or that speaking over the agent reverses a tool call.
The getting-started guide describes a voice frontend and a delegated backend. Keep the conversation prompt short and focused on style and when to ask for help. Put detailed task rules and tool workflows in the backend. This keeps the spoken interaction from becoming a recital of implementation instructions.
Our earlier GPT-Live coverage concerns the consumer experience. This article’s decision is narrower: how to connect a voice frontend to a business application you control. Customer testimonials and vendor benchmarks do not establish performance for that application.
02 — The decisionChoose who controls the backend request
With Responses delegation, GPT-Live calls a configured Responses model and supplies conversation context. With client delegation, your application prepares context, runs its chosen agent or workflow, and decides what result to return. The delegation guide says to choose the mode at session creation; switching modes requires a new session.
Client delegation is useful when the backend already exists, uses a different provider, or needs tightly selected context. It also makes your application responsible for assembling that context. The delegation event carries metadata rather than the complete task text, so a handler needs the saved transcript and relevant application state.
Choose by ownership requirements, then verify the supported settings. Live’s Responses integration is a subset of the standalone Responses API; do not assume that every field from an existing request can be copied into a Live command.
| Decision | Responses delegation | Client delegation |
|---|---|---|
| Who starts backend reasoning? | GPT-Live uses the configured Responses backend. | Application receives a delegation and starts its workflow. |
| Who supplies task context? | Service supplies conversation context. | Application selects transcript, memory and business state. |
| Where do private actions run? | Application handlers still execute private function tools. | Application workflow executes its authorized tools. |
| Why choose it? | The managed handoff fits the product. | Custom execution or result selection is necessary. |
03 — MethodFit the connection to the product
The documentation offers WebRTC for browser voice, WebSockets for server-side audio, and telephony integration guidance for phone applications. A server-side control connection can receive events while the primary connection carries audio. The connection choice should fit your media path and deployment environment.
Keep a project API key on a trusted server. A browser pilot needs microphone input, audio output and an event channel, as well as a backend that creates the session. A startup event confirms startup; it does not show that the microphone was intelligible, the result was correct or the speaker played it.
For a first pilot, choose one task such as looking up a booking and explaining its conditions. Add an action only after the application can verify the caller’s authority and distinguish a pending request from a completed change. Track these checks as separate outcomes.
04 — The costBudget voice duration and backend work separately
OpenAI’s API pricing lists GPT-Live-1 voice at USD $0.05 per minute, billed per second without rounding to a whole minute. Backend model and tool usage are charged separately. This is a session-duration rate, not a price for each successfully resolved call.
For illustration, 90 billable seconds cost $0.075 for voice: 90 divided by 60, multiplied by $0.05. A ten-minute session costs $0.50 for voice. These are calculations from the listed rate, not observed invoices, and exclude backend tokens, tools, phone service and your infrastructure.
The session guide describes cumulative usage snapshots and a final usage record on session closure. Do not sum cumulative snapshots as if each were an increment. Preserve the final record and account for delegated usage separately. If finalization was not observed, label that cost record incomplete rather than inventing a final duration.
05 — The evidenceTest the conversation and the completed task
Use the same task with a normal request, a thinking pause, a correction, overlapping speech and a slow tool. Listen to the played audio and inspect the backend result. A fluent confirmation can conceal a wrong date, a failed update or a response that the caller interrupted before hearing.
Measure first audible response separately from first useful result. A quick acknowledgment improves the experience only if it remains accurate about what is still pending. The voice latency reference supplies a worksheet for these different intervals.
Include a disconnect after the backend acts but before the confirmation is heard. On reconnect, the application should retrieve the result rather than repeat the action. The background-tool voice guide explains how to keep task revisions and spoken updates aligned.
06 — ExampleDecide whether to pilot or migrate
Pilot GPT-Live when natural interruptions and work during conversation solve a problem users actually encounter. Keep an existing approach when its current interaction model meets the task and a migration has no demonstrated benefit. A full-duplex frontend is a capability to test, not a reason to discard a working system.
Write a pilot decision with the selected connection, delegation mode, supported task, acceptance check and cost boundary. Mark language coverage, account-specific availability and operational requirements as verified only after checking the configuration you intend to use.
For a broader implementation, our AI transformation service can help define the workflow and its evidence. Start with the caller’s goal, then select the voice and backend combination that can complete it reliably.
As-of date. September 12, 2026. The article is dated September 10, 2026; current documentation was reviewed later.
Method. Primary documentation and research were reviewed for the cited distinctions. Tables, worksheets and pilot checks are Digital Applied proposed methods, not observed deployment results.
Limitations. No production API workflow, vendor benchmark or participant study was executed for this article. Documentation can change; verify the selected configuration before implementation.
07 — The failure caseFour pilots that measured the wrong thing
A voice pilot produces a lot of signals, and most of them are about the conversation rather than the task. The illustrative pilots below each took a conversational signal as proof of something it does not show. They are design examples drawn from the documentation’s own distinctions, not deployed systems.
The recital prompt
The task rules and tool workflow are written into the conversation prompt. The agent explains its implementation to callers and interrupts itself with procedure. The getting-started guide gives GPT-Live a short prompt for conversation style and keeps detailed instructions, business rules and tool workflows in the backend.
The summed snapshots
The pilot’s cost report adds up the cumulative usage snapshots the session emits, treating each as an increment. The session guide describes them as cumulative, with a final usage record at closure; the total was overstated.
The interruption as cancellation
A caller talks over the agent during a booking confirmation and the team assumes the booking stopped. Speaking over the agent does not reverse a tool call; the backend completed, and the caller was told nothing happened.
The startup event as proof
The browser pilot logs a startup event for every session and the pilot is declared working. The event confirms the session started, not that the microphone was intelligible, the result was correct or the speaker played it.
Each pilot would have been corrected by writing the acceptance check before the first call, which is what the one-page decision in the next section is for.
08 — The methodThe pilot decision on one page
The migration section asks for a pilot decision with the connection, delegation mode, supported task, acceptance check and cost boundary, and the page that holds it is short. Connection: WebRTC for a browser, WebSockets for server-side audio, or the telephony integration for a phone application, with the project API key kept on a trusted server. Delegation mode, chosen at session creation because the guide says switching requires a new session: Responses delegation when the configured Responses backend is enough, client delegation when the backend already exists, uses a different provider or needs tightly selected context. Supported task: one, with a clear result, such as looking up a booking and explaining its conditions, with actions added only after the application can verify the caller’s authority.
Acceptance check: the authoritative result inspected after the call, not the transcript; first audible response and first useful result measured separately; the disconnect-after-action case retrieved rather than repeated on reconnect. Cost boundary: voice duration at the listed $0.05 per minute billed per second, so an illustrative ten-minute session is $0.50 for voice, with backend model and tool usage, telephony and infrastructure budgeted as separate lines and the final usage record, not the cumulative snapshots, as the source. Verified availability: language coverage, account-specific availability and operational requirements marked verified only after checking the configuration you intend to use.
The page is also the exit criterion. The pilot expands when the new interaction improves the supported task under conditions callers actually create, and it stops when the existing approach meets the task and the migration has no demonstrated benefit, which is the conclusion the migration section reaches. Either outcome is a decision, and the page is what makes it one.
Voice is billed by session duration, per second at the listed rate. Backend reasoning and tools are billed by their own usage. A fluent ten-minute call with a wrong booking still costs the full voice line, plus whatever backend usage it consumed, and completes nothing; budget and test the two separately.
09 — Next stepPut the decision into practice
Fill in the one page for a single task before the first pilot session. It is the document that says, at the end, whether to expand or to keep what already works.
Understand what full duplex changes
Run a bounded pilot that records both the conversation and the authoritative result. Expand only when the new interaction improves the task under conditions your callers actually create.