How to Actually Calculate LLM Cost (The Rate Card Will Mislead You)

Every LLM provider publishes two numbers: a price per million input tokens and a price per million output tokens. Almost every cost comparison you'll read — including most vendor marketing — ranks models on those two numbers.

We spent two weeks measuring what eleven model configurations actually cost on an identical battery of tasks. The rate card predicted the wrong winner five times out of five.

Here's why, and what to calculate instead.

The formula everyone uses

cost = (input_tokens × input_rate + output_tokens × output_rate) / 1,000,000

That's correct. The problem isn't the formula — it's that people plug in a blended ratio they assumed instead of token counts they measured.

The common shorthand is a 3:1 input-to-output ratio, which gives a single "blended price" you can sort a table by. It's convenient and it's where the error enters, because output token count is a property of the model, not of your workload.

Five times the rate card pointed the wrong way

Every row below is measured, same prompts, same max_tokens:

Two of those deserve a second look.

Kimi K3 charges $15 per million output tokens. GPT-5.6 Sol charges $30. Half the rate. K3 cost 54% more, because it emitted 3.1× the tokens for the same graded answers.

Gemini 3.6 Flash charges more than GPT-5.6 Luna on both input and output. It cost 32% less, because Luna used 1.9× the tokens.

If you sorted either pair by rate card, you'd pick the more expensive option.

The missing variable: verbosity

Across our eleven configurations answering the same three questions, output token counts ranged from 286 to 1,751 — a 6× spread.

Same questions, same grading, same pass rate — six times the words. You pay for every one.

Verbosity is not a small correction factor. On this spread it routinely exceeds the rate difference between tiers, which is why rate-card rankings invert.

What to calculate instead

1. Measure output tokens on your own prompts. This is the whole trick. Take ten representative prompts, run them through each candidate model, and record usage.output_tokens. Everything else follows.

2. Compute cost per unit of work, not per token.

cost_per_task = (in_tok × in_rate + out_tok × out_rate) / 1e6

Then multiply by your monthly volume. A model with double the rate and a third of the verbosity is cheaper, and only this arithmetic shows it.

3. Use your real input:output ratio, not 3:1. Your ratio is a property of your workload. A RAG pipeline stuffing 8,000 tokens of context to get a 50-token answer is nearly all input cost — the output rate barely matters, so the "expensive" model with a low input rate may win. A generation workload is the reverse. The 3:1 blended figure describes neither.

4. Account for reasoning tokens. On reasoning models, thinking tokens bill as output. A model can spend its entire budget thinking and return nothing at all — we measured Claude Opus 5 consuming 2,000 output tokens and producing an empty answer. Those tokens are billable.

5. Sample more than once. We measured Claude Opus 5 four times on an identical battery: $0.035025, $0.037125, $0.037225, $0.044200 — a 26% spread, same model, same prompts. If your cost comparison hinges on a gap under about 25%, one run hasn't resolved it.

A worked example

Say you're running a million code-review calls a month and choosing between GPT-5.6 Sol and Grok 4.5.

By rate card: Sol is $5/$30, Grok is $2/$6. Output rate ratio 5:1 — Grok looks about 5× cheaper.

Measured, on an actual review task:

A 9.8× difference, not 5×, and both models found all four planted bugs in our review test. The rate card underestimated the saving by roughly $18,000 a month.

The short version

• Never budget from a pricing page. It's an input to the calculation, not the answer.
• Measure output tokens on your prompts. Verbosity varies 6× and often exceeds the price difference between tiers.
• Use your own input:output ratio. The standard 3:1 blend describes an average workload, which is to say nobody's.
• Count reasoning tokens as output, because they bill as output.
• Run each measurement more than once. 26% run-to-run variance is our measured floor.

None of this is complicated. It's just arithmetic that almost nobody does, on a number almost everybody assumes.

Measure your own

• Run a prompt and see the token counts — no account, no API key

To compare token counts and real cost across models on your own prompts, that's Promptster.

All figures measured 2026-08-04 to 2026-08-09 via the Promptster API at max_tokens: 4000, computed from list pricing against actual token usage. Full per-model cost table in the August roundup. Prices change; the method doesn't.