GPT-Live inside: How voice AI chats without waiting its turn

GPT-Live's leap forward isn't just in producing a more natural voice. The central change is to allow the model to continue listening while speaking, without relying on an external detector to decide that a person has finished their turn before starting to respond.

In the architecture presented by OpenAI on August 3, 2026, audio continually enters and leaves the voice model. Searches, tools, data persistence, and tasks that require more thought are routed through an asynchronous route, separate from the path that needs to keep the conversation flowing.

This does not mean the complete disappearance of turns, nor does it guarantee that every interruption will be understood correctly. The shifts continue to be rebuilt later for the interface, for records, analytics and security systems. The difference is that they no longer control the main audio path.

What OpenAI published and when

GPT-Live was introduced to the public on July 8, 2026, with the GPT-Live-1 and GPT-Live-1 mini models. At the time, OpenAI stated that the models were full-duplex and could delegate search, reasoning or complex tasks to GPT-5.5 while keeping the conversation active.

On August 3, 2026, the company published the engineering paper that detailed how this behavior was implemented: continuous inference, WebRTC transport, instance switching without interrupting audio, context compression in parallel, and asynchronous delegation.

Therefore, August 3rd is the date of the technical explanation of the architecture, not the original product release date.

What does full-duplex voice AI mean

In a phone call, both people can make sound at the same time. Communication systems capable of sending and receiving simultaneously are called full-duplex.

GPT-Live applies this principle to the model: the input stream does not need to stop when the output begins. While the system speaks, it continues to receive audio and can decide whether to complete the sentence, pause, listen, respond to an interruption or forward a task. OpenAI claims that these decisions can occur repeatedly throughout speech, rather than just at the boundary between closed messages.

The difference compared to previous generations can be summarized as follows:

Comparison is based on OpenAI's own technical and product descriptions. It does not represent an independent test of quality.

Shift detector moved out of the audio path, not the entire system

The “turnless” formulation requires care.

GPT-Live removes the shift detector from the audio critical path. The model does not need to wait for a separate component to declare that the person is finished before it begins processing or producing speech.

At the same time, other parts of ChatGPT still need organized messaging. The interface needs to show who said what; analytics and security systems need records; Tools typically take discrete inputs.

To do this, the server uses partial transcriptions, speaking time and signals about who is speaking. The latest message remains tentative and may change as more audio arrives. Then, the system produces a version considered definitive for records and processes that cannot depend on an unstable history.

In practice, there are two representations:

• a speculative and updateable view, used during the conversation;
• a consolidated record, produced when speech attribution becomes more reliable.

This separation explains why a conversation can sound continuous, but the final transcript still appears fragmented, reorganized, or different from the audio heard.

How GPT-Live Continuous Path Works

1. Audio receives a priority route

The architecture separates media transport from application logic. Audio flows between the device and the model through a dedicated path. Tool calls, business rules and auxiliary services are left behind an asynchronous communication boundary between services.

Thus, a slow search may delay the search result, but should not directly block the sending of the next audio frames.

OpenAI also reported that it replaced a previous implementation based on Python and asyncio with Go components. According to the company, the 95th percentile of regularity of the new frame delivery now approaches the 50th percentile of the previous system. This is a result published by the supplier itself and not an independent measurement.

2. Inference remains active

In traditional systems, each request can be treated almost as an isolated operation. In an ongoing conversation, however, the model instance maintains state over a potentially long session.

When an instance needs to be replaced, the architecture described by OpenAI heats another in parallel, loads the conversation context and temporarily executes both before transferring the flow to the new one.

The same strategy is applied when the history grows and needs to be compressed. State compression and reconstruction occurs off the main path, while the previous instance continues to service the conversation.

This does not eliminate reconnection failures, loss of context, or delays. OpenAI itself reports that production testing has found memory pressure, state restoration issues, and race conditions in common disconnects.

3. Talking and thinking have become separable tasks

The voice model is responsible for immediate interaction. When the question requires a search, tool or deeper reasoning, it can delegate the work to a frontier model.

