Accuracy — how often our own number held
How often our own number held — measured out of sample
| Model | p50 held | p90 held |
|---|---|---|
| Anthropic · claude-haiku-4-5 | 74.9% | 100% |
| Google · gemini-3.7-flash | 61% | 94% |
| OpenAI · gpt-5.6-luna | 51.8% | 82.6% |
| OpenAI · gpt-5-nano | 43.8% | 77.9% |
| OpenAI · gpt-5.6-sol | building (n=43) | |
The tail fan — the median is not your risk
5 of 5 measured series have a publishable median, p90 and p95 — the 8-job line, and a full set of percentiles to fan between. A series below it reports its count and no percentile: a handful of measurements cannot render as a distribution.
gemini-3.7-flash has the steadiest queue on the board — its p95 sits inside 1.4× of its median, which runs 2 min. Across all 5 series the medians span 58s to 2 min (2×) — while the p90s behind those same medians run 3 min to 30 min, a 10× spread. gpt-5-nano fans furthest, 90.1×. The spread is the decision, and the median cannot see it.
Rows are ordered by tail width, because ordering by median is the comparison this figure exists to correct. The bar runs from the typical wait to the p90 that covers nine jobs in ten; the tick is the p95.
Source: /v1/coverage
When to submit — the hour is a lever you control
gpt-5-nano · 24 of 24 hours carry enough measurements to draw, from 3,847 completed jobs in the last 30 days. An hour needs 2 to get a bar; below that it keeps its place on the axis and carries its count on hover, because a bucket that thin is a count rather than a distribution.
On gpt-5-nano the hour you submit is a lever you control before the job leaves. A job sent at 06:00 UTC carries a p90 of 13 min; the same job at 19:00 UTC carries 4 hours — 16.2× wider. Moving a deadline job 11 hours is worth that much, and no key, model change or code change buys it.
Each bar runs from that hour's median to its p90, on a log axis. The hour is the SUBMISSION hour in UTC — the one you choose — and a provider queue follows the world's day, not yours.
Not the eye's pattern. The hour shape survives a negative control: of 200 random relabellings of the same durations, only 0.5% reproduce this much hour-to-hour separation, so the clock is a measurement rather than the spread a heavy tail always shows.
Which day — does the week have a shape
gpt-5-nano · 7 of 7 days carry enough measurements to draw, from 3,847 completed jobs in the last 30 days. A day needs 2 to get a bar.
On gpt-5-nano the weekend is the cheaper slot: a job sent Saturday or Sunday carries a median of 52s against 78s on a weekday — 1.5× faster off the working week, and the day you submit is a lever you set before the job leaves.
Each bar is that weekday's median, on a log axis. The weekday is the SUBMISSION day in UTC — the one you choose — and a provider queue follows the world's week, not yours.
Not the eye's pattern. The weekday shape survives a negative control: of 200 random relabellings of the same durations, only 0.5% reproduce this much weekday-to-weekday separation, so the clock is a measurement rather than the spread a heavy tail always shows.
Same price, flex against batch — what the tier buys you in seconds
2 of 4 flex-capable models have a publishable median on both tiers. Each row is that tier's own measurements — the service tier is part of the rollup key, so flex and batch are never pooled and the distance between them is real.
Flex and batch cost the same, which leaves exactly two questions — how fast, and how often flex refuses — and both are measured. On gpt-5-nano the flex tier answers in 2s against 74s on batch, a 37× difference at an identical token price. Flex served that model at a measured 0.1% refusal rate over 6,126 definitive answers, so you can price the risk as well as the wait.
One row per tier, grouped by model, on a shared log axis: the dot is the median, the bar runs out to the p90. Both figures come from the same measurement pipeline every other page reads.
Price × time × tail — the decision, in one figure
Price × time × tail — is the discount worth it for your model?
Cheapest, fastest and tightest are three different models — so this is a real decision, not a ranking. Left is faster (typical wait, log scale), lower is cheaper (blended batch $/1M at a 3:1 input:output mix), and a bigger bubble is a looser tail. The price is the one sourced batch price the rest of the site quotes, so a bubble can never disagree with /pricing.
Source: /v1/coverage · /v1/models
Speed — median queue time by model
Median queue time by model
Minutes, not hours — and a large spread between models at the same provider. Fastest median at the top; each bar carries the n behind it and is coloured by how much we trust it. Batch endpoints bill at half the synchronous rate, so this wait is what you pay in time for that discount.
Source: /v1/coverage
The distribution, the clock and your deadline — per model
Distribution, the clock, the deadline, weekday and size — per model
An average hides the tail, and the tail is the risk. Pick a model to see the whole distribution behind its median, when in the day its queue is actually fastest, your own odds against a deadline you set, its weekday pattern, and — the question the forums have had open since 2024 — whether bigger batches wait longer. Each chart shows how fresh its numbers are.
Distribution — share finished vs. elapsed time
The clock — when is the queue fastest? (UTC)
The deadline explorer — will your job make it?
Weekday pattern
Size effect — do bigger batches wait longer?
Reliability — incident timeline and detectability
Incident timeline — and what we can even see
Severe and degraded windows we have measured, newest last. A provider's own status page rarely admits a batch slowdown; ours is drawn from what we actually watched happen. Below the timeline is the part almost nobody publishes: which models we can currently detect an incident for, and which we cannot — because saying what we cannot see is what makes the rest credible.
Detectability — what we can and cannot see right now
Source: /v1/outages
Edge latency by region
Edge latency by region — small multiples
We answer from Cloudflare's edge, so reading the data costs you almost nothing wherever you are. Time-to-first-byte from a real API call, one sparkline per region on a shared scale. We publish our own latency for the same reason we publish everyone else's — evidence, not assurance.
Source: /v1/latency
Coverage and provenance
Coverage and provenance
Right now every one of these 13,830 measurements is our own probe — 0 come from outside contributors. We publish the split because provenance is part of the measurement: you can see exactly where each number came from, which is more than any competitor shows. Add yours and become the second — the client reports what your own call did; it never routes the job through us.
| Model | Measurements (n) | Outside contributors |
|---|---|---|
| gpt-5-nano OpenAI | 3,849 | 0 |
| gpt-5.6-luna OpenAI | 3,261 | 0 |
| claude-haiku-4-5 Anthropic | 2,611 | 0 |
| gemini-3.7-flash Google | 2,347 | 0 |
| gpt-5.6-sol OpenAI | 1,762 | 0 |
Source: /v1/coverage
How these figures are produced
How these figures are produced
Everything above is drawn from measurements, and every one of them is one click from the endpoint that produced it. This is the whole method, stated once.
- What is measured
- Wall-clock time from the moment a job is submitted to the moment the provider reports it complete, taken from the server's clock at both ends. Every figure on this page is an observed completion of a real job — never a simulation, never a provider's own estimate.
- Where it comes from
- Our own probe fleet, running real jobs against the real queue, plus every measurement contributed through the API. 13,830 completed jobs across 5 measured batch series are behind the model figures above — the flex tier is counted separately, on its own rows — and the per-model split is published at /v1/coverage: provenance is part of the measurement, so you can see exactly where each number came from.
- Selection period
- A rolling 30-day window, recomputed continuously. A series is drawn once it has 8 completed jobs, so a small base can never produce a confident-looking percentile; below that line the series still reports its real count, because a count is a fact and a percentile drawn from four jobs is not. The hour-of-day figure splits one series across 24 buckets and states its own, smaller, per-bucket minimum on the figure.
- Freshness
- The newest measurement these figures are computed from landed 24 min ago, at 2026-10-15T02:46:18Z. That stamp is the data's age — not when this page was rendered and not when it was deployed.
- Prompt size
- Prompt size is measured as its own dimension rather than assumed away: probes run at a base size and a deliberate ladder sends larger ones, and the queue time per size band is published per model at /v1/patterns. So a reader can check what size does to the queue for their model instead of taking anyone's word for it.
- What these figures do not establish
- A batch figure is the queue wait AND the generation, together: a single completed row carries one start and one end, so the two cannot be separated from it, and we publish the number we can actually measure rather than a split we would have to model. These are observed completions over the window, which is what makes them checkable — they describe how the queue has behaved, and the 5 batch series drawn above are the ones where that record is long enough to speak for itself.
Source: /v1/coverage