How to Compare AI API Pricing Across Providers

To compare AI API pricing across providers you have to convert the advertised rate into cost per completed task, because the advertised rate is per million tokens and nothing you actually run is denominated in tokens. Four adjustments stand between the two numbers, and each one can move the answer by more than the price difference you were trying to measure. Teams that skip them regularly migrate to a cheaper model and watch the bill go up.

Here is the method, then the four adjustments.

The method to compare AI API pricing across providers

Take a representative sample of your real traffic, run it through each candidate model, and record total input tokens, total output tokens and the number of attempts it took to get an acceptable result. Multiply by each provider's current published rates. Compare cost per successful task.

Everything below is about why the shortcut version of that, comparing the headline per-million rates, gives the wrong answer.

Adjustment one: tokenizers differ

A token is not a unit of text, it is a unit of whatever that provider's tokenizer produces. The same 1,000-word document becomes a different number of tokens depending on whose model you send it to, and the variance is not small. Across major providers the same English input can differ by ten to twenty percent, and considerably more for code, for non-Latin scripts, and for text heavy in numbers or unusual formatting.

So a provider advertising a rate five percent lower can be more expensive on your actual content. The comparison is only valid once you have counted tokens per provider on your own text.

Both major providers ship counting endpoints for exactly this, such as Anthropic's token counting API. Use them on a real sample rather than estimating from a words-to-tokens rule of thumb. Our note on estimating tokens for a task covers what to sample and how much.

Adjustment two: output costs several times more than input

Every provider charges more for output than input, typically three to five times more, and sometimes more than that for reasoning models. Which means your input-to-output ratio determines which provider is cheaper for you, and the ratio varies enormously by workload.

That last row is the one that catches people. Reasoning models generate internal tokens before producing the visible answer, and those are billed as output whether or not you ever see them. A model with an attractive headline rate can be several times more expensive per task than a conventional model because most of what you pay for never reaches your screen. What test-time compute is explains why that trade exists and when it is worth paying for.

Check current rates at the source when you run this: OpenAI's pricing page, Anthropic's, and Google's Gemini API pricing. Rates change often enough that a comparison more than a few months old is a historical document.

Adjustment three: caching and batching change the answer

The published rate is the undiscounted, synchronous, cache-miss rate. Most production traffic does not qualify for it.

Prompt caching. If your requests share a large stable prefix, a long system prompt, a document, a set of examples, cached input is dramatically cheaper than fresh input on providers that offer it. For an assistant with a 4,000-token system prompt serving many short questions, caching can dominate the entire comparison. It also has rules, minimum cacheable sizes and time-to-live, so a workload with long gaps between requests may never hit a warm cache. See what prompt caching is for how it works.

Batch processing. Asynchronous batch endpoints typically cost around half the synchronous rate, with results returned within some hours. If any part of your workload is not user-facing, overnight enrichment, backfills, evaluation runs, classification of a queue, that half is available for the cost of a scheduler.

Committed-use discounts. Above a certain spend, negotiated rates exist and are not published. If you are large enough for this to matter, the public comparison is not the one you should be making.

The order matters here. Work out which discounts your workload qualifies for first, then compare. Comparing list prices and applying discounts afterwards produces the wrong shortlist, because eligibility differs per provider.

Adjustment four: retries and failures are part of the price

You pay for output you throw away. A model that returns malformed JSON one time in twenty costs you an extra five percent plus the latency, and if your retry sends the original request again you are paying the full input cost a second time.

This is where a cheaper model frequently loses. A model at half the rate that needs two attempts on fifteen percent of requests, and produces an answer you reject on another five, is not half the price. Measure it as cost per accepted output, not cost per call, and count the rejected attempts.

The same logic covers the case where a cheaper model needs more prompting to behave. If getting acceptable output requires three examples in every request, those examples are input tokens you pay for on every call, forever.

Putting it together

A worked shape rather than invented numbers, because provider rates move and specific figures would be stale within weeks.

1. Pull 200 real requests from your logs, spread across the kinds of work you actually do.

2. Count input and output tokens per provider using their own counting tools.

3. Classify each request by whether it could run batched, and whether it shares a cacheable prefix.

4. Run the sample against each candidate and record acceptance rate at first attempt.

5. Compute: (cached input tokens x cached rate) + (fresh input x input rate) + (output x output rate), divided by acceptance rate, with the batch discount applied to the eligible share.

6. Compare that number, per task, across providers.

Step four is the one people leave out, and it is the one that most often reverses the ranking.

What not to optimise for

Two traps.

Do not pick on price alone for a workload that is a small share of your bill. If a feature costs a few tens a month, the difference between providers is not worth an engineering week. Find your largest line item and work on that. Auditing where the spend actually goes usually reveals that a single endpoint is most of the bill.

Do not architect around today's prices. Rates have fallen repeatedly and unevenly, and each fall reshuffles the ranking. Keep the model identifier configurable, keep your evaluation set current, and re-run this comparison when prices move rather than committing your architecture to a provider because of a number that will change. What a price cut does and does not mean for your plans is covered in AI model price cuts and what changes for builders, and how to keep up with AI news is the low-effort way to notice when it happens.

If the total is the problem rather than the ranking, the levers in reducing AI API costs usually beat switching providers, because prompt size and retry rate are things you control and list prices are not.

FAQ

Is the cheapest model per token the cheapest overall?

Frequently not. Tokenizer differences, output-heavy workloads, retry rates and cache eligibility all move the real cost, and each can outweigh a headline rate difference of ten or twenty percent.

How often should I redo this comparison?

When prices change materially, when you add a workload with a different shape, or roughly twice a year otherwise. Keep the evaluation sample so re-running it is an afternoon rather than a project.

Do reasoning tokens really get billed?

Yes, as output, on every provider that offers reasoning models. They are usually the largest single line for those models and they are invisible in the response, so budget from measured usage rather than from what you can see.

What about self-hosting to avoid API pricing?

Different cost structure, not obviously cheaper. You trade a per-token bill for GPU capacity you pay for whether or not it is busy, plus the operational work of running it. Self-hosting wins at high sustained utilisation and loses badly at spiky low volume, so model your duty cycle before assuming it saves money.

Should I use a router to pick the cheapest model per request?

It can help, and it adds a component that has to be right. Routing works well when you have a clear split between easy and hard requests and a cheap, reliable way to tell them apart in advance. When you do not, the classifier cost and its mistakes eat the saving.