A price comparison table for LLM APIs has a short half-life. The useful output of reading one is not a list of numbers to memorize but a method: a set of pricing dimensions to watch and a small tracker to keep current. This page lays out those dimensions, explains why any snapshot goes stale, and points to the calculator that turns the question into a break-even number.
The pricing-dimension comparison table
Vendors differ less in their headline rate than in how many ways that rate can move. The table below lists the dimensions that separate two vendors’ real bills, with an estimate of how far each dimension can pull actual spend away from the sticker price. These are structural magnitudes, not live quotes; vendor pricing pages are authoritative and were last checked here on 2026-09-17.
| Dimension | What vendors do | How far it moves the real bill from the headline rate |
|---|---|---|
| Separate input / output pricing | Output is billed above input, often several times higher | Output-heavy workloads pay roughly 2–5× the input headline rate |
| Prompt / cache-hit discount | Tokens served from a cached prompt are billed at a fraction | Can cut input cost by roughly 50–90% on repeated system prompts |
| Batch / async discount | Offline or deferred endpoints are cheaper than realtime | Typically about 50% lower than the realtime rate |
| Context-tiered pricing | Longer context is billed at a higher rate | Adds roughly 10–100% depending on length |
| Minimum spend / reserved throughput | Committed-use plans unlock lower unit prices | Reserved plans move unit price by roughly 30–70% |
| Region and taxes | Price varies by region and tax is added on top | Adds 0–20%+ depending on region and tax rules |
| Egress / data-out traffic | Some vendors bill bytes leaving the platform | Adds roughly 0–10% for data-heavy applications |
The lesson is that the headline “$x per 1M tokens” is a starting point, not a bill. A workload with a cached system prompt, run through a batch endpoint, in a low-tax region, can land far below the sticker; the same workload billed realtime with long context in a high-tax region can land far above it. The token cost calculator folds the recurring side of this into a break-even against owned hardware.
Why not to copy any comparison table
Three forces make a copied table unreliable within weeks.
Price half-life. API prices for models move on the scale of weeks to months. A tier that looked cheap when a table was written can be undercut by a newer model or a promotional rate shortly after, and the older model may be deprecated entirely. Any number pasted from a comparison is a moment in time, not a fact about the market.
Model version churn. Vendors rename and replace models frequently. A price attached to “model X” may point at a model that no longer accepts traffic, or at a newer version with different quality and a different rate. Comparing on name alone hides the fact that the underlying product changed.
Hidden items. The dimensions in the table above are exactly the items a flat comparison omits: cache discounts, batch rates, context tiers, reserved throughput, region, and egress. A table that lists one input and one output price per model is missing most of what determines the bill.
The practical response is to maintain a tiny tracker rather than trust a snapshot. Four fields are enough:
- Model — the exact model identifier, including version, because names change.
- Date checked — the day the prices were read, so staleness is visible at a glance.
- Input price — per 1M tokens, recorded as a tier or range rather than a single point.
- Output price — per 1M tokens, same treatment, plus a notes column for which discounts, region, and context tier the prices assume.
With those four fields a reader can re-check one line at a time and see immediately which numbers are old. The ChatGPT cost per month page applies the same discipline to subscription tiers across regions.
When local is cheaper than API
The decision between owning hardware and buying API tokens is the same math the token cost calculator runs, but it can be stated qualitatively without any number:
- Local ownership tends to win when token volume is high and sustained, because the one-time hardware cost is spread over many tokens and the recurring cost is mostly cheap electricity.
- Local ownership tends to win when a single model is used heavily, since the workload does not benefit from hopping between vendor models.
- Local ownership tends to win when data must stay on-prem, because the API alternative would move that data off-site.
- API access tends to win at low or sporadic volume, because the electricity of a small box can already exceed the cheapest API tier, as the calculator’s critical-point table shows.
- API access tends to win when model capability differs, because a cheaper local model may not match the quality a frontier API returns — a separate question from cost.
The crossover sits in the tens-of-millions-of-tokens-per-month range for cheap hardware and moves earlier as hardware gets cheaper or electricity gets pricier. The local LLM hardware guide covers what hardware a workload actually needs, and the model file size lookup shows the memory footprint behind a local deployment.
Building cost intuition without a live quote
Two habits keep estimates honest. First, always separate input from output volume before multiplying by any price, because the output rate is the larger of the two and dominates output-heavy workloads. Second, treat any vendor number as a tier or range with a check date, and re-read it before a purchasing or architecture decision. The context length cost page explains how context choices drive token spend, and the KV cache calculator shows the memory side of serving many users at once. For serving architecture and its overhead, see the LLM engine comparison. To start from the hardware decision itself, see run a model locally.
What this page does not tell you
- It does not list live vendor prices; all rates shift and the vendor pricing page is authoritative. Ranges here were last checked on 2026-09-17.
- It does not recommend a specific vendor or model; the right choice depends on region, workload shape, and quality needs.
- It does not account for non-token costs such as storage, vector databases, or the engineering time to integrate an API.
- It does not compare model quality, only the structure of how price is composed.