Reading a provider’s list price correctly: the conditions nobody quotes
A single number on a pricing page is usually several numbers wearing a coat.
A model’s list price looks like one number per direction: so much for input, so much for output. It rarely is. Behind the headline sit context thresholds, cached-input rates, batch discounts, and peak and off-peak windows — and a comparison that ignores them is comparing two different things while presenting one figure.
This guide covers the conditions that actually change what you pay, using the providers’ own published pages as the reference.
Conditions that change the headline
| Condition | What triggers it | Effect |
|---|---|---|
| Context threshold | Prompt length crossing a limit | A higher rate, often for the whole request |
| Cached input | Repeated prefix within a window | Input priced far below the standard rate |
| Batch / async | Submitting work with a delayed deadline | Roughly half price, typically |
| Peak / off-peak | Time of day | Two published rates for one model |
| Reasoning tokens | Models that think before answering | Billed as output you never see |
The context threshold, and why it bites hardest
The clearest published example is xAI’s. Its documentation prices grok-4.6 at 2.00 input and 6.00 output per million tokens — and a prompt that reaches 200,000 tokens is billed at 4.00 and 12.00 for the entire request, not just for the tokens above the threshold.
That last detail is the one that matters. It is not a marginal rate. Crossing the line reprices everything, so a request at 199,000 tokens and one at 201,000 differ in cost by more than the two thousand tokens between them — they differ by a factor of two.
Check this per model, on the provider’s own page. Thresholds vary and they move.
Cached input: the biggest legitimate discount
Every major provider now prices cached input separately, and the gap is large — often an order of magnitude below the standard input rate. If you send the same system prompt or the same document repeatedly, this is likely the single largest lever on your bill, and it is one a naive per-token comparison cannot see.
It also has a shape worth knowing: caches expire on a timer, and writing to the cache sometimes costs more than a normal input token. A workload that reuses a prefix every few seconds benefits enormously; one that reuses it every few hours may pay a premium for the privilege. The providers document the windows and the write rates on their pricing pages — Anthropic and OpenAI both publish theirs.
Reasoning tokens: output you pay for and never read
Models that reason before answering generate tokens during that step, and those tokens are billed as output. They do not appear in the text you receive. A model advertised at a modest output rate can therefore cost several times what a naive estimate suggests on a task that makes it think hard.
The practical consequence: for reasoning models, per-token list price is a weak predictor of cost per task. Two models with identical published rates can differ by a wide margin on the same workload because one of them thinks more. If you are choosing between them, measure cost per completed task on your own prompts rather than comparing rate cards.
Peak and off-peak
Some providers publish two rates for the same model depending on the time of day. DeepSeek is the clearest case, with an off-peak input price roughly half the peak one.
This creates an obvious ambiguity in any comparison: which of the two is "the" list price? Quoting the off-peak rate flatters the provider and shrinks a relay’s apparent discount; quoting peak does the opposite. There is no neutral choice, only a disclosed one — and a comparison that shows a single figure without saying which window it came from has made the choice for you without telling you.
This is not hypothetical for us. When we audited our own list-price column, the DeepSeek row was carrying a figure below the provider’s own cheapest published rate, which understated our discount. The fix was to read the provider’s page and record which window the number came from.
Batch and asynchronous tiers
Work submitted with a relaxed deadline is typically priced around half. If your workload is genuinely asynchronous — evaluations, bulk classification, overnight enrichment — this is a real and legitimate discount that no relay comparison will show you, because relays generally resell the synchronous tier.
Worth stating plainly, since it cuts against our own interest: for a large batch workload, the provider’s own batch tier may well beat a relay’s synchronous resale price. That is a genuine case where going direct is cheaper, and a comparison that never mentions it is not being straight with you.
A checklist
- Find the provider’s own pricing page. Not an aggregator, not a cached copy.
- Note the exact model variant. Mini, flash and turbo siblings have their own rates, and confusing them is the most common error in published comparisons.
- Check the units — per thousand or per million — before any arithmetic. The thousand-fold trap.
- Read the conditions: context thresholds, cached input, batch, peak windows.
- Record the date you read it. A price with no date is a rumour.
Step five is the one people skip and the one that ages the rest. Our own verified reference entries carry a read date and expire sixty days later; the ten currently in use were read on 2026-08-27 and stop being displayed on 2026-10-26 unless someone re-reads them.
A worked example: the same workload, four ways
Take one concrete job — a document-processing task that sends a 30,000-token reference document plus a short question, and receives about 500 tokens back, ten thousand times a month. At a headline 3.00 input and 15.00 output per million, the arithmetic looks simple.
| Scenario | Input cost | Output cost | Total |
|---|---|---|---|
| Headline rates, no caching | $900.00 | $75.00 | $975.00 |
| Reference document cached | $90.00 | $75.00 | $165.00 |
| Batch tier, no caching | $450.00 | $37.50 | $487.50 |
| Cached and batched | $45.00 | $37.50 | $82.50 |
Same model, same work, and a spread of nearly twelve times between the first row and the last. Every one of those rows is the provider’s own published pricing correctly applied. None of them is the number a per-token comparison table would show you.
The lesson is not that comparisons are useless — it is that a per-token rate is the *starting* point for a cost estimate rather than the answer. If your workload has a large repeated prefix, caching dominates everything else, and any decision made on headline rates alone was made on the wrong number.
What this means for relay comparisons
Relays generally resell the standard synchronous tier. That has two honest consequences worth stating even though they cut against our own case:
- Batch workloads may be cheaper direct. If your work tolerates a delayed deadline, the provider’s own batch tier can beat a relay’s resale of the synchronous one.
- Caching support varies. If a relay does not pass prefix caching through, a workload that would have benefited from it loses that discount entirely — and the loss can exceed the relay’s headline saving.
Both are worth asking about directly before committing a workload. "Do you pass through prompt caching?" is a question with a one-word answer, and an operator who cannot give one has told you something.
Conditions are one of three ways a comparison goes wrong; the others are mixed units and a reference price nobody checked. The wider guide to relays puts all three in context.
Figures in this guide were read on the dates shown beside them. Prices change; where a claim depends on a provider’s published price, the link goes to that provider’s own page so you can check it rather than take ours. This guide is reviewed by 2026-10-26.
Check the numbers yourself
Every model on this station, its per-token price and the provider’s published list price are on the pricing page, with no account required to read them.