The helper template session can be created and preloaded when the conversation starts. Session affinity and prompt caching are used to avoid the entire context having to be rebuilt with each delegation.

While work occurs, the voice model can acknowledge the request, ask a clarifying question, or maintain dialogue. But there is an important limit: OpenAI itself recognizes that the voice model cannot hide a slow tool indefinitely. The total time for routing, inference, outbound calls, and callback is still part of the perceived experience.

4. WebRTC underpins transport

GPT-Live uses WebRTC as its transport base. The protocol already offers features necessary for real-time calls, such as connection negotiation, encrypted media, quality control, echo cancellation and compensation for variations in packet arrival.

OpenAI also described WARP, a set of proposals to reduce the rounds required when opening a WebRTC session.

Here there is a difference in language between the sources: the OpenAI paper summarizes the optimization as reducing six rounds to one, while the technical draft published in IETF's Datatracker describes two total rounds — one for signaling and one for media — when all optimizations are combined. The IETF document also makes it clear that this is an ongoing Internet Draft, without approved standard status.

One possible interpretation is that the “one” in the OpenAI article refers to the round remaining in the media path after the Instant Connect engine removes the signaling from the critical path. Still, the difference must be preserved, and not presented as a final specification.

What should change for those who talk

The architecture is designed to improve noticeable behaviors:

• interrupt the response without waiting for the end of a sentence;
• continue an idea after a brief overlap;
• tolerate pauses in thought without responding immediately;
• issue short confirmations while the person is still speaking;
• consult tools without muting all interaction;
• start or restore sessions with less delay.

These behaviors are not guaranteed under all conditions. The OpenAI Help Center advises that speech overlap, noise, network, and microphone settings can affect what the system hears. It also warns that voice transcriptions are not verbatim records of the conversation.

Therefore, “full-duplex” should be treated as a property of the architecture, and not as a promise of perfect understanding.

Availability August 4, 2026

On the date of this investigation, the Help Center indicated GPT-Live-1 for paid plans and GPT-Live-1 mini for Free users. The experience was available on supported web, iOS, and Android versions, but access depended on plan, region, app version, and workspace configuration.

For Business, Enterprise, Edu, and Healthcare environments, availability and activation could involve administrator controls and early access periods. The absence of the Live option on a specific account, therefore, does not prove general unavailability.

The API situation deserves a caveat. The August 3 engineering paper calls the GPT-Live API “future,” and the public catalog consulted on August 4 did not list GPT-Live-1 as a conversational API model — although it did list other Realtime models and a separate product called GPT Live Transcribe.

On the other hand, an update added to the July 31 release announcement mentions GPT-Live audio generated by ChatGPT Voice and the API.

Given this apparent inconsistency, it is not safe to say that the GPT-Live API was generally available to all developers on August 4th. Availability must be confirmed in your account and product documentation before publishing integration instructions.

Own protocol for testing GPT-Live

The protocol below is DBIO's own editorial proposal. It was not performed during the preparation of this article and does not represent an evaluation of OpenAI.

The goal is to enable reproducible comparisons across devices, application versions, and network conditions.

Record the environment before you begin

For each session, note:

• date, time and zone;
• account country or region;
• ChatGPT plan;
• voice option selected;
• intelligence level, when available;
• device and model;
• operating system and version;
• browser or application version;
• internal microphone, headset or Bluetooth headset;
• use of loudspeaker or headphones;
• network type: Wi-Fi, Ethernet, 4G or 5G;
• speed, ping and jitter measured immediately before;
• presence of noise and approximate distance from the microphone.

Do a minimum of ten repetitions per condition. For a more stable analysis of percentiles and infrequent failures, prefer 30 repetitions.

Record the screen and audio when everyone present has consented. Do not include personal data, secrets, restricted professional information, or sensitive content in prompts.

Test 1: direct interruption

