How much latency does a router add? We measured ours — from India
Every AI gateway says its overhead is negligible. OpenRouter markets "~25ms". Those numbers are usually gateway compute measured at the gateway's own edge — which is true, and also not what your users feel. What your users feel is the whole trip. So we measured the whole trip, from Bengaluru, on 2026-09-02, and we're publishing the commands.
1. The number nobody publishes: distance to the edge
Same probe (GET /v1/models, median of 3, one machine in Bengaluru):
| API | Round trip | vs BharatRouter |
|---|---|---|
| api.bharatrouter.com | ~200 ms | — |
| openrouter.ai | ~355 ms | 1.8× slower |
| api.groq.com | ~355 ms | 1.8× slower |
| api.anthropic.com | ~385 ms | 1.9× slower |
| api.together.xyz | ~428 ms | 2.1× slower |
| api.openai.com | ~430 ms | 2.2× slower |
From India, reaching a US-edge router costs ~355ms before its "~25ms" even starts. BharatRouter terminates in-country (we moved our edge onto an India PoP in September — the TLS handshake alone dropped from ~165ms to ~70ms). A router's overhead claim is true from where its edge lives. Theirs is true from Virginia; ours is true from Bengaluru.
2. End-to-end overhead, same model, same provider
The honest test: one model (gpt-oss-20b), one upstream (Groq), one prompt, 5 runs each — raw versus routed, with the route pinned so both paths hit the identical backend. The response header x-br-provider: groq confirms it.
| Path | Median | Range |
|---|---|---|
| Raw Groq, direct | ~189 ms | 172–360 ms |
| Through BharatRouter (BYOK → Groq) | ~381 ms | 317–474 ms |
| Added, end-to-end | ~190 ms |
Where does it go? A bare /health — zero gateway work — costs ~110–130ms from the same machine, so most of the 190ms is the network path (you → edge → origin, both directions, plus our data-center's own hop to Groq). The gateway's compute — auth, routing, budgets, rate limits, audit, INR metering — is roughly50–70ms of it. Comparable to any router's compute; every request also returns x-br-latency-ms (the upstream's own time), so you can compute our overhead on your traffic, not our blog's.
3. What about OpenRouter's number?
We tried to run the identical three-way through OpenRouter (same model, provider pinned to Groq). We could not complete it — so the fair statement is: their edge costs an Indian user ~355ms of distance (measured), their compute is ~25–40ms (their claim, and we have no reason to doubt it at their edge). We'll publish the completed three-way when we have it; the commands below work for any router.
4. Reproduce it
Timing breakdown for any endpoint:
{timingCurl}The overhead pair (bring your own keys — the point is that you don't have to trust us):
{threeWayCurl}The takeaway
Routing costs something — for us, ~190ms end-to-end from India, of which ~50–70ms is the gateway earning its keep (failover, budgets, residency enforcement, INR billing). But for an Indian user the alternative isn't "zero overhead": it's carrying every request to an edge on the other side of the planet first. Measured door to door, one API in India is the faster way to reach most of the world's models.
Method: medians over repeated runs from one Bengaluru vantage on 2026-09-02–03, warm DNS; completion tests used identical prompts and max_tokens. Numbers vary with ISP and time of day — run the commands. Overhead decomposition uses ourx-br-latency-ms response header (upstream time as the gateway saw it).