Is GPT-Live-1, OpenAI's Full-Duplex Model, Ready for Production?
The media path is simpler and the conversation is more natural. The production control problem still belongs to the system around the model.
GPT‑Live‑1 is OpenAI's full‑duplex voice model, released in the API on September 10, 2026. This article is a technical breakdown for teams building or evaluating real‑time voice agents: what the model actually is, how its architecture works, what the $0.05‑per‑minute price does and does not cover, and which production controls stay outside the model. If you are weighing whether to build on it, start here.
After running full-duplex models in production, the pattern is consistent: they fix conversational timing and expose everything else. GPT‑Live‑1 listens while it speaks and lets the model itself decide when to talk, so a VAD no longer gates every response. What it does not do is take over the parts that make a voice agent correct. Permissions, confirmations, tool execution, and durable task state still live in the system around the model. The broader cascaded-versus-full-duplex comparison lives in our full-duplex speech model primer.
- GPT‑Live‑1 keeps incoming and outgoing audio in one continuous model loop, so a VAD no longer decides when every response may begin.
- Fast conversation and deeper work run on different paths. The voice model keeps the exchange moving while a backend model, agent, or service reasons and uses tools.
- The published price is $0.05 per minute for the front-end voice layer, billed per second. Backend model and tool charges are additional.
- Our view: full duplex solves conversational timing. Production correctness still requires an explicit control layer around the model.
What is GPT‑Live‑1?
GPT‑Live‑1 is built for continuous conversation rather than a sequence of isolated audio turns. Its defining architectural choice is to separate the model handling the live exchange from the backend doing deeper reasoning and tool work. That lets the conversation continue while another part of the system works on the task.
The important word is continuous. Earlier speech systems relied on a VAD to decide the user had finished, then let the larger model start. GPT‑Live takes the VAD off the trigger path: the model decides many times per second whether to speak, pause, listen, or acknowledge, without waiting for a silence gap. Incoming speech keeps reaching the voice model while it is producing outgoing speech, which is what lets it handle overlaps, thinking pauses, backchannels, and interruptions as part of the conversation itself.
Turn-based speech
Listen, decide the turn ended, then respond.
GPT‑Live full duplex
Listen and speak on the same continuous timeline.
OpenAI reports a 30 percentage-point improvement over GPT‑Realtime‑2.1 on Full Duplex Bench. Its launch material also reports 0.798-second turn-taking latency versus 1.41 seconds for GPT‑Realtime‑2.1, and Speak reported almost 80 percent fewer interruptions during learner thinking pauses in early evaluations. These are vendor and customer-reported results. They establish the intended capability, but performance still varies by telephony route, language, prompt, and workload.
How does the GPT Live architecture work?
GPT‑Live splits the work across two paths that run at different speeds. A low-latency media frontend sustains the spoken exchange. A separate, asynchronous path handles work that can take longer: retrieval, deeper reasoning, tool calls, business logic, and persistence.
OpenAI's engineering article describes a dedicated fast path from the client to the voice model. Delegation and application work sit behind an asynchronous RPC boundary, so a slow backend call can delay its own result without freezing the audio stream. Stateful inference keeps the live conversation running, while model handoffs and context compaction happen away from the active media loop.
Client or phone call
WebRTC, WebSocket, or SIP carries the live session and audio.
GPT‑Live‑1
Listens, speaks, handles overlap, and decides when deeper help is needed.
Backend + application
Reasons, uses tools, checks policy, stores task state, and returns verified results.
This separation is the most important architectural idea in GPT‑Live. Speech has a strict timing budget. A refund lookup, account mutation, search request, or multi-step plan does not. Putting both inside the same blocking loop would make the voice experience inherit the latency and failure modes of every downstream service.
How do delegation and tool calls work?
OpenAI explicitly documents two modes: Responses delegation and client delegation. With Responses delegation, GPT‑Live calls the supported Responses model you configure and manages the context and result handoff. With client delegation, your application prepares the context, runs an agent or workflow, and sends results back to GPT-Live.
The model page lists function calling as supported, but that short label needs architectural context. Tool work is delegated. With a Responses backend, GPT‑Live can invoke the configured model and its tools. With client delegation, the Live session emits a delegation event and your application runs the work. OpenAI explicitly assigns permissions, confirmations, business records, private function execution, and durable task state to the application.
Natural conversation and safe action are separate engineering problems. GPT‑Live gives the first problem a much better primitive. The second still needs a control system whose hard boundaries do not depend on the model remembering another line in a prompt.
How much does GPT‑Live‑1 cost?
GPT‑Live‑1 costs $0.05 per minute for the frontend voice model, billed per second. The backend model is billed separately at the rates for the model you choose and the usage it incurs. Tool usage can add further charges. OpenAI states this separation in both its API launch announcement and GPT‑Live guide.
Billed per second.
Tools may add their own charges.
What GPT‑Live's architecture shares with the DinoDial harness
GPT‑Live‑1 is a voice model. The DinoDial harness, the runtime behind Vox, our voice AI orchestration layer, is the runtime around a speech model that manages workflow stages, tools, and execution. They occupy different layers of a voice agent. The useful comparison is how each architecture separates responsibilities to keep conversation responsive and actions controlled.
OpenAI separates continuous speech from delegated reasoning and tool work. We have applied a related principle in the DinoDial harness: the speech model perceives and speaks, while the harness owns the workflow graph. The model reports an outcome; the runtime decides which authored stage follows and which instructions and tools are available there.
Speech + delegated work
- The voice model manages continuous conversation.
- A backend handles deeper reasoning and tools.
- The application enforces permissions and task state.
Speech + controlled workflow
- The speech model handles the spoken exchange.
- The runtime routes between decision checkpoints.
- Stage policies and validation govern tool execution.
Keep decisions outside the model when code can own them
In our harness, a stage is a decision checkpoint, such as identity verification, a branch in the workflow, or a tool result that changes the next step. It does not represent every spoken sentence. Keeping routine conversation inside a stage avoids unnecessary workflow transitions and the extra round trips they introduce.
| Architectural decision | GPT‑Live system | DinoDial harness today |
|---|---|---|
| Separate speech from other work | The voice frontend delegates reasoning and tools to a backend. | The speech model handles conversation; the runtime owns workflow routing and execution rules. |
| Keep control explicit | The application owns permissions, confirmations, and durable task state in either delegation mode. | Stage-specific tool allow-lists restrict availability; integration validation checks requests before execution. |
| Limit avoidable coordination | Asynchronous delegation keeps backend work off the continuous audio path. | Stages represent meaningful decisions, avoiding an extra workflow transition for every conversational step. |
| Handle reasoning separately | A chosen backend model can reason through delegated tasks. | Current routing is deterministic. A separate reasoning supervisor is an additional capability, not something the workflow graph already does. |
Reasoning can improve recovery while the harness keeps authority
A failed lookup shows where the distinction matters. A reasoning layer can work out whether to retry, ask for another detail, or choose a fallback. The harness still has to check whether that next action is allowed at the current stage. Our intended direction keeps that division: more flexible recovery, with explicit execution boundaries. In our harness that boundary is enforced in code, not a prompt: tool calls run as sandboxed WASM components that are validated before they execute, so a permitted action is checked in isolation before it can touch a real system.
Client delegation provides an interface for connecting this kind of application-owned backend to GPT‑Live. For that integration, context, events, cancellation, and returned results need to map cleanly into the harness. The evaluation then covers the complete system: conversational responsiveness, recovery after a failure, and whether each permitted action completes correctly.
Is GPT‑Live‑1 the right architecture for production voice agents?
GPT‑Live‑1 gives builders a production API for treating conversation as a continuous stream instead of a queue of audio turns. The clean media path, asynchronous delegation, and native handling of overlap address problems that become brittle when separate components must coordinate every interruption.
It also makes the application boundary more important. Client delegation requires your system to retain context, interpret transcript fragments, track pending work, confirm actions, and decide which results may re-enter the conversation. The voice layer can sound immediate while the underlying business task remains pending.
Use the managed Responses path when its model-and-tool loop fits your task. Use client delegation when you need to own backend context, routing, result validation, or recovery policy. Permissions and required confirmations remain application responsibilities in both modes. Measure conversation quality and completed outcomes separately, the kind of split production voice AI observability is built to surface.
Full duplex gives the model control of conversational timing. Production readiness depends on how deliberately the application controls everything that follows.
Frequently asked questions about GPT Live
What is GPT‑Live‑1?
GPT‑Live‑1 is OpenAI's full-duplex voice model for real-time conversations. It processes incoming and outgoing audio together, can listen while speaking, and delegates deeper reasoning or tool work to a separate backend agent.
Is GPT‑Live‑1 speech-to-speech?
Yes. GPT‑Live‑1 accepts and produces audio directly on the live path. It also provides native ASR transcripts and response text as side-channel artifacts, so applications can display, store, or use text without putting a separate STT-to-LLM-to-TTS cascade in the primary conversation loop.
How much does GPT‑Live‑1 cost?
GPT‑Live‑1 costs $0.05 per minute for the frontend voice model, billed per second. Backend model usage is billed separately at the chosen model's rates, with additional charges for applicable tools. Telephony, transport, and application infrastructure are also outside the frontend rate.
Does GPT‑Live‑1 support tool calling?
Yes. GPT‑Live‑1 delegates reasoning and tool work either to an OpenAI Responses backend or to a client-operated backend. The application still owns permissions, confirmations, private function execution, business records, and durable task state.
Is GPT‑Live‑1 better than a turn-based voice model?
GPT‑Live‑1 is designed for more natural overlap, pauses, backchannels, and interruptions. OpenAI reports stronger full-duplex benchmark results, but production suitability still depends on task success, tool governance, total cost, latency, and workflow control on your own calls.
Build the control layer the model still needs
The DinoDial harness gives speech-to-speech agents an explicit workflow, bounded tools, and a runtime your team can inspect. Explore how those controls fit around the speech model and backend you choose.
Explore the DinoDial harness →