GPT-Live-1 arrived in the OpenAI API on September 10, 2026 with an important change for developers building voice agents: the model can listen and speak at the same time. This full-duplex behavior reduces the need to manually coordinate every handoff between speech recognition, reasoning, and speech synthesis. In practice, the main promise is not just a more natural voice. It is a less fragmented conversation layer that can handle interruptions, pauses, and changes of direction while a backend performs tasks.
The architectural decision, however, is not to "replace the entire agent with GPT-Live-1." The documentation separates two responsibilities: GPT-Live-1 runs the spoken conversation, while a backend can handle reasoning, tools, business rules, and durable state. The application remains responsible for permissions, confirmations, and safe action execution.
What changes compared with a chained voice agent
| Area | Chained pipeline | GPT-Live-1 |
|---|---|---|
| Audio | Usually separates speech-to-text, a language model, and text-to-speech. | One voice model handles incoming and outgoing audio at the same time. |
| Interruptions | The application must coordinate turn detection, audio cancellation, and resumption. | The model is designed to follow overlapping speech, pauses, and changes of direction. |
| Reasoning and tools | Often live in the same orchestrator that also manages voice. | They can be delegated to a Responses model or to an application-controlled agent. |
| Telephony | Often needs a custom bridge between the telephony provider, streaming layer, and model. | The documentation includes SIP paths plus integrations with partner providers and frameworks. |
| Voices | Voice choice depends on the separate TTS service. | The release expands built-in choices and keeps custom voices as a separate option for eligible customers. |
| Billing | You must add STT, model, TTS, and infrastructure costs. | The GPT-Live-1 voice layer is billed by session duration; backend models and tools are billed separately. |
OpenAI describes the traditional architecture as a sequence of speech-to-text, model, and text-to-speech, with each transition adding latency and coordination points. GPT-Live-1 processes incoming and outgoing audio together. In launch evaluations, OpenAI reported a 30 percentage point improvement on Full Duplex Bench versus GPT-Realtime-2.1. That is a vendor-reported measurement, not a guarantee for every deployment, so teams should test with the actual call patterns and noise conditions of their product.
Full duplex mainly changes turn control
Full duplex means the system can listen while it is speaking. That is different from simply streaming audio in both directions. In a human conversation, a user can interrupt, say "yes," correct a detail during the reply, or take a long pause. In rigid turn-based architectures, these situations often require external logic to decide when the user has finished and when the agent should stop speaking.
GPT-Live-1 was trained to manage that conversational dynamic in the voice layer. The documentation also says the model natively provides ASR transcripts and response text and supports turn detection when an application still wants explicit boundaries. This gives developers two patterns: a more continuous conversation or preserved turn checkpoints when the business flow needs them.
There is an important caveat: interrupting the agent's speech does not automatically cancel work that has already been delegated to the backend. The application must decide whether that work should continue, be abandoned, or be replaced by a newer request. This is an important distinction between conversational naturalness and transactional control.
Delegation: where agent reasoning lives
GPT-Live-1 can delegate work while it continues managing the conversation. The documentation defines two main modes.
| Mode | When it tends to simplify | What the application still controls |
|---|---|---|
| Responses delegation | When a Responses API model and the supported tools cover the workflow. | Private functions, permissions, confirmations, and business rules. |
| Client delegation | When an existing agent, orchestrator, or service should remain the backend. | Context sent to the agent, routing, result validation, state, and execution. |
With Responses delegation, the Live service sends conversation context to the configured backend model and returns the result to the voice session. With client delegation, the application receives a delegation event, builds the backend input from transcripts and its own state, runs the agent, and sends back only the result it wants the conversation to use.
This design can replace the STT and TTS layer without discarding a mature text agent. The migration guide specifically recommends keeping detailed instructions, tools, permissions, and durable state in the backend, while the GPT-Live-1 prompt focuses more narrowly on speaking style and when to delegate.
New voices: more built-in choice, while custom voice remains separate
In the API launch announcement, OpenAI said it expanded real-time voice choices across accents, dialects, and languages. New options highlighted in the release include Quartz, Ripple, Vesper, Willow, Stone, Gleam, Meridian, Bossa, Tempo, Beacon, Delta, and Cinder. OpenAI says it will continue expanding voice options and language availability.
Custom voice should not be confused with that built-in catalog. Custom voices remain limited to eligible customers. The documentation requires a consent recording and a matching sample from the same speaker before a voice can be created. For GPT-Live-1, a custom voice is selected when the session starts and the output voice cannot be changed in the middle of that session.
Telephony: what becomes more direct
For browser applications, the documentation recommends WebRTC. For server-side audio integrations, it offers WebSockets. For telephony, OpenAI documents SIP and also points to integrations with LiveKit, Twilio, Telnyx, and Daily/Pipecat. The architectural benefit is that the same full-duplex voice layer can receive call media without requiring the developer to assemble separate STT and TTS stages on each side.
For inbound call flows, the API includes operations to accept or reject a call, monitor the session, transfer the call, and hang up. The documentation also records a relevant limitation: creating an outbound SIP call directly through POST /v1/live/sessions is not supported. For provider-owned outbound calling, the recommended path is the appropriate integration.
Native telephony does not remove application controls from sensitive operations. Voicemail detection, recording beeps, playback policies, identity checks, and confirmations before actions can still require application logic or even a separate audio detector.
When GPT-Live-1 actually simplifies a voice agent
| Scenario | Likely architectural effect |
|---|---|
| Browser voice assistant | High simplification: WebRTC can connect microphone input and audio output directly to the Live session, with a separate backend for tools. |
| Existing STT + text agent + TTS stack | High simplification in the voice layer: GPT-Live-1 can replace separate recognition and synthesis stages while preserving the existing agent through client delegation. |
| Inbound phone support | Meaningful simplification: SIP and call operations reduce some of the glue between telephony and AI, while business rules remain in the backend. |
| Agent with many services, policies, and approvals | Partial simplification: conversation handling becomes simpler, but orchestration, state, security, and validation remain application responsibilities. |
| Flows that depend on specific acoustic signals | Smaller simplification: voicemail, beeps, and other audio classifications can require parallel processing. |
| Large-scale outbound dialing | Requires additional provider integration because direct outbound SIP call creation through a Live session is not supported. |
A practical rule is to separate "conversation complexity" from "business complexity." If the current problem is interruptions, turn timing, buffers, STT, TTS, and audio synchronization, GPT-Live-1 directly targets that layer. If most complexity lives in policies, integrations, state, routing, and approvals, the new API improves the voice interface but does not remove the backend.
Current price and limits: treat them as configuration, not constants
In the documentation checked on September 16, 2026, a GPT-Live-1 voice session costs $0.05 per minute, billed per second without rounding up to the next whole minute. Backend model and tool usage is billed separately. Comparing cost only by the voice-layer rate can therefore be misleading: the final cost depends on the delegated model, tool calls, average session duration, and concurrency.
Published limits are measured in concurrent sessions: the Free tier is not supported; Tier 1 allows 25 sessions, Tier 2 allows 50, Tier 3 allows 200, Tier 4 allows 300, and Tier 5 allows 500. Because pricing and limits can change, capacity planning should point to the model page and project dashboard rather than hard-code these values permanently.
Checklist before migrating
- Map how much code and how many services exist only to coordinate STT, TTS, turn detection, and interruption handling.
- Separate conversation rules from business rules. Keep the voice prompt short and detailed workflows and tools in the backend.
- Choose Responses delegation when the managed workflow is sufficient and client delegation when you need tighter control of context, routing, or result review.
- Test barge-in, long pauses, overlapping speech, background noise, and mid-sentence corrections with real users.
- For telephony, validate inbound calls, transfers, hangups, network drops, and the outbound-call path provided by your carrier.
- Calculate cost per complete call, including the Live session, backend model, and tools, rather than only the per-minute voice price.
