How we compute cost per request

Published 2026-08-16 · Prose last reviewed 2026-10-30 · Figures recomputed nightly from the 2026-11-14 catalogue snapshot

A specification, not an estimate. These are the formulas behind every cost-per-request figure on this site.

Every model row carries two cost figures: Cost / 1K req (list price) and Cost / 1K req (after discounts). The table prints them per 1,000 requests so a column of them can be compared without counting zeros. The formulas and worked examples below are per single request, so multiply by 1,000 to land on the table's figure. 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 and the assumptions behind them. More usefully, it lists the things they leave out on purpose, because that is where a budget built on them goes wrong.

The list-price formula

Cost per request at the price we quote, 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 Gemini 4 Argon (Google, $2.00/M in, $10.00/M out) at the Support Ticket profile:

The after-discounts formula

Same request, priced as if you had implemented the two optimisations the model publishes a rate for. Four 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 (where that discount is real).
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 (what that discount is worth).
3. Cache write, amortised. A token can only be read from the cache after it has been written there, and models that publish a write rate charge more for it than for ordinary input. The formula assumes one token written for every 5 read. A written token is one of the cache misses, already billed at the input rate by rule 2. What is added is the premium: the published write rate minus that input rate, never below zero. Under batch the write rate is taken as published, because no model publishes a batch rate for it. A model that publishes a read rate but no write rate is assumed to write at the ordinary input rate: premium zero.
4. 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 and leaves no write to charge. And if the write premium outweighs the read saving, the input side is billed uncached, since caching that does not pay is caching you would not switch on: the figure is never above list.

writePremium   = max(0, cacheWriteRate - inputRate)   (0 when no write rate is published)
writtenShare   = min(hitRate / 5, 1 - hitRate)

effectiveInput = cacheReadRate x hitRate
               + inputRate x (1 - hitRate)
               + writePremium x writtenShare
effectiveInput = min(effectiveInput, inputRate)

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

The 5 is a modelling assumption, not a published figure: how often a cached prefix is re-read before it must be rewritten is a property of your traffic. In a conversation, each turn re-reads the earlier turns and writes its own, which works out to (n - 1) / 2 reads per write over n turns, so 5 corresponds to an 11-turn session. A prompt shared by all requests under steady traffic does far better, and the same prompt at low volume does worse, because entries expire between requests. A write rate is published by 58 of the 310 priced models; 3 of them publish no read rate, so rule 3 has no caching to apply it to.

Rule 4 is the one that matters when reading the table. The after-discounts column is never lower than what the published rates allow, so where a model publishes nothing, the two figures are identical and the table prints a dash in place of the second one. A dash 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):

Gemini 4 Argon publishes a cache-write rate of $0.1875/M, 0.09x its input rate, so the written tokens cost the difference on top of the input rate their cache miss already paid.

A 21.4% 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.032 at list, $0.015 after discounts: 52.8% off. The monthly figure is this number multiplied by your volume and nothing else. At 100,000 requests a month, $3.2K becomes $1.5K.

Do not read 52.8% as typical. This example was chosen because it publishes both a cache and a batch rate, which only 69 of 310 priced models do. The median model on this profile saves 6.3%, for the reason set out in the next section.

How much the after-discounts column is worth

Measured across the 310 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. Batch is the larger discount, half off a 30/70 blend of both sides on 64 of the 75 models publishing it. But it can only apply to the 75 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 is why the Meeting Summary example above saved 52.8% while the median model on the same profile saves 6.3%. The example publishes batch rates; 235 of the 310 priced models do not.

These hit rates are modelling assumptions, not measurements of your traffic. They move the after-discounts column more than any other input, so treat that column as a shape rather than a quote.

Which models can be discounted at all

Of the 310 priced models, 232 publish at least one discount rate. The other 78 publish neither and therefore have an after-discounts cost identical to list. That is a disclosure gap, not a pricing fact: a model may well have a batch endpoint with no published rate card. Where the table shows a dash, 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 on an enterprise contract they are the largest single difference between this page and the invoice.
• Your real cache behaviour. The write is charged at one per 5 reads and the hit rates assume steady traffic. At 10,000 requests a month a request arrives about every 4 minutes against a typical 5-minute cache lifetime, so entries expire between calls, writes multiply and the after-discounts figure is optimistic. Longer-lived cache tiers, sold at a higher write rate, are not modelled at all.
• 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 can multiply the input side.
• 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 documentation of the host you buy from before concluding a model has no discount path.
• Re-run after any model switch. Discount coverage is a model maker's billing policy, not a property of the model, so a migration can change the optimisation case even when the headline rates look similar.

For a team at Crawl maturity the first step is splitting the bill into input, output, cache reads and cache writes, before any model is swapped. A team at Walk or Run already holds that split and can run the four rules on its own token counts instead of the presets. Every decision on this page depends on that split.

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

Data snapshot: 2026-11-14 · Compare all models · Cloud compute pricing · All guides