How AI provider pricing actually compares

Key takeaways

• You cannot fairly compare AI providers on one dollar-per-token number: real cost is the sum of separate input, output, and cached rates, plus tier, region, and billing-path effects.
• The fair method is to fix a representative workload and price it through each provider's full rate structure on identical assumptions, producing a cost per unit of work.
• Because negotiated rates go stale quickly, a durable comparison is a method you re-run against current rates, not a memorized price table.

The honest answer: there is no single comparable price

You cannot fairly compare AI providers on one dollar-per-token number, because no provider sells a single token at a single price. A model's real cost is the sum of several rates that the headline figure collapses: a separate price for input tokens and output tokens, a different price again for cached input, a context window that determines how much you must send on every call, a model tier that moves the rate by an order of magnitude, and a billing path that can apply commitments, marketplace markups, or regional differences on top of all of it. Two models can advertise a similar per-token figure and still differ by several times on the same workload once those dimensions are accounted for. The comparable number is something you compute from your own traffic, not something you read off a price page.

The right way to compare is to fix a workload and price it through each provider's full rate structure, rather than comparing list prices in the abstract. Take a representative request shape for the job you actually run, with its typical input length, output length, and cache-hit pattern, then run that same shape through every candidate model's input, output, cached, and context rates, at the tier and region you would actually buy. The output is a cost per unit of work, per provider, on identical assumptions. That is the only basis on which OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, and Google Vertex can be set side by side without one of them quietly being measured differently from the rest.

Why a single dollar-per-token number misleads

The first thing the headline number hides is that input and output are priced separately, usually with output several times more expensive than input. A workload that reads a long document and emits a short answer has a completely different cost profile from one that takes a short prompt and writes a long draft, even on the same model at the same nominal price. If you compare providers using a single blended rate, you implicitly assume one input-to-output ratio for all of them, and that assumption is almost never true across your real mix of tasks. The only honest unit is cost per request given that request's actual input and output token counts, not a single number that pretends the two are the same.

The second omission is cached input. Most providers now offer a reduced rate for input tokens they have seen recently, which matters enormously for agent loops, long system prompts, and retrieval-heavy workloads that resend large stable context on every call. A provider with a higher headline input rate but an aggressive cache discount can be cheaper in practice than a nominally cheaper provider with no caching, once your hit rate is factored in. Caching also has rules, around minimum sizes, time windows, and what counts as a hit, that differ by provider, so the effective discount is workload-specific. Ignore caching and you will systematically mis-rank providers for exactly the high-volume, repetitive workloads where the bill is largest.

The third distortion is the model tier. Each provider sells a family ranging from small, fast, inexpensive models to large frontier ones, and the price gap within a single vendor is usually far wider than the gap between vendors at the same tier. Comparing a frontier model from one provider against a mid-tier model from another tells you nothing useful about the providers; it tells you that you compared different tiers. A fair comparison holds capability roughly constant, matching like tier against like tier for the task, before it compares price. Otherwise the cheaper number is just the smaller model, and you have measured your own choice rather than the providers.

The billing layer: commitments, marketplaces, and region

Above the per-token rates sits a billing layer that can change the effective price without any model changing at all. The same Anthropic or OpenAI model can be purchased directly, through Azure OpenAI, through AWS Bedrock, or through Google Vertex, and each path carries its own billing semantics. A cloud marketplace may apply a markup or a discount, may let the spend count against an existing committed-use agreement, and may bury the AI line inside a larger infrastructure invoice. Committed-use and provisioned-throughput pricing trades a lower per-unit rate for a capacity or spend commitment, which only pays off above a usage floor you have to estimate honestly. None of this appears in a per-token comparison, yet it routinely moves the real cost more than the token rates do.

Region is the other quiet variable. The same model can carry different prices in different regions, and the region you must use is often dictated by data-residency or latency requirements rather than chosen for price. A comparison done in one region does not transfer to another, so the region has to be part of the fixed assumptions, not an afterthought. Provisioned or reserved capacity adds a further wrinkle, because its economics depend on utilization: a reserved unit is cheap per token only if you keep it busy, and expensive if it sits idle. The fair comparison therefore prices the billing path you will actually use, at the commitment level and utilization you can actually sustain, not the most flattering combination on each vendor's page.

Because these billing arrangements are negotiated, regional, and time-bound, the specific numbers go stale quickly and vary by customer, which is exactly why a durable comparison is a method rather than a memorized table. What stays constant is the structure: list rates, then caching, then tier, then the commitment and marketplace and region layer on top. Compare at the structural level and re-price against current rates when you need a decision, rather than trusting a figure that was true for someone else, somewhere else, last quarter.

Why per-provider dashboards can't give you one comparable price

