OpenAI GPT-Live Shows the Trade-Off Behind Faster Voice AI

GPT-Live keeps a cloud session open

OpenAI published a detailed engineering account of GPT-Live on 3 August 2026. The voice model is full duplex: it listens while it speaks, so a user can interrupt without waiting for the answer to finish. Audio streams to OpenAI and generated speech streams back.

The connection uses WebRTC rather than a record, upload, transcribe, answer, and playback sequence. OpenAI also uses a transport protocol called WARP, which it says cuts WebRTC startup from six network round trips to one. The company reports that the new system's 95th-percentile frame delivery time matched the median of its previous voice system. Those figures come from OpenAI, not an independent benchmark.

The inference session keeps conversational state ready. If a model instance needs replacing, OpenAI prepares another instance and rebuilds its context cache before switching over. Slower work can be delegated to another model while the voice session continues. Session affinity and prompt caching reduce the delay when that model is called.

These changes explain the speed without treating latency as a single model metric. Connection setup, audio transport, cached context, speech generation, and model handoffs all contribute.

Audio, transcripts, and retention

GPT-Live requires microphone audio to leave the device. OpenAI's application also turns the continuous audio into transcripts and messages for chat history, analytics, and delegation to other models.

OpenAI's Voice Mode FAQ says voice clips are stored with the transcript. Deleting the chat schedules those clips for deletion within 30 days, subject to stated security and legal exceptions. Content already disassociated from an account after being shared for training may also be retained.

Training has separate controls. OpenAI says voice audio and video are not used for training unless the user opts in to sharing them. Transcripts and uploaded files may still be used when "Improve the model for everyone" is enabled in Data Controls.

Turning training off does not make the session local. It limits a later use of the data; the live audio still travels to OpenAI for inference.

Local voice avoids the upload, with limits

A fully local voice system can keep speech recognition, model inference, and speech synthesis on the phone or computer. It can work offline and avoid sending the conversation to a provider. The cost is borne by the device: model size, available memory, battery, heat, and speech quality become practical limits.

Some products are hybrid. They may detect a wake word locally but upload audio, or transcribe locally and send the transcript to a remote model. A privacy claim should name each stage and its destination.

CuriousLM currently provides local text chat and file workflows. It does not offer GPT-Live's full-duplex voice experience, so it would be misleading to present it as a direct replacement. The relevant distinction is that ordinary CuriousLM inference stays on the device, while GPT-Live depends on a continuous cloud session.

Check before a sensitive conversation

For any voice assistant, check where raw audio is processed, whether a transcript is created, how long clips are retained, and whether deleting a chat also removes its audio. Training, storage, and inference settings are separate controls and should be read separately.

An airplane-mode test can confirm whether a prepared feature works offline. It cannot establish what happened during earlier connected sessions. Network inspection can identify contacted domains, although encryption may hide the transmitted content.

GPT-Live is a strong example of cloud engineering reducing conversational delay. Its responsiveness does not change the underlying data path. For sensitive conversations, the useful questions remain direct: who receives the audio, what is stored, and how it can be deleted.