The Sub-300ms Latency Figure for GPT-Live Is Not for GPT-Live

7 SEP 2026 — OpenAI has published an architecture account of GPT-Live, the full-duplex voice system behind ChatGPT Voice, describing a latency-sensitive media path separated from application work by an asynchronous boundary. The number circulating alongside it — sub-300ms — is not a GPT-Live figure. OpenAI has published no end-to-end latency benchmark for GPT-Live at all.

Where the number actually comes from

The figure that exists is a median time to first audio chunk in the 300 to 600 millisecond range, and it belongs to GPT-4o Realtime v2, a different model in a different product surface.

Time to first audio chunk is also not end-to-end latency. It measures how long until the first fragment of speech starts playing, not how long until the system has finished deciding what to say. For a full-duplex system where the model can be interrupted mid-sentence, those two quantities can diverge substantially.

So the "sub-300ms GPT-Live" claim compresses three errors. It borrows another model's number, applies it to a different metric, and reports the bottom of a range as the whole of it.

The architecture is the real news

The design OpenAI disclosed is more interesting than a benchmark number. The live path holds the media pipeline and the inference loop. Delegation, tool use, persistence and the rest of the application logic sit behind an asynchronous remote procedure call boundary, off the path that has to keep audio flowing.

That split is the standard answer to a hard conversational problem. Anything on the critical path adds jitter, and jitter in speech is far more noticeable than in text: a person will forgive a slow answer and will not forgive one that stutters.

Putting tool calls behind an async boundary means the model can keep talking while a lookup runs, rather than going silent. It is the same reason a human says "let me check" instead of stopping dead.

Full duplex is the capability claim worth testing

Full duplex means both sides can talk at once — the model can be interrupted, and can register that it has been, without a turn-taking protocol pausing the conversation.

This is a departure from the older transcribe-generate-synthesise pipeline, where each stage had to wait for the one before it. Eliminating the text pipeline removes both the latency of those hops and the information they discarded, because tone, pace and hesitation do not survive a transcript.

It is also the hardest part to evaluate from outside. No public benchmark covers interruption handling, no standard measure exists for how quickly a model yields the floor, and no figure has been published for how often it talks over a user. Those are the numbers that would describe the experience, and none of them exists.

It is a product, not an API model

GPT-Live powers ChatGPT Voice across iOS, Android and the web. It is not available as an API model, which means no third party can benchmark it independently or build against it.

That matters for how the claims should be read. An API model gets measured by everyone within a week of release, and the vendor's numbers get checked. A deployed product surface is measured by the vendor alone, and the architecture note is the only account there is.

That also explains the shape of the disclosure. A company that publishes an architecture essay instead of a benchmark table is describing what it built, not how well it performs, and those are different disclosures serving different purposes.

What a useful voice benchmark would measure

A useful benchmark would measure four things, none of them published by anyone in a comparable form. End-to-end response latency measured from the user finishing speaking to the model producing intelligible audio, which is what a person actually experiences.

Interruption latency: how long between a user starting to speak and the model stopping. Recovery behaviour after an interruption, because resuming coherently is harder than stopping. And the tail rather than the median, since a conversation is ruined by the slowest exchange in it rather than the typical one.

The median is the figure vendors publish, and it is the least useful of the set. A system with a 300ms median and a two-second ninety-fifth percentile feels broken, and both numbers are true.

How to read the coverage

This repeats the pattern from OpenAI's Astra launch last week. The headline ARC-AGI-3 score depended on a harness OpenAI built, and the standard harness gave a much lower number. The mechanism repeats: a real figure, attached to the wrong thing, travelling further than the caveat.

The defensible summary is narrower than the headline and still worth having: OpenAI has built a full-duplex voice system, has explained how it separates the media path from application work, and has not said how fast it is.