# 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                         < 800ms
```

Those 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](https://voice.sphoro.com/docs/providers). | 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](https://voice.sphoro.com/docs/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](https://voice.sphoro.com/docs/behaviours). |
| 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.

`GET /v1/calls/{id}`

**Shell**

```bash
curl -s https://voice.sphoro.com/v1/calls/$CALL_ID \
  -H "Authorization: Bearer $SPHORO_API_KEY"
```

For a distribution rather than one call, [analytics](https://voice.sphoro.com/docs/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".