llm-latency-tracker
# 📊 LLM Latency Tracker
**Measure AI API latency and uptime across regions, and publish the results as open data.**
🌐 **[Live rankings](https://llmlatency.dev)** · **[JSON API](https://llmlatency.dev/api/rankings.json)** · **[MCP endpoint](https://llmlatency.dev/mcp)**
## ⚡ What it does
- 🌍 **Regional measurements** — compare provider response times and availability from distributed probe nodes.
- ⏱️ **Two probe types** — network time to first byte (TTFB) and optional inference time to first token (TTFT).
- 📈 **Open dataset** — daily rankings, historical snapshots and regional p50 / p95 statistics.
- 🤖 **Agent access** — JSON API, MCP, Markdown pages and an `llms.txt` index.
- 🗓️ **Model lifecycle** — a deprecation calendar with links to provider announcements.
## 🔧 Built for measurement
- **Python standard-library core** for edge probes; provider keys are needed for inference probes.
- **SQLite storage** and regional aggregation, with remote nodes shipping measurements to a central node.
- **Static publishing** for the website and JSON datasets.
- **CI checks** for tests and linting; published snapshots include their measurement date.
**Reading the results:** edge TTFB measures network/API responsiveness, not model generation speed. Compare it separately from inference TTFT; results depend on region, probe type and time window.
## 🚀 Quick start
Use the public data without installing anything:
```bash
curl https://llmlatency.dev/api/rankings.json
```
Or run edge probes locally with **Python 3.12+**:
```bash
git clone https://github.com/mazamaka/llm-latency-tracker.git
cd llm-latency-tracker
REGION=local python3 run.py
python3 aggregate.py --region local
```
For a local stdio MCP server over the published API (stdlib only, no keys):
```bash
python3 mcp_server.py
```
Tools: `get_ai_api_latency` (provider leaderboard per region), `get_provider_latency` (one provider across regions), `get_model_deprecations` (model shutdown calendar), `get_coding_agent_health` (Claude Code / Codex speed and accuracy drift). All read-only.
**[Inference probes, API access & site generation →](docs/USAGE.md)** · **[Deployment →](deploy/)**
## 🧪 Contributing
Add a provider, bring a new probe region, or improve the measurement code. See **[CONTRIBUTING.md](CONTRIBUTING.md)** for setup and checks.
---
**Python · SQLite · JSON API · MCP · Cloudflare Pages**
**[Code: MIT](LICENSE)** · **Data: CC-BY-4.0**, with attribution to [llmlatency.dev](https://llmlatency.dev).
<details>
<summary><b>📈 Latest daily snapshot</b></summary>
<!-- DATASET:BEGIN -->
### Daily snapshot — 2026-10-31
Measured latency across **46 AI inference providers** in 4 regions. Method: distributed edge (DNS→TCP→TLS→TTFB) + inference (TTFT) probes, last 24h. License: CC-BY-4.0.
| Region | Fastest provider (p50) | p50 | p95 | Uptime |
|---|---|---|---|---|
| Asia (Tokyo) | fireworks | 22 ms | 73 ms | 100% |
| Europe (Germany) | fireworks | 19 ms | 57 ms | 100% |
| South America (São Paulo) | openrouter | 61 ms | 90 ms | 100% |
| US (Central) | fireworks | 28 ms | 74 ms | 100% |
- Full dataset: [`data/rankings/2026-10-31.json`](data/rankings/2026-10-31.json) ([latest](data/rankings/latest.json))
- Citable archive (DOI): [`10.5281/zenodo.23388429`](https://doi.org/10.5281/zenodo.23388429) — daily aggregates, CC-BY-4.0
- Hugging Face dataset: <https://huggingface.co/datasets/llmlatency/llm-latency-tracker>
- Kaggle dataset: <https://www.kaggle.com/datasets/llmlatency/llm-latency-tracker>
- Archived in Software Heritage: [`swh:1:snp:2778cbabd72a70a629ee35fbd5ac536d1ccb7a9a`](https://archive.softwareheritage.org/swh:1:snp:2778cbabd72a70a629ee35fbd5ac536d1ccb7a9a)
- Python client: <https://pypi.org/project/llmlatency/>
- Live rankings and methodology: <https://llmlatency.dev>
- Machine-readable API: <https://llmlatency.dev/api/rankings.json>
- Model deprecation calendar: <https://llmlatency.dev/deprecations>
_Snapshot generated 2026-10-31T07:46:21Z — this table is regenerated daily._
<!-- DATASET:END -->
</details>
TDQS
Scored across 4 tools
The two latency tools have overlapping subject matter, but each description explicitly points to the other with a clear boundary rule (leaderboard vs. single-provider across regions). The deprecations and coding-agent-health tools are in entirely different domains, and each description reiterates its scope ('calendar data, not latency', 'for raw API latency use...'). An agent can pick correctly without guessing.
All four tools use the same get_<subject> snake_case pattern with no deviation in verb or casing. The names are predictable and readability is high. Minor quibble: get_ai_api_latency actually returns a ranked leaderboard rather than a single latency value, but the convention itself is uniform.
Four tools is compact and none feel redundant, which fits a narrowly scoped observability server. It is on the lean side given it spans three distinct areas (API latency, model deprecations, coding-agent health), leaving little room for supporting lookups.
The surface covers the core questions: regional ranking, per-provider detail, deprecation planning, and agent regression checks. Gaps are minor and workaroundable (no provider-list endpoint, though errors enumerate valid ids; no historical time series beyond the fixed 24h window).