Methodology — how AI API latency is measured

Updated September 07, 2026

Latency here is measured directly from probes in four regions — not scraped from pricing pages and not routed through an aggregator gateway. This page documents exactly how, so the numbers can be audited and cited with confidence.

What exactly is measured?

Two independent metrics per provider:

• Edge latency (time-to-first-byte, TTFB) — a probe connects to the provider's official API host and measures DNS resolution, TCP handshake, TLS handshake and time to the first response byte. This isolates network and edge performance from model compute.
• Inference latency (time-to-first-token, TTFT) — the time from request to the first streamed token of a real streamed completion. This needs an API key per provider, so it is measured only where we hold one and appears as a separate table on those region pages. Coverage is deliberately partial: every headline ranking on this site is edge latency (TTFB), never a mix. We publish nothing rather than estimate a provider we cannot actually call.
  The same request doubles as an error probe. A 5xx, a 529 or a timeout on that one-token request counts as a failed request and enters the incident log as “requests to <model>”, kept apart from host probes — a host can answer normally while a model returns errors, and on 3 September 2026 Anthropic did exactly that. Errors that are ours (a rejected key, an exhausted quota, a retired model name) are excluded rather than counted as the provider’s downtime.
  TTFT is not comparable across providers. Each one is measured on whichever model that account can call, and model size drives TTFT far more than the network does — a 30B model will beat a 120B model on the same hardware. The model is printed next to every TTFT figure so the number can be read honestly; treat it as a per-provider baseline over time, not a leaderboard.

Where is it measured from?

Independent probe nodes in four regions, so latency reflects real geographic distance to each provider's infrastructure: Europe (Germany), US (Central), Asia (Tokyo) and South America (São Paulo). Rankings routinely differ by region — the fastest API from Europe is often not the fastest from Asia. That per-region difference is the reason this site exists.

How much data is behind these numbers?

Every figure on this site comes from the table below — the same database the rankings are built from, so the two cannot drift apart. As of September 07, 2026 it holds 2,419,748 individual measurements of 45 providers across 4 regions, collected continuously since 2026-07-23 (46.2 days). The last 24 hours alone account for 52,461 probes.

Probes per provider is the honest check on the rest of this page: at one probe every five minutes a region should record roughly 288 per provider per day, and a region that falls short is one whose figures carry less weight that day. Inference (TTFT) is measured for 4 of 45 providers — only those we hold an API key for. Raw measurements are retained for 90 days.

How often is it measured?

Each provider is probed on a repeating schedule (every few minutes). Pages rebuild automatically and show a visible “Updated” / “Last verified” date. Reported figures are percentiles over the last 24 hours.

Why percentiles instead of averages?

We publish p50 (median — a typical request) and p95 (95th percentile — the slow tail users actually feel), plus uptime (share of probes returning a successful response). Percentiles are nearest-rank; averages are avoided because a few outliers distort them.

How is the Speed Index calculated?

The Speed Index is a composite 0–100 score for comparing providers across regions at a glance. In each region a provider scores fastest_p50 / provider_p50 × 100 — so the region’s fastest API scores 100 and one twice as slow scores 50 — and the score is averaged over the regions where the provider is measured. The homepage lists only providers measured in all regions, so the comparison is like-for-like. It is derived entirely from the measured p50 figures above: reproducible, not a subjective rating.

What does this data not tell you?

• It is an independent, provider-neutral, reproducible signal of how quickly each API responds by region, over time.
• It is not a benchmark of model quality, throughput (tokens/sec) or price. Measured latency depends on network path and endpoint behaviour and can change without notice.
• Every number is measured by this system; nothing is estimated or copied from a provider’s marketing.

How can I use or cite this data?

All rankings are free to reuse under CC BY 4.0, including commercially, provided the source is attributed. Machine-readable: JSON API, per-page markdown (append .md or send Accept: text/markdown), full corpus, and an MCP endpoint for agents.

There is also an embeddable badge if you want to display a measured latency figure on your own site or README — it regenerates itself from live data.

Because every figure moves, a citation is only meaningful with the timestamp it was taken at. Please cite it as:

Source: llmlatency.dev — measured AI API latency by region, as of <UTC timestamp>.

The generated field in the JSON API carries that timestamp. If you are quoting a single number, quote the region with it: a latency figure without an origin is not a fact about a provider, it is a fact about a provider and a location.

Corrections & disputes

If a figure on this site looks wrong to you — especially if you work for a provider listed here — write to contact@llmlatency.dev. A ranking nobody can challenge is not independent, it is just unverified.

To make a report actionable, include the provider, the region, the UTC timestamp you are disputing, and what you measured instead. Every published number is backed by stored raw probes, so a claim can be checked against the original samples rather than argued about.

• What happens next: the raw samples behind the disputed window are re-read. If the figure is wrong, it is corrected and the correction is recorded on the changelog — silent edits defeat the point.
• What will not happen: no number is removed, delisted or softened because a provider dislikes it. A measurement that survives a challenge stays exactly as measured.
• Endpoint changed? If the API host being probed is no longer the right one, say so — a stale endpoint is a measurement bug on our side, and it is the most useful report we get.
• The same address takes requests for an extra region or provider, and bulk history beyond the published window.

Partner links, and how they are kept apart from the data

A few pages carry a block labelled Partner link. If you sign up with that vendor through it, this site earns a commission. Three rules keep that from touching the measurements:

• Partner links live in their own marked block, never inside a ranking, table or comparison, and carry rel="sponsored" so search engines and answer engines can tell them apart from citations.
• No provider measured here can buy a position, a badge or a softer number. Commissions have no input into any figure on this site. Where a measured provider runs an affiliate programme we have joined (Novita AI), the link appears on that provider’s own page only, never in a ranking or comparison, and its figures come from the same probes and the same code as everyone else’s.
• The list is short and public: Novita AI, UptimeRobot. If it changes, this section changes with it.