A provider's own console can report what its own models cost, but it is structurally incapable of telling you whether a competing provider would be cheaper for the same work, because it cannot see the rate structure of any vendor but its own. Worse, no two consoles express price on the same basis: one quotes split input and output token rates, another folds usage into a committed-use discount that hides the unit price, a third routes through a marketplace where the AI rate is implied by a sub-line of a larger cloud bill. Tokens, requests, characters, and compute hours are not the same denominator, so the per-unit price one dashboard shows you and the one another shows you were never built to be subtracted from each other.

This is a different problem from reconciling five invoices into a monthly total. Even if every dashboard agreed on what you spent last month, none of them would tell you what a given request would cost on a provider you are not yet using, which is the question a procurement or routing decision actually turns on. Pricing comparison is forward-looking and counterfactual: it asks what the same workload would cost elsewhere, at a tier and region and commitment you may not have today. A console that only meters your existing usage on its own catalog cannot answer a counterfactual about a catalog it does not carry.

So the comparison falls to a human pricing it out by hand, mapping each vendor's rate card onto a common request shape and reconciling rate definitions that were written independently. The result is slow, error-prone, and stale the moment a vendor updates a price, and it usually compares list rates rather than realized cost, because realized cost requires joining real usage to the full rate structure including caching and commitments. The fix is to put usage and rates on one plane before anyone compares, so a price from Bedrock and a price from Azure OpenAI mean the same thing, decompose the same way, and can be exercised against the identical workload.

How to normalize onto one plane

Start by fixing the workload, not the price. Define a representative request profile for the job, including typical input tokens, output tokens, and the share of input that is cacheable, plus the tier of model the task genuinely requires and the region you must run in. This profile is the experimental control: every provider is priced against the same one. Holding the workload constant is what converts an unfair comparison of list prices into a fair comparison of realized cost, because it forces each provider's input, output, cached, and context rates to be exercised on identical assumptions rather than on whatever shape flatters that vendor.

Then compute cost per unit of work for each provider by running the profile through its full rate structure: input tokens at the input rate, output tokens at the output rate, cacheable input at the cached rate weighted by a realistic hit rate, all at the chosen tier and region, with the billing path's commitment or marketplace effect applied on top. Express the result as a single cost per request, or per thousand requests, that is directly comparable across providers because it was built from identical inputs. This is also the figure to feed a routing decision, because it answers what a real call costs, not what a token nominally lists for. When rates change, you re-run the profile rather than rebuild the comparison from scratch.

Finally, keep the comparison anchored to ground truth by reconciling it against measured usage rather than leaving it as a projection. Capture real input, output, and cached token counts from production traffic per provider and per model, apply the recorded rates at the time of use, and roll the result up by team, model, and provider so the comparison reflects what you actually ran rather than an idealized profile. Recording the cost as it happened, against the rate that applied then, keeps historical comparisons stable even as prices move, which is what lets you defend a routing or procurement decision later instead of watching last quarter's numbers shift every time a vendor updates a price.

Where Quordo fits

Quordo's spend surface is built to be the single normalized plane that a fair provider comparison requires. It connects OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, and Google Vertex, ingests usage from each, and computes dollar-cost on a common basis so a figure from one provider means the same thing as a figure from another. Live per-team cost attribution is shipped for all five, so you stop reconciling five consoles by hand. Cost rolls up by team, model, and provider, which is exactly the decomposition that lets you compare realized cost rather than list prices.

Because Quordo records what each unit of usage actually cost at the time it happened, historical comparisons stay stable as provider prices change, and the same data supports the operating loop around the comparison: budgets with deduplicated threshold alerts dispatched by webhook, spend anomaly detection against a trailing baseline, CSV export for chargeback, and an append-only audit trace spanning 15 event types. Quordo does not publish a live price table or claim one universal cheapest provider, because the honest answer is workload-specific; what it provides is the normalized, attributed, time-stamped cost data that turns the comparison method in this article into a number you can actually defend for your own traffic.

Frequently asked questions

Which AI provider is cheapest?

There is no universal answer — the honest one is workload-specific. Providers price input, output, and cached tokens separately, sell model tiers whose in-vendor price gaps exceed cross-vendor gaps, and layer commitments, marketplace effects, and regional rates on top. Fix your representative workload and price it through each provider's full rate structure to get a comparable number.

How do I compare OpenAI and Anthropic pricing fairly?

Hold the workload constant: define a representative request profile (typical input tokens, output tokens, cacheable share, required model tier, region), then run that same profile through each provider's input, output, and cached rates at the billing path you would actually use. The output is cost per request on identical assumptions — the only basis that doesn't quietly measure the two vendors differently.

Why is a dollar-per-token comparison misleading?

Because output tokens usually cost several times more than input tokens, cached input is discounted differently per provider, and each vendor's model family spans an order of magnitude in price. A single blended rate assumes one input-to-output ratio and one tier for everyone, which is almost never true of a real workload mix.

Related reading

• Governing a multi-provider AI estate
• LLM cost optimization techniques that cut the bill without hurting quality
• AI cost tracking: build it in-house or buy?