Inside GPT-Live: How OpenAI Rebuilt ChatGPT's Voice Stack for Full-Duplex Conversation

Most voice assistants are built like walkie-talkies. You press to talk, release to listen, and the system tries to guess the exact moment you finished speaking so it can start its reply. Get that guess wrong and you either get cut off mid-sentence or sit through an awkward pause. That turn-detection problem has haunted voice AI since the first interactive voice response systems.

On August 3, 2026, OpenAI published a detailed engineering post on how it spent six months rebuilding ChatGPT's voice infrastructure to get rid of that tradeoff. The result is GPT-Live, a "turnless" speech model that listens and speaks simultaneously, now powering ChatGPT Voice. This post walks through the architecture described in OpenAI's engineering write-up, with detail from RuntimeWire's technical analysis of the announcement.

The Problem: Turn Detection Is a Bottleneck

Earlier ChatGPT voice systems treated a conversation as a sequence of turns. A separate voice-activity detector had to decide when the user had stopped talking before the model could respond. That design creates an unavoidable tradeoff: decide early and you risk cutting the user off; decide late and you add an audible pause to every exchange.

This is a latency problem that no amount of faster inference fully solves, because the decision itself is the bottleneck. Every turn boundary is a judgment call about silence, breathing, filler words, and unfinished sentences. As OpenAI's earlier write-up on low-latency voice at scale noted, conversational turn-taking is one of the hardest problems in real-time voice AI.

The Fix: One Continuous Full-Duplex Model

GPT-Live removes the separate turn detector from the audio path entirely. Instead of two phases (listen, then speak), the model runs full-duplex: it continuously processes incoming speech while generating outgoing audio, and decides several times per second whether to listen, speak, pause, interrupt, or hand off to another system.

The implications go beyond feeling more natural. Because the model never waits for a clean turn boundary, interruptions become first-class interactions. You can talk over the assistant mid-answer and it can adjust on the fly — something that felt broken in every previous generation of voice assistants.

Separating Speech from Everything Else

The most interesting architectural decision is what OpenAI did around the model. Speech travels between the client and GPT-Live over a dedicated fast path — a low-latency lane dedicated to the audio loop. Everything else (search, tool calls, persistence, and deeper reasoning) sits behind an asynchronous boundary.

This means a slow tool call no longer stalls the conversation. When you ask a question that requires a web search, GPT-Live keeps talking while the search runs in the background, then weaves the result into the flow when it's ready. The system is effectively two models presented as one assistant: GPT-Live handles timing and speech, while a frontier model — GPT-5.5 Instant for the lighter settings, GPT-5.5 Thinking for Medium and High — handles the work that needs more computation. OpenAI can also swap out that delegated reasoning model as newer systems arrive, without rebuilding the voice model around each release.

From Python to Go: Engineering for Consistent Latency

OpenAI rewrote the media frontend and inference logic in Go, replacing an earlier Python asyncio implementation. The stated goal was consistency rather than peak speed: the new system's 95th-percentile frame-delivery performance matched the previous system's median. In real-time audio, worst-case latency is what users actually feel, so moving the whole distribution left matters more than winning a benchmark.

Long conversations posed another problem. Context grows over time, and model instances may need to be replaced as capacity changes. OpenAI built a handoff process that warms a replacement instance, loads it with the current context, and runs both instances in parallel before switching traffic. The same mechanism lets it compact an oversized context without pausing the conversation.

WARP: Cutting Session Startup from Six Round Trips to One

Below the model layer, standard WebRTC setup requires several protocol handshakes before media can flow. OpenAI developed the WebRTC Abridged Roundtrip Protocol (WARP), which reduced media and data startup from six network round trips to one. A related system called Instant Connect negotiates session parameters ahead of time, allowing the client to begin a session with a single UDP packet when those parameters are still valid.

This matters at scale. ChatGPT Voice and Dictation serve more than 150 million people each week, and every session startup that gets cut from six round trips to one is a measurable reduction in perceived lag. OpenAI is advancing WARP through an Internet Engineering Task Force working group, and says support has already landed in libwebrtc and Pion — so the work generalizes beyond OpenAI's own stack.

What Shadow Deployment Revealed About Capacity

Before the July 8 launch, OpenAI routed a gradually increasing share of production voice sessions through the new system while Advanced Voice Mode kept serving everyone else. This shadow deployment exposed the replacement stack to real networks, session lengths, and geographic traffic.

The testing surfaced a counterintuitive finding: GPU throughput alone is a poor measure of voice capacity. Voice calls keep connections open and send frames continuously, placing sustained pressure on CPU stream handlers, queues, and network services. OpenAI reports that one supporting component saturated earlier than load tests predicted, causing inference requests and latency to accumulate. At hundreds of millions of weekly users, natural conversation depends as much on regional routing, connection setup, and recovery behavior as it does on model inference.

What It Means for Developers

GPT-Live is currently powering ChatGPT Voice (GPT-Live-1 for Go, Plus, and Pro users; GPT-Live-1 mini for Free users), and OpenAI says an upcoming GPT-Live API will expose the same architecture to developers. That API is the part worth watching: a voice system built around continuous interaction and background delegation raises the bar for customer support, tutoring, and desktop agents.

For anyone building voice products, the takeaways are practical. Separate the audio loop from application logic so slow services can't stall speech. Optimize for consistent latency, not best-case latency. And treat connection setup as a first-class latency problem — six round trips of handshaking is six round trips too many when users can hear the difference.

Further Reading

• How we built a realtime system for responsive voice AI in six months — OpenAI (primary source, August 3, 2026)
• Introducing GPT-Live — OpenAI (product announcement, July 8, 2026)
• OpenAI rebuilt ChatGPT's voice stack so GPT-Live can listen while speaking — RuntimeWire (independent technical analysis)
• How OpenAI delivers low-latency voice AI at scale — OpenAI (background on the WebRTC stack rebuild)