Which half-price tier is actually fastest right now?

The saving is not ours to claim or inflate - it is the providers' own published price, the same at all three: a job that costs $100 synchronously costs $50 on the cheap tiers. What you trade for it is a wait, and that is the number every comparison guesses at and none of them measure. The table below is our measurement of it, one row per model - and it is yours to read for free.

Flex and batch cost the same: OpenAI prices flex "at Batch API rates", and Google's flex is "half the Standard API" — which is exactly what its batch tier costs. When the price is identical the only questions left are the two we measure: how fast, and how often does flex refuse to run. One row per flex-capable model below, the flex tier beside the batch tier at the same price, over the last 30d (delayed 15 minutes).

Read the two latency columns differently as your prompt grows — that difference is the most useful thing on this page. A flex call is synchronous: a flex figure is the model's own work, prefill and decode, so it grows with the prompt. A batch figure is dominated by queue time — the wait to be scheduled — which is why the batch column is orders of magnitude larger at the very same prompt size. A longer prompt adds the same extra work to both, and that is the whole of the flex figure but a small fraction of the batch one. Both tiers are probed with the same fixed 8-input-token prompt and our size ladder is held out of both headlines, so neither is flattered by a different job. Take the batch column as the wait you can plan a real job against, and the flex column as the floor a larger prompt starts from — a 4,000-token flex call carries far more work than our probe does. No provider publishes a flex latency distribution at any prompt size, and we are measuring it at 3: 8, 2,000 and 16,000 input tokens, in the size ladder below. Each rung states its own count as it fills, so you can see exactly what stands behind the figure at the size you actually send.

A longer prompt is more work for both tiers — and it is the whole of the flex figure while it is a small fraction of the batch one. A flex call is synchronous, so what you are timing IS the model's own work. A batch figure is dominated by the wait to be scheduled, so the same extra work moves it far less. That is why one probe size describes a batch queue well and describes a flex call only at that size — and it is the reason to measure the curve rather than assume it. So we run flex at 3 sizes: 8, 2,000 and 16,000 input tokens, the same rungs our batch prober sends, so the two tiers can be compared at identical prompt sizes. Over the last 30d, delayed 15 minutes; every cell carries its own n.

The number to watch is how fast the columns grow, not how far apart they start. Flex's advantage at a small prompt is enormous and published above; whether it survives a 16,000-token one is the question this table answers, and nobody else is answering it. The 8-token column is the figure the table above publishes, shown here so you can see exactly what it is the floor of; the larger rungs are held out of that headline on purpose, so a published median is never a blend of prompt sizes. The refusal rate is measured at 8 tokens, where admission control makes its decision before it reads your prompt — so it is quoted on one size, on its own, and never blended with these. A rung we have not measured is reported as unmeasured, never estimated — and 128,000 tokens, the top of our batch ladder, is one of those today.

The flex tier's real risk is not latency — it is refusal. A flex request that is refused does not wait in a queue; it does not run at all (OpenAI returns a 429 resource_unavailable, Google a 503 at capacity). Nobody publishes how often that happens, and the providers do not charge for the refusal — so this is the one flex number that is both decision-critical and free to measure. Below is the refusal rate we observed, by UTC hour of day, over the last 30d. Public figures are delayed 15 minutes; each hour states its own n.

This number is exact at our probe size, and that is a property of the metric rather than a claim about our sample. A refusal is decided in admission control — before inference, before the model runs at all — so our 8-token probe measures it exactly as well as a 16,000-token one would. The prompt size that governs a synchronous latency does not enter here. It is also why we can keep the probe small rather than growing it for a latency ladder: refusals cost nothing to collect, so we can run enough of them to answer by the hour.