How fast do Vapi and Retell actually respond? We measured it from the audio, not the dashboard.

Every vendor publishes a latency number. None of them can be compared with another vendor’s, because each measures a different thing at a different point in the pipeline. So we measured one thing, the same way, for both: the silence between the caller finishing a sentence and the agent starting to speak, from dual-channel phone recordings.

10 calls (5 per platform), 3 caller turns each, 16–18 September 2026 · raw data

Why the vendor numbers do not compare

Retell’s API reports an end-to-end p50 per call. Vapi reports no equivalent; it exposes per-message timestamps from which you can compute something latency-like. On our first pass we did exactly that and got 1,682 ms for Retell against 1,540 ms for Vapi — and then realised the two definitions differed by more than the two numbers did. Publishing that table would have been worse than publishing nothing. This page exists because we threw it away.

Method

Calls were placed from a Twilio phone line with a scripted text-to-speech caller and recorded with RecordingChannels=dual, which puts the agent on one channel and our caller on the other. (Twilio’s default mono recordings are useless for this: they begin after the agent has already started its greeting, and a first pass with a voice-activity detector returned an onset of 0.00 s for all sixty of them. That is the detector finding speech already in progress, not a measurement.)

Detector: webrtcvad aggressiveness 2, 20 ms frames, >=120 ms speech, RMS floor 400; caller segments merged across gaps <=600 ms; latency = caller-turn-end to next agent-speech-onset, from Twilio dual-channel recordings (ch0 agent, ch1 caller). Before trusting it we checked channel isolation by hand: during the agent’s greeting the caller channel measured 0 RMS on both platforms; during the caller’s turn the agent channel measured 107 (Vapi) and 0 (Retell) against speech levels of 2,000–3,900. There is no crosstalk to confound the onsets.

The scripted caller said three things, in order: a short request (“Hi, I would like to book an appointment please”), a name and a ten-digit phone number, and a short confirmation (“Thursday morning works great”). The same agent prompt ran on both platforms with the same model (gpt-4o) and the same voice provider.

Results, per turn

Caller turn	Retell median (ms)	Retell, all 5	Vapi median (ms)	Vapi, all 5
1 · short request	640	680, 540, 640, 600, 680	1460	1620, 1420, 1460, 1380, 1500
2 · name + phone digits	2560	2560, 2280, 2020, 2940, 3000	2040	2080, 2080, 2040, 1860, 1820
3 · short confirmation	1300	1000, 1200, 1500, 1700, 1300	1440	1380, 1560, 1440, 860, 2060
All 15 turns	p50 1300 · p90 2940	540–3000	p50 1560 · p90 2080	860–2080

p90 is nearest-rank on n=15. Per-turn medians are the honest unit here; the pooled p50 mixes three different kinds of turn.

What the shape says

Retell is fast when the caller says something short and slow when the caller reads out digits. 640 ms on the opener — roughly 2.3× quicker than Vapi — then about 2.5 s after a name and phone number, with one turn at a full 3.0 s. That pattern is consistent with endpointing: the platform waiting longer to be sure a string of digits has finished. Vapi is flat. Around 1.4–2.0 s whatever the caller said, never under 860 ms and never over 2,080 ms.

So a median-only comparison — which is what every vendor publishes — would say “Retell is 260 ms faster” and hide that Retell is the platform that occasionally makes a caller wait three seconds after giving their number. Whether you prefer a fast-then-slow receptionist or a steady one is a real choice; it is not the choice the headline number describes.

The vendor’s own figure, checked. Retell’s API reported an end-to-end p50 of 1,682 ms across these same calls. Measured neutrally it was 1,300 ms. Retell’s self-report is pessimistic by about 380 ms — it appears to include stages a caller never hears.

Caveats, stated plainly

n = 15 turns per platform. Enough to see the shape; not enough to put error bars on a 260 ms difference. Treat the per-turn medians as the finding and the pooled percentiles as descriptive.
One agent configuration, one voice provider, one model, one day, one region. Different transcribers or endpointing settings would move these numbers.
Our caller is text-to-speech. Real speech has pauses inside sentences that endpointing must handle; ours does not.
Both platforms were on free/pay-as-you-go tiers with default settings. We did not tune either.