llm-status

Cross-gateway LLM model status and latency, assembled from telemetry the providers already publish.

🚧 Planning. There is no implementation yet — this repository currently holds the problem statement and the open design questions. Watch the issues if you want to follow along or weigh in.

The idea

When a model feels slow, the question is rarely "is OpenAI down". It is "is this model slower than usual, on this route, right now — and would another provider serving the same model be faster?" Answering that today means checking several places that do not talk to each other.

Three public sources, combined, already answer it:

Source	What it gives	Auth
Vercel AI Gateway	Per-endpoint status, uptime_last_15m/1h/1d, latency_last_1h (p50/p95), throughput_last_1h	None
OpenRouter	The same shape over shorter windows — uptime_last_5m/30m/1d, latency_last_30m, throughput_last_30m	None
Provider status pages	Incidents and component health — status.openai.com, status.claude.com (Statuspage-compatible JSON)	None

A live response from the Vercel gateway for anthropic/claude-opus-4.5 shows why the routing dimension matters — the same model, three provider endpoints, very different latency:

endpoint	uptime (1h)	latency p50	latency p95
anthropic	100%	814 ms	1674 ms
bedrock	100%	1425 ms	1975 ms
vertexAnthropic	100%	937 ms	1731 ms

How this differs from a benchmark site

This is not a benchmark. No synthetic prompts are run, no probe traffic is generated, and no tokens are spent. Every number is telemetry a gateway observed on its own production traffic, and it is reported as such — including the fact that two gateways will disagree about the same model, because they are measuring different network paths with different fleets. That disagreement is part of what the page is for.

Relationship to StatusBeam

StatusBeam is the status page engine from the same org, and it already covers the incident half of this problem: check: statuspage and check: incidentio read the provider status pages directly.

The split between the two projects follows the data:

• A curated set of models, graded up / degraded / down fits StatusBeam's existing CheckResult (one status and one latency per entry per tick). That is being added there as a check kind — see pleaseai/statusbeam#79.
• The full comparison view — every model, every provider endpoint, p50 and p95, across two gateways — does not. StatusBeam's checks table stores a single response_time per slug per tick with no dimension for provider endpoints, and its configuration is a hand-authored YAML file, not a home for the ~770 models the two gateways list between them. That is this repository.

Open questions

• Sweep cost. The endpoint metrics API is one call per model. A full sweep of both gateways is roughly 770 requests, well past a Cloudflare Worker's subrequest budget for a single invocation. Sharding across ticks, a curated allowlist, or both.
• Window mismatch. Vercel aggregates over 1 hour, OpenRouter over 30 minutes. The two are not directly comparable; the store has to keep the window alongside the value.
• Undocumented status codes. Vercel returns 0 for healthy endpoints. OpenRouter returned -2 for an endpoint that was simultaneously reporting 99.98% daily uptime. The meaning needs pinning down before it drives anything user-visible.

License

MIT