Unbiased

Blog

Gateway latency, measured: what the extra hop really costs

The standing objection to any router is the hop. We measured it instead of arguing about it: +68ms at the median, and the tail actually favored the gateway.

By the Unbiased Team · published · fees and prices verified July 28, 2026; measured data dated in place

+68ms
median time-to-first-token added by the routing hop: 0.656s vs 0.588s direct
104ms
how much better the gateway's p95 was than direct's: 0.821s vs 0.925s
20 + 20
streamed runs, same prompt, same hour. Small n, honest method, reproducible

We measured the gateway hop at +68ms median time-to-first-token (0.656s through a full routing gateway vs 0.588s direct), with the gateway's p95 beating direct by 104ms (0.821s vs 0.925s) across 20 streamed runs each way. Provider-side variance is larger than the hop; median latency is not a reason to avoid routers.

The method

Twenty streamed requests direct to a provider and twenty through a full routing gateway, identical prompt, same hour, measuring time-to-first-token. Small sample, deliberately simple, and reproducible in an afternoon; the runnable script is linked from the gateway comparison so you can check us against your own network and region.

We measured a full routing gateway rather than a pass-through proxy because that is the worst reasonable case: if routing logic runs on your request, you are paying for the whole detour.

The result, both halves

Median: the hop is real, 68 milliseconds, 0.656s against 0.588s. That is the honest cost of the convenience and for most interactive traffic it is imperceptible. Tail: the gateway's p95 came in 104ms better than direct, 0.821s against 0.925s, because provider-side variance, the thing you already live with, is bigger than the hop.

Read that second half carefully before architecting around latency: eliminating the gateway does not eliminate your tail. The provider is your tail.

The gateway hop, measured: 20 streamed runs each way

Time-to-first-token, same prompt, same hour: direct provider call vs a full routing gateway. Method and runnable script in the gateway comparison. Measured 2026-07-28.

Where latency actually becomes real

Per-request routing reasoning on hard tasks, not the network hop, is the latency question worth asking any routing layer. We document ours: Pareto can run up to 3x slower on the hardest reasoning tasks while measuring +0 on agentic work, stated on the model card rather than discovered in production. Demand the same disclosure from anything that thinks before it routes.

For simple catalog routing, the honest summary is: the hop is 68ms, your provider's p95 dwarfs it, and anyone using latency to sell you off a router owes you their measurement.

Questions, answered

How much latency does OpenRouter add?

Our measurement of a full routing gateway found +68ms at the median time-to-first-token. OpenRouter specifically may differ; the method is published and takes an afternoon to run against any layer.

Is a gateway slower at p95?

Not in our runs: the gateway's p95 beat direct by 104ms (0.821s vs 0.925s). Provider-side tail variance exceeded the hop cost.

Does time-to-first-token matter more than total time?

For streamed interactive use, usually yes: perceived speed is dominated by when text starts. Batch and agentic workloads should weigh total completion time instead.

When is routing latency a real problem?

When per-request routing reasoning runs on hard tasks. That can add multiples rather than milliseconds (we disclose up to 3x on hardest reasoning for our own model), so ask any routing vendor for that number specifically.

Compare any two models

VS

Rates verified 2026-07-28. "Measured task" = our identical dashboard-generation prompt, metered where marked ✓ and list-math otherwise. Verbosity from the Verbosity Index, Edition 1. Data: prices.json.

Run the comparison on your own traffic. $100 to verify.
Buy Pareto API credits