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.
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 — Practical guideChoose 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 — Practical guideFit 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 — Practical guideBudget 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 — Practical guideTest 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 — Practical guideDecide 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.
Evidence and scope
- As-of date
- September 12, 2026. September 10 is the editorial allocation; 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 — Next stepPut the decision into practice
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.