Cover photo

How GPT-Live Keeps a Voice Conversation Moving

The system separates a continuous audio loop from slower reasoning, then reconnects the result without forcing every exchange into turns.

Most voice assistants still behave like walkie-talkies. One side speaks, a detector decides the turn has ended, and only then does the system begin producing a reply. That sequence is tidy for software, but awkward for conversation. A short silence may be a breath, a search for a word, or an invitation to respond. Treating all three as the same event creates either interruption or delay.

OpenAI's new engineering account of GPT-Live describes a different design. Instead of making turn detection the gatekeeper for every response, the system keeps incoming and outgoing audio moving continuously. The voice model listens while it speaks, and slower tasks can run beside that live exchange rather than freezing it.

That is the useful idea behind the product. GPT-Live is not merely a faster speech generator. It reorganizes where waiting happens.

The old pipeline accumulated pauses

A conventional voice assistant often joins three separate systems. Speech recognition turns audio into text. A language model writes an answer. Text-to-speech converts that answer back into audio. Each stage waits for enough output from the previous one, which adds latency. Converting speech to text also discards information such as timing, emphasis, and hesitation before the language model sees it.

Turn detection creates another trade-off. If the detector reacts quickly, it can mistake a natural pause for the end of a sentence. If it waits for certainty, even simple exchanges feel sluggish. Developers can tune the threshold, but no single delay fits every speaker, language, room, or moment.

GPT-Live removes that detector from the main audio path. Its model receives a continuing audio stream and repeatedly decides whether to listen, speak, pause, or stop. Because the same model works with speech directly, vocal cues remain available when it makes those decisions.

Full duplex is the networking term for communication that can travel in both directions at once. Telephones are full duplex. Walkie-talkies are not. In GPT-Live, full duplex means the user can begin speaking while the model is talking, and the model can use that new audio to yield or adjust instead of waiting for a formally completed turn.

One loop talks while another thinks

Continuous audio does not mean every task must be completed inside the voice model. OpenAI separates the low-latency media loop from an application path used for tools and deeper reasoning.

The voice model handles the immediate conversational job. It tracks the exchange, produces speech, and reacts to interruptions. When a request needs a web search, calculation, or more capable text model, the system derives a discrete turn from the continuous conversation and sends that work away asynchronously. Asynchronous means the slower task can proceed without blocking the live audio stream.

The result returns later and is folded back into the conversation. This allows the voice model to acknowledge a request, ask a clarifying question, or keep the interaction alive while another component works. The July product announcement says GPT-Live can delegate deeper work to GPT-5.5 in this manner.

This division also clarifies why the system can feel responsive without every answer arriving instantly. Responsiveness is partly about what happens during the wait. A quiet three-second pause feels longer than a three-second interval in which the assistant confirms what it is doing and remains interruptible.

Keeping continuity is an infrastructure problem

The model is only one part of the design. Audio travels over WebRTC, the real-time communications technology commonly used for calls in browsers and apps. The transport must cope with lost packets, drifting clocks, changing networks, and audio that arrives too quickly or too slowly. OpenAI says the system can stretch playback or catch up without exposing most of that correction to the listener.

Long conversations introduce a second challenge. A live session may need to move between model instances as servers are updated or capacity changes. GPT-Live uses a warm handoff. A replacement instance is first loaded with the session context, both instances run briefly, and traffic switches only when the new one is ready. The goal is to preserve state without making the user restart the conversation.

Session setup was also shortened by moving protocol steps off the critical path. These details sound mundane next to a new model, but they determine whether the first word arrives promptly and whether a call survives ordinary network conditions.

Timing remains a judgment, not a solved fact

Removing a fixed turn detector does not remove the need to judge conversational timing. It transfers more of that judgment to the model. The model can still interrupt at the wrong moment, miss an interruption, or react oddly to background speech. Independent developer Simon Willison reported an unwanted laughter response during an earlier preview, though he said the behavior improved before launch.

Safety also has to operate continuously. OpenAI says it monitors both inputs and outputs as the conversation unfolds and can steer, interrupt, or end a session. Its system card reports voice-specific production and synthetic evaluations, while also noting small regressions in a few categories. Those are vendor-reported tests, not proof that every language, accent, or noisy environment will behave equally well.

The practical lesson is broader than voice AI. Low latency often comes from separating an immediate control loop from slower, richer computation. GPT-Live keeps listening and speaking close to the user, then lets tools and larger models work in parallel. The conversation feels less turn-based because the architecture no longer makes every component wait in line.

Sources