Latency
People notice conversational delay above roughly 800ms — not as slowness, but as the other party being confused or absent. Everything in the call path is organised around staying under that number, and this page is where the time goes and which settings move it.
The budget
From the moment the caller stops speaking to the moment the agent starts:
Caller stops speaking ─────────────────▶ Agent starts speaking
endpointing / turn detection ~100–200ms
final transcript ~100–150ms
retrieval (only if grounded) ≤250ms, bounded, fails open
model first token ~200–400ms
first audio from the voice ~100–150ms
network and jitter ~50–100ms
───────────────────────────────────────────
TARGET < 800msThose numbers add up to more than 800ms, and that is the point: the budget is met because the stages overlap, not because each is fast. The voice begins synthesising the first sentence while the model is still writing the second. Run them strictly one after another and the identical pipeline lands near two seconds.
The other budget nobody measures
The one above is within a conversation. There is a second one — from the moment the callee picks up to the moment they hear a word — and it is a completely different set of stages: carrier handoff, media stream establishment, and the greeting. A call that answers promptly and then sits silent for two seconds fails for a reason none of the numbers above will show you.
Both are reported per call, so you can tell which one you are looking at:
| What it measures | Where it shows up |
|---|---|
| Pickup to first word | connect_ms on the call record |
| The carrier's own share of that silence | carrier_handoff_ms |
| Caller stops to agent starts, per turn | latency_ms on transcript
events |
What actually moves the number
In rough order of how much difference each makes, which is not the order people usually try them in.
| Change | Typical effect |
|---|---|
| Use a model built for latency. A reasoning model cannot answer a telephone: tens of seconds to first token is normal for one, and no amount of tuning elsewhere survives it. | Seconds. This is almost always the whole problem. |
| Shorten the prompt. Time to first token grows faster than linearly with prompt length — halving a long prompt can quarter the wait. | Hundreds of milliseconds. |
| Put the fastest vendor at the head of the chain. A chain falls through on failure, so the head is what almost every call uses. See vendors. | 100–300ms. |
Cap retrieval. retrieval_timeout_ms bounds the grounding
step, and it fails open — a slow knowledge base degrades the answer rather than the
call. | Up to the cap, on grounded agents. |
| Pre-render the fixed lines. A greeting or a menu synthesised on every call is paid for on every call. See voice lines. | The whole synthesis cost of those lines. |
Cut tool round-trips. Every round is a full model call plus your API.
max_tool_rounds bounds it. | Your API's latency, times the rounds. |
| Set a filler phrase. Does not make anything faster; makes a long tool call sound like thinking rather than a dropped line. | Perceived, not measured. |
Things that look like latency and are not
| Symptom | Usually |
|---|---|
| Silence at the very start of every call | The connect path, not the model. Read
connect_ms and carrier_handoff_ms before touching anything
else. |
| The agent talks over the caller | Turn detection ending the turn early, or barge-in switched off. See conversation behaviour. |
| Long pause after a specific question | A tool call, not the model. Watch
call.tool.called. |
| The agent answers, but the audio is chopped | Not latency at all — a vendor refusing mid-session. The chain re-routes; the call record names the vendor it landed on. |
Measuring it yourself
Every finished call carries its own timings, so you can measure the deployment rather than trusting this page.
/v1/calls/{id}curl -s https://voice.sphoro.com/v1/calls/$CALL_ID \
-H "Authorization: Bearer $SPHORO_API_KEY"For a distribution rather than one call, analytics reports the same numbers over a window, sliced by agent — which is the shape you want when the question is "has it got slower" rather than "why was that call slow".