The sub-second shortlist: picking the right OpenAI model for live voice

Three numbers from the run

What was measured, and how

A voice turn isn't a benchmark. It's a stack, and the model is one slice. This benchmark isolates that slice and stresses it the way live traffic would.

Each of the twelve models was given the same Voice AI-shaped prompt and the same generation budget. Five timed runs per model after a warmup, then a separate cold-start pass to expose tail behaviour. Where supported, both default and priority tiers were tested; where priority was unavailable the request fell back to default and the row is marked accordingly.

Three numbers reported per model:TTFT median (time to first useful token),TOTAL median (request to last token of a short voice-turn response) and TOTAL p95(the tail the caller will eventually hear). Reasoning models (GPT-5.2 / 5.4 / 5.5) were run with effort=none. Non-reasoning models were run at temp=0.2.

Five runs per model, warmed, priority routing

Sorted by total median latency. This is the kindest possible condition for each model: pre-warmed connection, priority queue, short voice-turn output. The shape of this table is what shows which models belong on the live turn and which belong elsewhere in the pipeline.

Priority routing is not a uniform speed-up

Priority is sold as a flat upgrade. The data says otherwise. The biggest gains landed on the smallest, fastest models, exactly the ones whose default-tier latency was already being dominated by queue time, not compute. Reasoning models shed hundreds of milliseconds in absolute terms but their floor is set by thinking, not routing.

Two models (GPT-4o Mini and GPT-5.2) actually gotslowerunder priority in this run, by 22% and 16% respectively. That's a strong signal not to assume priority is a free improvement; benchmark it on your own prompt and your own time-of-day before you commit a production voice path to it.

The same lineup, through a buyer's lens

Latency decides whether a model can hold a turn. Token cost, context window and knowledge cutoff decide whether you can afford to keep it on the turn at scale, with the right history, against the right facts.

Pick by behaviour, not benchmark

Latency tells you whether a model can talk. It does not tell you whether the model should hold the tool surface, orchestrate a multi-turn flow, or grade the call once it ends. Each tier in OpenAI's lineup has a job; the timings alone don't show you which one.

Nano tier: fastest off the line, best as a gate

GPT-4.1 Nano and GPT-5.4 Nano post the lowest TTFT figures and benefit most from priority routing. In practice, nano models are less consistent at chained tool calls: JSON arguments occasionally drift and multi-call sequences can break across turns. Excellent as a first-pass intent classifier, language detector or confidence gate; better not deployed as the model holding the tool surface in a multi-step voice flow.

Mini tier: fast enough, best on bounded sub-tasks

GPT-4.1 Mini and GPT-5.4 Mini look ideal at first glance: ~700 ms total, sub-second p95, decent token throughput. The thing to watch for is conversational. Across longer voice flows, minis can lose track of where they are, skip pre-conditions on tool calls and re-ask questions the caller already answered. Strong for one-shot tasks (summarise, extract, classify); not the right tier for long-conversation orchestration.

Reasoning tier: smart, accurate, best off the live path

GPT-5.2, GPT-5.4 and GPT-5.5 land between 1.27 s and 1.36 s on total median, with p95 spikes north of 4 s on tail events. These models consume most of the turn budget on their own, leaving little room for ASR finalisation, retrieval, validation and TTS. They are exactly what you want for post-call analysis, evaluation, scoring and summarisation, just not on the live wire.

Full-model tier: GPT-4.1 is the orchestration pick

GPT-4o posts the lowest TTFT, the lowest total median and the tightest p95 in this run. It is also the model with the most-documented weaknesses on instruction-following and hallucination. GPT-4.1 lands ~250 ms slower at 783 ms total, 885 ms p95, and is a material upgrade on instruction-following, tool-call discipline and factuality. For a live turn that has to behave reliably, that latency gap is worth paying.

The right answer is a per-turn portfolio

Holding a sub-second turn on OpenAI doesn't come from picking one best model; it comes from routing OpenAI's full lineup, one tier per job,per turn.

1. GPT-4.1 on the live turn.The conversational orchestrator. Tool selection, argument formation and the spoken response.
2. Mini for specialised assistants.Bounded, one-shot sub-tasks: summarisation, extraction, classification, intent shaping.
3. GPT-4.1 for complex chains.When a flow has to coordinate multiple tool calls and persistent state across turns, the same instruction-following and tool-call discipline pays compound interest.
4. Reasoning off the wire.Grade calls, enrich CRM notes, run evals overnight. Never on the live turn budget.

The right voice model is a portfolio

For the live conversational turn, GPT-4.1 is the natural fit: slightly slower than GPT-4o but a material upgrade on instruction-following and hallucination, which is what production voice actually needs. For specialised one-shot assistants, mini suits the role. For complex multi-step chains, the same full-tier GPT-4.1 carries the orchestration. For evaluation off the wire, reasoning models.

The question "which OpenAI model is best for voice?" is the wrong one. The right one is "which OpenAI model belongs on this turn?"