1. Ask: “Explain, in about a minute, how photosynthesis works.”
2. Wait for the response to begin.
3. Two seconds into your speech, say clearly: “Stop. Summarize in one sentence.”
4. Measure the interval between the beginning of the word “stop” and the moment the previous output stops being audible.
5. Check that the new response respects the most recent statement.

Register:

• interrupt latency;
• words pronounced after the command;
• if the instruction was recognized;
• if the system repeated the previous section;
• if there was an abrupt cut, echo or artifact.

Test 2: speech overlap

1. Say: “I’m going to list three items and I don’t want a response until after the third.”
2. Say “notebook”, pause for a second and continue with “pen” and “eraser”.
3. If the system starts talking during pause, continue the list without stopping.
4. Ask them to repeat the three items in the original order.

The test observes whether the model continues listening while producing audio and whether it preserves the content received during the overlay.

Record the number of correct items, the order, any misattributions, and whether the user's speech was lost while the assistant spoke.

Test 3: initial latency

Use a new session and always say the same phrase: “Just respond with the word ready.”

Measure separately:

• time between tapping the voice button and the interface indicating that it is listening;
• time between the end of the sentence and the first sound of the response;
• total time between the initial ring and the audible response.

Alternate cold sessions, opened after closing the application, and hot sessions, started right after another conversation. Do not mix the two groups in the same result.

Test 4: reconnection

1. Start a conversation on a Wi-Fi network.
2. Provide three neutral pieces of information, such as a color, a number, and the name of a city.
3. During a reply, only turn off Wi-Fi to force migration to the mobile network.
4. After recovery, ask the system to repeat the three pieces of information.

Register:

• duration of interruption;
• existence of reconnection warning;
• resume or restart the response;
• loss of some data;
• speech duplication;
• complete session termination.

Do not perform this test while driving or in a situation where loss of connectivity could create a risk.

Test 5: tool use

Request information that requires current consultation, making the need for search explicit. An example is: “Consult the web and enter the forecast for tomorrow in Maceió, with the absolute date.”

During the survey, ask a short question about progress and see if the conversation continues.

Measure:

• time until first audible confirmation;
• time until final result;
• possibility to speak during the consultation;
• response to an interruption;
• presence of date and source;
• coherence between speech, text and visual card.

The test doesn't just measure the speed of the tool. It checks whether or not longer delegation blocks voice interaction.

How to publish results

Do not combine all devices into a single average. Post a line for each relevant combination.

For binary results, publish the full count, such as “8 hits out of 10”, rather than just “80%”.

Use median to summarize latency. Percentiles such as p90 or p95 should only be highlighted with a sufficient sample and accompanied by the total number of observations.

Also preserve bad cases. A voice system can seem fast most of the time and still fail significantly on reconnections, noise, or long sessions.

What this test cannot prove

A test performed on the ChatGPT interface measures the complete experience: device, operating system, microphone, local processing, network, OpenAI infrastructure, model, and audio playback.

It cannot isolate how much of the latency belongs to the model or the transport. It also does not provide access to internal inference times, server events, or the exact moment a delegation was created.

Results are valid for registered conditions, not for all users. Version, region, service load, and configuration changes may change behavior without warning.

The full-duplex architecture also does not allow us to conclude that the system offers more privacy, greater factual accuracy or perfect understanding of multiple people. GPT-Live is designed primarily for one-on-one conversations and can still be confused by noise, people talking over each other, and heavy overlap.

An architecture where the voice doesn't need to stop

GPT-Live's main change is to take tools, persistence and hard thinking out of the way of continuously delivering audio.

The voice model maintains the interaction; a more powerful model can work in parallel; the application reconstructs discrete messages later; and transport tries to preserve flow even when the network varies.

This makes a conversation less like pressing a button and waiting for a complete response. But actual quality remains dependent on the entire package — microphone, network, transport, tool, auxiliary model, and application decisions.

To keep up with the rest of the model ecosystem, the related read is “GPT-5.6 Luna just got 80% cheaper”. The article should only be used as context on models and costs, without turning price into evidence of voice performance.

Save this protocol and follow the series of tool tests, interruptions and reconnection on different devices.