We benchmarked native speech-to-speech models, a DIY cascade, a managed platform and an open framework with one harness and one clock, measured from what the caller actually hears. Here is the leaderboard nobody publishes, what a call costs per correct answer, and the turn-taking failure the entire industry currently shares.

Benchmark scope: 499 recorded live calls · ~20 configurations · <$2 total API spend

The fastest voice-agent stack we measured answers a caller in 707 milliseconds, but only when the hardest problem in voice AI is solved for it in advance. Give the same stacks that problem back, the way a real phone call does, and the honest numbers land between 758 ms and 2.4 seconds. And when we placed a 680 ms pause in the middle of one sentence (the kind a person makes while glancing at a calendar), every single endpointing technology on the market failed: 0 clean passes in 65+ attempts, across OpenAI, Google, Deepgram, ElevenLabs and LiveKit alike.

We measured all of this ourselves. In one day we placed 499 recorded live calls against four architecture classes (OpenAI's and Google's native speech-to-speech models, a hand-assembled STT → LLM → TTS cascade, ElevenLabs' managed agent platform, and the open-source LiveKit Agents framework) with one harness, one audio corpus and one definition of latency: the time from the caller's last spoken sample to the first audible sample of the agent's reply. Total API spend for the entire benchmark: under two dollars.

This article contains two leaderboards that must never be merged into one, a decomposition of where the milliseconds actually live, six things platforms did that we did not ask for, the cost of a call normalised to a correct answer rather than a turn, and a live agent you can call to check our numbers yourself.

Every vendor number measures a different clock

If you have shopped for a voice-agent platform this year, you have seen the numbers: ElevenLabs Flash advertises ~75 ms, Cartesia advertises a sub-90 ms voice stack, Vapi publishes a target of p50 < 500 ms, Retell's homepage says ~600 ms. None of these numbers is a lie. None of them is the number your caller experiences either, because each one starts and stops its clock somewhere different: model inference only, TTS first byte only, a server-side window with the endpointing wait conveniently outside it.

The people running these agents in production have noticed. In an r/AI_Agents post-mortem of a fintech voice deployment, the conclusion was blunt:

Single-call latency looked fine… Then we'd hit real concurrency and one provider started spiking to 800ms+… Measure at YOUR real concurrency, the demo number is a lie. (r/AI_Agents)

And the component that dominates the caller's experience is rarely the one being advertised. A widely-shared breakdown of a real conversational turn put endpointing (the machine deciding you have finished speaking) at roughly 700 ms, about 53% of the whole latency budget, while teams spend their weeks optimising the LLM (r/AI_Agents). The builder of a much-discussed sub-500 ms hand-rolled agent on Hacker News reached the same place from the other direction:

Switching from fixed silence thresholds to semantic end-of-turn detection was night and day. We burned weeks early on optimizing STT accuracy when the actual UX killer was the agent jumping in mid-sentence. (Hacker News, March 2026, 570 points)

The median gap between human speakers in conversation is close to zero milliseconds. Listeners routinely start before the speaker finishes. A production operator running outbound calls describes the half-second of silence after the callee says "Hello?" as the "Uncanny Valley death zone" where people simply hang up. Every hundred milliseconds is audible.

What existing benchmarks cover, and what none of them do

Independent measurement does exist, and we used it to position our own. Cekura Bench runs the same scheduling task across seven platforms and ranks reliability, but its response time is measured at Cekura's own agent layer, and each vendor chose its own stack. Openbenchmarks is the closest prior work to ours: caller-side time-to-first-audible-byte from dual-channel recordings, and it found no managed platform under one second (medians 1,296-1,740 ms), but it covers only five managed telephony platforms, pins endpointing to a fixed 0.1 s (which disables exactly the semantic endpointing behaviour that fails in production), and is run anonymously. The much-cited Tested Media 500-call study reports 680-920 ms medians with no published detection methodology, and its numbers contradict Openbenchmarks by roughly 2×. Artificial Analysis benchmarks models and TTS components over raw APIs, telephony explicitly out of scope. Academic work on pause handling (Full-Duplex-Bench, IHBench) tests research models only: it has never been run against commercial production stacks.

So, as far as we can establish, no public benchmark before this one has done any of the following, let alone all of them at once: measured caller-side audible-first-audio with one identical harness across all four architecture classes; probed mid-utterance pauses on commercial stacks; joined billing data to verified task outcome into a cost per clean success; and audited what the agent actually said by independently re-transcribing its audio. That is the gap this benchmark fills.

What we measured, and what we refused to count

One metric anchors everything:

speech_end_to_first_audible = first audible output sample (−42 dBFS, two consecutive frames) − last active input sample (fixed acoustic timeline, monotonic clock)

Not time-to-first-byte, not first packet, not a server-side stage timing. It is the first moment a caller would hear the agent. Audio goes in with real 20 ms pacing; a trial is invalidated if pacing drifts. WebSocket handshakes and session setup are recorded but excluded. Every trial stores its raw event log, response audio and provider usage, and nothing gets averaged away: a genuine ~2-second Groq queue outlier that landed during calibration stayed in the data.

Four scripted caller utterances (synthetic English voice, manually verified speech-end markers) probe four different failure surfaces:

Test corpus: Four fixtures, four failure surfaces

The second methodological anchor: there are two different clocks, and mixing them is how vendors mislead you and how demos fool your own team.

Leaderboard one: reaction speed, with the endpoint solved for free

Clock A first. Every row below received an explicit end-of-speech signal: the purest measure of how fast an architecture can react, and the closest thing to the conditions vendor demos are filmed under.

Three things worth pausing on. A well-assembled cascade (supposedly the legacy architecture) beat every native speech-to-speech model on reaction speed. Quality and speed pulled in opposite directions everywhere: the fastest stacks dropped the leading "A" from a spoken confirmation code, while the only model with a perfect score was also the slowest and, per turn, the most expensive. And these are the best possible numbers: no stack gets its endpoint handed to it on a real phone call.

Leaderboard two: the production clock, where endpointing lives inside the number

Clock B. Same corpus, same audible-audio detection, but now each stack must decide for itself when the caller has finished. We report the hesitation fixture ("Um, I need to, uh, reschedule…"), because it is the only endpointing probe that anything passed.

This is the chart that explains a familiar disappointment: why the platform that felt instant in the demo feels sluggish on a real line. Nobody lied to you. The demo was running on Clock A, and your customers live on Clock B. And on Clock B, only one configuration we measured combined sub-second speed with intact accuracy on codes: an open-framework stack we tuned ourselves.

Notice also what the fastest production row buys its speed with. Qwen3-4B answers in 758 ms, and mangled the confirmation code all seven times. A user on r/AI_Agents captured why raw speed is not the whole story from the perception side, too: their agent with a 280 ms p99 felt slower to users than a competitor's 450 ms agent, because the competitor stopped talking faster when interrupted. Latency is a system property, not a model property.

The 680-millisecond wall: 0 of 65

Here is the caller utterance that broke everything:

"I'd like to book [~680 ms silence] an appointment for Friday at three."

A perfectly ordinary pause: someone checking a calendar mid-request. It creates a trap: at the moment of silence, the transcript so far ("I'd like to book.") is grammatically complete but semantically unfinished. Every endpointing technology we tested walked into it.

The Gemini row deserves its own warning label, because it is the failure you will not catch. Gemini's server VAD never barged in: a timestamp-only check would grade it a pass. But the usage metadata shows it accepted 36 input audio tokens where manual control accepted 92: it quietly discarded everything after the pause and then confidently answered a question the caller never asked. We only caught it because the harness audits input-token counts against a control run. If your monitoring watches timestamps and not content, this failure mode is invisible in production.

What this means architecturally. Silence thresholds, semantic text detectors and prosody models all approximate the same question ("has this person stopped talking?") when the question that matters is "is this request complete?" Those are different problems. Until providers ship completeness-aware endpointing, a production phone agent needs an application-level completeness gate on top of any built-in detector: hold the turn briefly when the parsed intent is missing required slots, release it fast when it is not. Practitioner data agrees on the size of the prize: the best end-of-turn detectors get 94.0% of turns right against 46.9% for a plain silence timer. Nobody's built-in detector got 680 ms of mid-sentence silence right even once.

Where the milliseconds actually live

Because the harness records per-stage timings, we can decompose the production clock instead of guessing at it.

Figure 5: Per-stage medians across three production-grade stacks (ms)

Three engineering conclusions fall straight out of the decomposition.

The pause dominates, and it is yours to tune. On LiveKit's defaults, more than half the endpoint stage was a configured safety delay, not computation. Cutting VAD minimum-silence and endpoint delay from 0.55/0.50 s to 0.25/0.25 s took the end-of-turn decision from 586 ms to 271 ms without one false cutoff on the hesitation corpus. That single knob was worth more than any model swap.

An extremely fast LLM buys real, honest speed, and quality decides whether you can afford it. Qwen's 45 ms first token is genuinely the fastest component we saw all day. It also returned confirmation codes as digit strings with the leading letter missing, seven times out of seven. Exact-code accuracy tracked the LLM, not the pipeline: GPT-4.1 mini scored 7/7 on the identical ASR and voice. If your calls contain booking codes, account numbers or phone numbers, the model, not the plumbing, is your accuracy budget.

Batch STT has no place in a live call path. We ran the official batch-Whisper recipe head-to-head against streaming STT with everything else held constant:

Six things platforms did that we did not ask for

Benchmarks usually publish tables. The incidents below are, in our view, worth more than the tables: each one is a production outage or a corrupted A/B test waiting to happen, and none of them appears on a pricing page. All were observed and logged on a single bench day; platform behaviour can and does change.

1. The platform silently swapped our model

We created an ElevenAgents agent configured with gpt-oss-20b. The platform accepted the configuration and silently substituted a hosted Qwen reasoning model, which then exhausted its token limit three times without producing a single answer. No error, no warning. Had the harness not verified the observed LLM in conversation metadata on every trial, we would have spent the day benchmarking the wrong model and published numbers about a stack that did not exist.

2. A hidden fallback added 3.26 seconds

The default agent configuration shipped with an undocumented backup-LLM cascade. In our first smoke test it fired mid-turn and delivered a duplicated answer 3.26 s late. Every measured run afterwards had it explicitly disabled. If you run an agent on defaults, some fraction of your calls are being answered by a model you did not choose, at a latency you did not budget.

3. A dead voice looks exactly like a working agent

Mid-benchmark, an ElevenLabs free-tier TTS quota ran out. The failure mode was remarkable: the TTS socket closed silently, the agent kept "responding" (in text, with no audio whatsoever), and nothing in the logs said anything was wrong. 29 calls were lost before caller-side audible verification caught it. If your monitoring checks that the agent responded rather than that the caller heard something, you can be paying for a mute agent for days.

4. The tuning knob that silently does nothing

Two full tuning rounds on LiveKit 1.7.0 measured no change, because a deprecated endpointing parameter was being silently ignored when a turn detector was active, with no warning anywhere. Server-side stage metrics, not logs, revealed the pause had never moved. Verify tuning through measured behaviour, never through configuration files.

5. The letter "A" keeps vanishing from spoken codes

Across three separate vendors' small models, the confirmation code "A seven B four two Q" came back without its leading "A": OpenAI's mini twice in five attempts, Gemini four in five, GPT-4.1 nano seven in seven. Separately, an expressive voice model whose LLM text was correct swallowed the final "Q" at the synthesis stage in two of three readings. Spelled-out alphanumerics were the single most fragile content type we measured anywhere in the pipeline, consistent with an independent 13-provider STT study on real calls that found postcode-style strings the hardest input for every provider. If your calls involve codes, test codes. Nothing else predicts them.

6. The failure that only an audit can see

Gemini's tail-loss behaviour from Figure 4 generalises into a monitoring principle: two of the day's worst failures (dropped audio tail, mute agent) produced no error, no timeout and no anomalous timestamp. They were caught by auditing content: input token counts against a control, and independent re-transcription of output audio. An agent stack without a content audit isn't monitored; it is merely running.

A cheap model that breaks codes is the most expensive model you can buy

Vendors price per turn or per minute. A business pays for outcomes. So we computed both: the measured cost per turn, and that cost divided by the fraction of turns that were verifiably correct: cost per clean success. The re-ranking is instructive.

Read the bottom two rows. The "cheap" managed arms, nano and Qwen, are the most expensive configurations on the whole chart once you pay for their failures. And on a managed platform the model barely matters to the bill in the first place: 90-96% of the ElevenAgents per-turn cost was the platform's duration-based fee, making conversation length, not token count, the real cost lever. On the DIY cascade the structure inverts: TTS is ~84% of turn cost and the LLM is around 2%. Different architectures, different levers, neither visible on a rate card.

For scale: at our measured rates, a 5,000-call month of three-turn conversations runs roughly $29 per month of clean successes on the tuned cascade versus about $90 on the best managed configuration, plus a $37.49/month server for the self-hosted route. Both are rounding errors next to one staffed phone seat; the difference that matters is control, which is the subject of the next section.

Geography is real, but only after you shorten the pause

We ran the champion stack from seven server locations across two continents, expecting the usual answer: closer to the AI providers is faster. The measured answer was stranger and more useful.

Figure 8: Provider round-trips by server location (median ms)

On out-of-box settings, moving the entire stack from Helsinki to Oregon changed the end-to-end median by one millisecond: 1,041 ms vs 1,040 ms. The framework's default behaviour starts LLM and TTS work speculatively while the endpoint detector is still sitting in its 500 ms safety pause, so hundreds of milliseconds of provider proximity simply hide behind the pause. Only after we cut the pause did geography start paying: the same tuned configuration ran 971 ms in Oregon against 1,114 ms in Helsinki, and the Helsinki run began making code errors, because tighter timing plus longer round-trips squeezed the transcription window. Swapping the voice to the TTS tournament winner finished the job:

The order of operations is the lesson. Region-shopping before endpoint tuning measures nothing; endpoint tuning before region-shopping leaves quality on the table. Tune the pause, then move the server, then pick the voice, each step validated against a quality gate, or you will ship a faster agent that mispronounces booking codes.

What we would deploy today

Three routes survive the data, for three different situations.

And one requirement all three routes share: an application-level guard for the mid-sentence pause, because as of the day of measurement, no provider will do it for you. Ours, an asymmetric completeness gate that holds the turn only when the parsed request is missing required information, is the next experiment on this bench.

What the evidence supports, and what it does not

We would rather bound these numbers ourselves than have you discover the bounds later. This was a screening benchmark: 5-21 measured turns per cell. Medians at that sample size are informative; the p95s are diagnostic only, and no row here should be quoted as an SLA. The corpus is synthetic English; a Russian-language and human-recorded corpus is planned, and quality results do not transfer across languages, a point practitioners have made sharply about vendor tiers that were "equivalent" in English and not in Japanese. All numbers are model-and-framework latency over WebSocket/WebRTC: no PSTN carrier leg, no SIP bridge, no telephone playback. The caller-side telephony round is the next phase, and it will add real milliseconds to every row equally. Single-turn exchanges only; multi-turn context, barge-in economics and concurrency behaviour are unmeasured here. And the platforms are moving targets: we watched one silently swap a model mid-benchmark, which is precisely why these numbers describe one day of measured behaviour rather than a standing ranking. Per-turn raw logs, event traces, response audio and configuration snapshots exist for every figure above; we share them with clients on request.

Call the benchmark yourself

Codebridge Voice Lab

We kept the benchmark running as a live, browser-based switchboard. Six lines, fastest first (the tuned LiveKit champion, the managed ElevenAgents arms, the batch-Whisper stack and the Flux end-of-turn stack), each labelled with its measured median. The page shows your personal speech-end→first-audio latency on every turn, measured in your own browser, plus the live per-second cost of the call computed from actual usage.

Three things to try, in order:

• Ask "What time do you close today?", then watch the latency meter.
• Dictate "My confirmation code is A seven B four two Q. Repeat it back.", then check the leading "A".
• Say "I'd like to book…", pause for one beat, then "…an appointment for Friday at three." You will hear the 680 ms wall for yourself.

Open the Voice Lab

How we build agent systems

How Codebridge approaches voice agents

We are an engineering firm, and this benchmark is how we start voice-agent work: measure first, on the clocks that match your callers, before anyone argues about platforms. The founding team came out of Big 4 consulting, which left us with a habit the tables above reflect: every number keeps its provenance, and vendor-reported figures are labelled as such.

If you are putting an agent on a phone line, the engagement that follows from this article is a fixed-fee discovery: we run this same harness against a corpus built from your real call recordings (your codes, your names, your interruptions) across the shortlist that fits your constraints, and hand you the two leaderboards, the cost-per-clean-success table and a deployment recommendation. You keep the harness, the raw data and everything we build on it. Sometimes the recommendation will be a managed platform and a two-week integration; we will tell you when it is, and show you the bill either way.

Book a 30-minute call

FAQ

What is a good latency for an AI phone agent?

Humans leave near-zero median gaps between conversational turns, so every added millisecond is perceptible. From our measurements and production reports: under ~800 ms feels responsive, ~1.0-1.3 s is serviceable for most business calls, and beyond ~2 s callers start talking over the agent and abandoning. Measure it as the caller hears it (speech end to first audible audio, with endpoint detection inside the number) or the figure will flatter you by 300-1,700 ms.

Why does my voice agent interrupt callers mid-sentence?

Because its endpointing treats silence, sentence grammar or prosody as a proxy for "finished", and a natural mid-sentence pause satisfies all three. In our testing, a 680 ms pause inside one sentence defeated every built-in detector on the market, 0 clean passes in 65+ attempts. The fix is an application-level completeness gate: hold the turn briefly only when the request is semantically incomplete, and pair any tuning with a false-cutoff test, since faster settings buy more wrongful interruptions.

Are native speech-to-speech models faster than STT→LLM→TTS cascades?

Not in our measurements. With the endpoint held constant, a Deepgram→Groq→ElevenLabs cascade (706.8 ms median) outpaced Gemini Live (786.4 ms) and both OpenAI Realtime models (888.8 and 1,140.1 ms). Native S2S buys other things (simpler integration, prosody carried through the model), but raw reaction speed is currently won by well-placed, well-tuned components.

How much does an AI phone call actually cost?

Per measured turn: roughly $0.002 on a self-assembled cascade and $0.005-0.006 on a managed platform, where 90-96% of the price is a duration-based platform fee. The number that matters is cost per correct answer: configurations that fail tasks quietly inflate it: the cheapest managed model we tested became the most expensive per clean success (+62%). Budget on outcomes, not on rate cards.

Can I trust vendor latency numbers?

Trust them to describe what they actually measure, which is rarely a caller's experience. Advertised figures we examined ranged from TTS model inference (75-90 ms) to platform targets with undefined windows (<500 ms), while independent caller-side measurement of managed platforms finds 1.3-1.7 s medians. The reliable procedure is the one practitioners keep converging on: measure caller-side, at your concurrency, on your corpus, and date every number.

Sources and further reading

• This benchmark: all first-party figures measured on our harness in one day (499 recorded live calls; per-trial logs, audio and config snapshots retained). Exact model IDs: gpt-realtime-2.1 / -mini, gemini-3.1-flash-live-preview, Deepgram Flux + nova-3, Groq openai/gpt-oss-20b, ElevenLabs Flash v2/v2.5 + Agents platform, Cartesia sonic-3.5, LiveKit Agents 1.7.0.
• Prior benchmarks: Cekura Bench · Openbenchmarks TTFAB · Tested Media 500-call study · Artificial Analysis S2S methodology · Full-Duplex-Bench
• Community threads cited: HN: sub-500ms voice agent from scratch · HN: Launch of Speko (endpointing 94.0% vs 46.9%) · HN: STT on 100 real calls · r/AI_Agents: endpointing ~53% of the budget · r/AI_Agents: fintech post-mortem · r/AI_Agents: 280ms felt slower than 450ms · r/vapiai: the opening-silence death zone
• Vendor documentation: OpenAI Realtime API · Gemini Live API · Deepgram Flux · ElevenLabs API · Cartesia TTS · LiveKit Agents · Groq

© 2026 Codebridge Technology, Inc. Measurements are point-in-time observations of third-party services on the date of testing; provider behaviour, models and pricing change. Product names belong to their owners.