Engineering note
GPT-Live Voice Architecture: Full-Duplex Interaction, Delegation, and API Boundaries
Industry Pulse Bloss0m Note 046 OpenAI announced GPT-Live on July 8, 2026, as the technology powering a new ChatGPT Voice experience. The important engineering change is not merely that speech sounds more human. It is a pair of system boundaries: a full-duplex voice model continuously handles input and output, while search or deeper reasoning can be delegated to another frontier model. Realtime interaction and slower work no longer have to be one synchronous step.
One distinction prevents a costly implementation mistake: the GPT-Live product name in ChatGPT is not automatically a Realtime API model ID. As of August 9, 2026, the official GPT-Live announcement describes ChatGPT Voice and an API-audio update. The official API model catalog, however, lists the GPT-Realtime family and does not document a gpt-live-1 slug that developers can safely copy into production code.
What GPT-Live actually changes
Early cascaded voice systems ran speech-to-text, a text model, and text-to-speech in sequence. Each conversion could add latency or discard vocal nuance. Native audio models later handled audio input and output inside one model, but commonly retained discrete turns: the user finished speaking before the model responded.
OpenAI describes two changes in GPT-Live:
- Continuous interaction. The model can listen and speak simultaneously while repeatedly deciding whether to listen, pause, respond, accept an interruption, or invoke a tool. That is the practical meaning of full duplex; it does not make network, tool, or model latency disappear.
- Delegation for deeper work. Requests that need search, reasoning, or longer agentic work can be delegated while GPT-Live maintains the conversation. At launch, the Instant and mini variants used GPT-5.5 Instant in the background, while Medium and High used GPT-5.5 Thinking at different reasoning levels. OpenAI also says the backing model will change over time, so that launch configuration is not a durable integration contract.
The architectural value is decoupling. It is not a guarantee that the voice layer will always fill a wait with small talk. A production design still needs policies for progress disclosure, cancellation, and checking whether a completed background result remains relevant to the latest conversation state.
ChatGPT Voice and the Realtime API are different products
GPT-Live is an OpenAI-managed ChatGPT experience. OpenAI controls routing, interface behavior, model updates, and rollout. With the Realtime API, the developer owns sessions, tool authorization, business state, and recovery behavior.
The currently documented GPT-Realtime-2.1 supports speech-to-speech interaction, tool use, and configurable reasoning effort. Its model page also describes improved silence, noise, interruption, and alphanumeric handling. It has a 128,000-token context window and a 32,000-token maximum output; higher reasoning effort can increase latency and output-token use. Those statements are API-contract facts. They should not be inferred from a consumer GPT-Live demo.
On July 31, the GPT-Live release page added that supported audio produced through ChatGPT Voice and the OpenAI API includes SynthID watermarking. The API model pages should still be the direct source for model IDs, prices, and endpoint support. If the catalog does not list the expected GPT-Live model, wait for documentation or use a listed Realtime model instead of inventing a slug.
Failure modes a voice agent must handle
A natural demo is not evidence of an operable system. Test at least these risks:
- False turn endings and interruptions: silence, noise, or overlapping speakers can create a false boundary. An interruption can also leave old audio or background work running.
- Stale delegated results: the user may change the request while a task is in flight. Playing the old result without reconciliation contradicts the current conversation.
- Repeated tool side effects: replay, reconnect, or retry can repeat a purchase, appointment change, or email. Side-effecting tools need idempotency keys and explicit confirmation.
- Fluency masking factual error: natural prosody does not remove hallucinations. Amounts, dates, names, and alphanumeric codes still need read-back or visual confirmation.
- Weak privacy and disclosure controls: microphone data, transcripts, tool inputs, and retention need separate review, and users should know that they are interacting with AI.
What to evaluate before launch
Do not stop at answer accuracy. A voice-agent test suite should measure time to first audio, end-to-end completion latency, false endpoint rate, interruption recovery, background-task cancellation, tool success, and human escalation. Support and transaction flows should add noise, accents, code read-back, network jitter, and repeated changes of mind.
A useful architecture separates an interaction layer, task layer, and safety layer. The interaction layer owns audio, sessions, and turn-taking. The task layer runs search, reasoning, and tools. The safety layer owns identity, authorization, confirmation, and audit logs. For the surrounding agent design, continue with the AI Agent guide, the 2026 MCP overview, and the enterprise AI agent security architecture.
Primary sources
- OpenAI: Introducing GPT-Live (July 8, 2026; updated July 31, 2026)
- OpenAI API: Models (model and product boundaries)
- OpenAI API: GPT-Realtime-2.1 model (capabilities, limits, and pricing)