Skip to content

LLM Cost Calculator

Put one workload against three rate cards and see the monthly bill for each, split into fresh input, cached input and output.

The workload — one workload, run on all three

Option A — your rates

Option B — your rates

Option C — your rates

Cheapest of the three — Option B
$406.00 / month

The most expensive option, Option C, comes to $8,120 a month on the same workload — a spread of $7,714, or 20.0×.

Option A — per request
$0.02
Option B — per request
$0.0020
Option C — per request
$0.04
Option A — per month
$3,036
Option B — per month
$406.00
Option C — per month
$8,120
Fresh input, 2,400 tokens
$0.0012 per request
Cached input, 1,600 tokens
$0.000080 per request
Output, 500 tokens
$0.00075 per request
Output as a share of the bill
36.9%
Tokens per month, all meters
900,000,000
What this assumes: the three rate cards are the ones you typed, not a price list — this page ships no prices and never will. Input, cached input and output are billed on separate meters at the rates you gave. The cache-hit share is applied to input tokens only, and the write premium some providers charge the first time a prefix is cached is not modelled here; the prompt caching savings calculator does that separately. Reasoning tokens, if the model emits them, are billed as output on most price lists — fold them into the output figure. No per-request fee, no minimum, no tax.

A bill from an inference API is four numbers multiplied together and nothing else: how many requests you make, how many tokens go in, how many come out, and what each of those meters costs per million. Every argument about which model is cheaper is an argument about those numbers, and almost every one of them is conducted without writing them down. That is what this page is for — put one workload against three rate cards and the answer stops being a matter of opinion.

The thing most comparisons get wrong is the weighting. Output tokens usually cost several times what input tokens cost, so a model with a cheap input rate and an expensive output rate can lose badly on a summarisation workload and win comfortably on a classification one. The breakdown above shows output as a share of the total for exactly this reason: if it is over half, your lever is the output rate and the length of your responses, and shaving the prompt will do very little. If it is under a fifth, the reverse.

What this does not capture: rate limits you will hit before you hit this volume, retries, the requests that fail and get billed anyway, the cost of the second model you call to check the first one, and any committed-spend discount that changes the rate card at volume. It also treats a month as whatever you put in the requests field, so if your traffic is seasonal, run it twice — once for a quiet month, once for a peak — rather than trusting the average. And the cheapest option here is only cheapest at this volume and this shape; change the ratio of input to output and the ordering can invert entirely.

LLM Cost Calculator · Multigrid