How OpenAI Cut Voice Latency by Removing Steps
In OpenAI's August 2026 account of building its realtime voice system, the two biggest numbers sat outside the model: connection round trips fell from six to one, and the turn detector was removed from the audio path.
When a call feels sluggish, the model is the first thing anyone looks at. In OpenAI's August 2026 account of building its realtime voice system, the biggest numbers from six months of work sit outside the model.
All figures below are OpenAI's own, against its own previous system. Not an independent benchmark.
The Largest Number Lands Before Anyone Speaks
OpenAI built a transport protocol called WARP that cut the network round trips needed to start sending audio and data from six down to one. With Instant Connect on top, a client can open a session with one UDP packet.
Dashboards rarely capture this stretch. Most teams measure question-to-answer time, and those six round trips pass before that clock starts.
The Next Move Was Deleting a Component
Calling GPT-Live its third-generation voice system, OpenAI wrote that it removed the turn detector from the audio path. The piece deciding whether the other person had stopped talking is gone.
Once the model listens and speaks at once, there is no decision left to make. Nothing was made faster. A step was deleted.
None is a swap for a faster part. OpenAI's own disclosures.
The Third Change Was a Rewrite
The media frontend and inference logic moved from Python asyncio to Go, reported this way.
new system p95 = previous system p50
No absolute millisecond figures were released, only percentiles. The slow tail moved to where the middle used to sit.
Tool calls and heavier reasoning also moved onto a separate asynchronous path, so a slow backend cannot stall the conversation.
Reading This From a Contact Centre
None of the three answers which component to swap for a faster one. That changes where to look.
- Check whether connection setup is measured on its own. A dashboard tracking only response time has no column for it
- Count the steps in the path. Removing one beats optimising it
- Check whether external lookups hold the call. If speech stalls while a CRM query runs, the paths were never separated
There are two ways to reduce latency. Do it faster, or do not do it.
When This Does Not Transfer
Two of these travel badly.
- Dropping the turn detector only works when the model listens and speaks at once. A staged STT → LLM → TTS stack has nothing else to tell it a sentence ended. Remove endpointing there and it cuts people off
- WARP is a WebRTC protocol, as its name says. For calls arriving over the public telephone network, the carrier leg is not yours to change, and six-to-one does not carry over
Which items apply depends on how the stack is built.
At BringTalk we count a path's steps before reading its response time. While a step can still be removed, changing the model comes after.
Baseline: In OpenAI's own account, the largest numbers were connection round trips going from six to one, and the turn detector's removal. None of the three changes was a faster part.
