Methodology — how AI API latency is measured

Updated October 23, 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 October 23, 2026 it holds 4,806,346 individual measurements of 46 providers across 4 regions, collected continuously since 2026-07-24 (90.9 days). The last 24 hours alone account for 53,907 probes.

At one probe every five minutes, a region should record roughly 288 probes per provider per day. Lower counts indicate reduced coverage for that day. Historical inference coverage in the retained database includes 7 of 46 providers, not necessarily active today. For successful TTFT measurements in the last 24 hours, see current TTFT coverage and named models. 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. Include the measurement region when citing a latency figure.

Corrections & disputes

Report a suspected error to contact@llmlatency.dev.

Include the provider, the region, the UTC timestamp and your own measurements. We check reports against the stored raw probes.

• 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.
• 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.