—all-standard cost
—saved / mo
—blended $/1M
Where the money goes — per tier
Your traffic split across the three tiers. Whatever is not deferrable or critical stays on standard. Batch/flex is charged at the discount; priority carries the premium.
| Tier | Share | Rate vs standard | Monthly cost |
|---|
How much can you batch? — the deferrable dial
The single biggest lever is the share of volume you can move off standard onto the discounted tier. Each row holds your priority share fixed and varies the deferrable share; the saving is versus running everything on standard.
| Deferrable share | Blended cost | Saved / mo | Saving |
|---|
The cheapest token is the one you were willing to wait for
Most teams treat model price as a single number, but the same tokens now come in tiers, and the gap between them is enormous: roughly half price for anything you can defer, a premium for anything you insist on serving instantly. The mistake in both directions is uniformity — running everything on standard leaves the batch discount on the table, and running everything on priority pays a latency tax on calls no user is waiting for. The win is almost always in the boring middle: tag your traffic by how much delay it can absorb, push the offline half onto batch or flex, keep ordinary interactive work on standard, and reserve priority for the narrow set of paths where a slow response actually costs money. The priority premium is the number people misjudge most, so this calculator isolates it — it prints the extra dollars per month you are paying purely for the service level on your critical share, separate from the tokens themselves, so the decision is a comparison and not a shrug. Size the offline discount precisely on the batch API savings calculator, stack it with cache hits on the prompt caching savings calculator, and fold every lever together on the LLM cost optimization calculator.
Batch API SavingsPrompt Caching SavingsLLM Cost OptimizationLLM Tier PricingLLM Latency
How this calculator works
It prices your full monthly volume at the standard input and output rates to get the all-standard baseline, then splits that cost by share across three tiers. The deferrable share is billed at the batch/flex discount, the latency-critical share at the standard rate plus the priority premium, and whatever remains stays at standard. Adding the three gives the blended monthly cost; the saving is the baseline minus the blended figure, and the effective blended $/1M divides the blended cost by total tokens. The sweep table re-runs the whole split across a range of deferrable shares so you can see the payoff of moving more work offline.
Frequently asked questions
What are LLM service tiers and why do they cost different amounts?
The same model can be billed at different processing tiers that trade latency against price. Standard is the synchronous list price. Batch and flex tiers run the same request asynchronously or at lower priority for roughly half the standard rate — they are meant for work that can wait minutes or hours, like bulk classification, embeddings, offline summarisation or nightly report generation. Priority processing goes the other way: you pay a premium above standard to get faster, more consistent latency and better reliability during load spikes, which matters for interactive, user-facing calls. The tokens are identical; you are paying for how quickly and how reliably they are served.
How much can batch or flex processing actually save?
The discount is typically around 50% off the standard rate, so every slice of traffic you can move to a batch or flex tier costs about half. The catch is latency: batch jobs can take up to a day to return and flex requests can be slower or occasionally queued, so only genuinely deferrable work qualifies. The lever is the share of your volume that can tolerate the wait — a pipeline that is 80% offline batch and 20% interactive lands near a 40% overall saving, while an all-interactive product saves nothing this way.
Is priority processing worth the premium?
Only for the traffic where latency has real value — a checkout flow, a live agent, anything a user is waiting on — and only for that slice, not your whole volume. Priority typically costs meaningfully more than standard per token, so putting all traffic on it is the most expensive way to run. The honest test is whether the faster, more reliable response is worth the extra dollars it adds, which this calculator prints as a standalone number: the priority premium in dollars per month for the critical share you selected.
How do I split traffic across tiers in practice?
Start by tagging each call path by how much delay it can tolerate. Anything a user is not actively waiting for — overnight jobs, backfills, evaluations, bulk enrichment — goes to batch or flex at the discounted rate. Anything a user is waiting on but that is not latency-critical stays on standard. Reserve priority for the narrow set of interactive paths where a slow or dropped response costs you money. Then set those three shares here to see the blended rate and the saving versus running everything on standard.