How we compute cost per request

A specification, not an estimate. These are the formulas the table, the model pages and the MCP server all run.

Every model row carries two cost figures: Cost/req (list price) and Cost/req (after discounts). They answer different questions, and the gap between them is the only part of the number you control. This page gives both formulas in full, the assumptions behind them, and — more usefully — the things they deliberately leave out, because that is where a budget built on them goes wrong.

The list-price formula

Cost per request at the published rate card, with no optimisation assumed:

cost = (inputTokens / 1,000,000) x inputPrice
     + (outputTokens / 1,000,000) x outputPrice

That is the whole of it. The token counts come from the use-case profile you pick in the scenario bar; the prices come from the catalogue. Nothing else enters.

Worked, on Claude Haiku 4.5 (Anthropic, $1.00/M in, $5.00/M out) at the Support Ticket profile:

The after-discounts formula

Same request, priced as if you had implemented the two optimisations the provider publishes a rate for. Three rules, applied in order:

1. Batch substitution. If the use case is asynchronous and the model publishes both batch rates, the batch input and output rates replace the list rates outright.
2. Cache read on the hit-rate share. The profile's cache hit rate is the fraction of input tokens billed at the published cache-read rate; the remainder bills at whatever rate rule 1 left in place.
3. Fall back, never invent. A model that publishes no batch rate keeps list prices for rule 1. A model that publishes no cache-read rate has its cached share billed at the ordinary input rate, which makes the discount zero.

effectiveInput = cacheRate x hitRate + inputRate x (1 - hitRate)

cost = (inputTokens / 1,000,000) x effectiveInput
     + (outputTokens / 1,000,000) x outputRate

Rule 3 is the one that matters when reading the table. The optimized column is never lower than what the provider will actually honour, so where a model publishes nothing, the two columns are identical — and an identical pair means "nothing published", not "no savings available".

The same request, now at the Support Ticket profile's 60% cache hit rate (this profile is synchronous, so no batch rate applies):

A 20.3% reduction, entirely from prompt caching. Note where it comes from: output is untouched, so the saving is bounded by the input share of the request before caching is even discussed.

An asynchronous profile exercises both rules. At Meeting Summary (10,000 in, 1,200 out, 10% cache hit, batch-eligible) the batch rates replace list on both sides first, and the cache rate then applies to 10% of input:

$0.016 at list, $0.0076 optimized: 52.5% off. The monthly figure is this number multiplied by your volume and nothing else — at 100,000 requests a month, $1.6K becomes $760.

Do not read 52.5% as typical. This example was chosen because it publishes both a cache and a batch rate, which only 58 of 254 priced models do; the median model on this profile saves far less, for the reason set out in the next section.

How much the optimized column is actually worth

Measured across the 254 models carrying both prices, counting only those that receive a discount for that profile. Knowledge Q&A moves furthest at 21.0%; Marketing Content moves least at 3.9%.

The ordering rewards cache hit rate rather than batch eligibility, which is worth pausing on. Batch is the larger discount — typically half off both sides — but it can only apply to the 58 models publishing a batch rate, so on an asynchronous profile the median model still gets nothing from it. A high cache hit rate pays out on every model publishing a cache rate. That gap is the whole reason the Meeting Summary example above saved 52.5% while the median model on that same profile saves 6.1%: one model publishes batch rates, most do not.

These hit rates are modelling assumptions, not measurements of your traffic. They are the single biggest lever on the optimized column, so treat that column as a shape rather than a quote.

Which models can be discounted at all

171 of 254 priced models publish at least one discount rate; 83 publish neither and therefore show an optimized cost identical to list. That is a disclosure gap, not a pricing fact — a provider may well run a batch endpoint it has not published a rate card for. Where the two columns match, the correct reading is that we have nothing to quote.

What these numbers deliberately exclude

Every exclusion below is a decision, not an oversight. Each one would have made the figure look better and less true.

• Your negotiated rates. These are public list prices. Committed spend, marketplace agreements and enterprise terms all sit outside them, and they are usually the largest single difference between this page and your invoice.
• Retries and failures. A request that errors after generating output is billed. Timeouts, tool-call loops and validation retries are real line items that no token profile models.
• Reasoning tokens. On models that think before answering, the reasoning trace bills as output and can dwarf the visible answer. The profiles here count the answer.
• The system prompt, past the profile. Input tokens are the profile's assumption, not your prompt. A long system prompt, a tool schema or a RAG context window changes the input side substantially.
• Everything that is not tokens. Fine-tuning, embeddings, storage, egress, the compute you run around the model, and the engineering time to implement the caching this page credits you for.
• Throughput and rate limits. Two models at the same cost per request are not equivalent if one needs three times the concurrency to hold your latency target.

Using the number honestly

• Compare with it; do not budget with it. Ranking models against one another is what a common set of assumptions is good for. A committed monthly figure needs your own token counts.
• Measure your input-output split before trusting any saving. Caching cannot touch output, so an output-heavy workload has a low ceiling however good the hit rate.
• Treat an identical column pair as missing data. Check the provider's own documentation before concluding a model has no discount path.
• Re-run after any model switch. Discount coverage varies far more between providers than list prices do, so a migration can change the optimisation case even when the headline rates look similar.

For a team early in its FinOps practice the first useful step is not choosing a cheaper model, it is splitting the bill into input, output, cache reads and cache writes. Almost every decision on this page becomes obvious once that split exists, and almost none of them are answerable without it.

The FinOps reasoning behind this guide comes from OptimNow's open-source practice library: github.com/OptimNow/cloud-finops-skills.

Data snapshot: 2026-08-16 · Compare all models · Cloud compute pricing · All guides