# LLM API cost calculator

> Price any model in the book against your own token volumes. Every figure computes in exact decimal, so a total matches an invoice to the cent.

URL: https://getculpa.com/llm-api-cost-calculator
Last reviewed: 2026-08-02

## Answer
This LLM API cost calculator prices your own monthly token volumes against any model in Culpa's price book, splitting uncached input, cached input and output because they bill at three different rates. Culpa, a local-first LLM cost, margin, and forecast ledger, computes every figure here in exact decimal rather than floating point, so a total matches an invoice to the cent.

## Why this happens
Most cost estimates start by multiplying a call count by one price, and a model has three. Uncached input, cached input and output all bill at different rates, and on most rate cards output runs between four and six times input while a cached read costs a tenth. An estimate built on one blended number lands wherever your assumed mix happened to sit. The second problem is the arithmetic itself. JavaScript prices 40 million tokens at $0.0012 per thousand as 47.99999999999999, so a calculator reaching for the obvious multiplication publishes a figure that looks broken and rounds unpredictably.

## What this usually looks like
- A budget was built by multiplying calls by one price per call.
- Nobody split your volumes into uncached input, cached input and output.
- Your estimate and your invoice disagree by a factor rather than by a margin.
- Two people modelled the same workload and came back with different numbers.

## Common mistakes
- Modelling with a single blended price per token. Why it hurts: Output usually costs four to six times input, so the blend only holds at one mix. Do instead: Enter the three volumes separately. The split is where the money actually sits.
- Estimating from call count rather than token count. Why it hurts: Calls vary in size by orders of magnitude, so a per-call average describes nothing. Do instead: Measure tokens. A call count only helps once you know the tokens behind it.
- Leaving cached input out of the model. Why it hurts: Cached reads bill at a tenth, so ignoring them overstates a cache-heavy workload. Do instead: Enter your cached share. If you don't know it, that's the first thing worth measuring.

## Self-check
- Split last month's tokens into uncached input, cached input and output.
- Enter them above and compare the total against the invoice for the same month.
- If the two disagree, the gap is a capture problem rather than a pricing one.
- Change one volume at a time to see which of the three drives your bill.
- Re-run it against a second model before any migration decision.

## Where a blended estimate goes wrong (illustrative)
A workload of 200M uncached input, 50M cached input and 20M output tokens a month on Claude Sonnet 5, at real rates of $2.00 per million input, $0.20 cached and $10.00 output, effective 2026-07-02. Volumes are modelled.
  Uncached input: 200 x $2.00 = $400.00
  Cached input: 50 x $0.20 = $10.00
  Output: 20 x $10.00 = $200.00
  Exact total: $610.00
  As one blended rate that's $610.00 across 270M tokens, or $2.26 per million
  Move 50M from input to output: (150 x $2.00) + (50 x $0.20) + (70 x $10.00) = $1,010.00
  The blended rate still reads $610.00 for the same 270M tokens
The token count never moved and the true bill rose 66%. A blended rate carries an assumption about your mix, and the assumption is the part that breaks.

## Cost figures
Every figure carries its confidence and its source. No figure on this site is provider-reported.
- $610.00 — modelled monthly cost of the teardown workload priced across all three rates [calculated] Source: (200 x $2.00) + (50 x $0.20) + (20 x $10.00) per million, using real Claude Sonnet 5 rates from the price book, effective 2026-07-02. Token volumes are modelled.
- $610.00 to $1,010.00 — modelled monthly cost of the same 270M tokens under two different splits [estimated] Source: Both endpoints from the teardown arithmetic at real rates. A range because the split between input and output is modelled.

## FAQ
Q: How accurate is this calculator?
A: The arithmetic is exact. Every figure computes in whole-integer decimal rather than floating point, so totals match a hand calculation to the cent. What it doesn't know is whether the volumes you entered match your real traffic, which is the part worth measuring.

Q: Why does it ask for cached input separately?
A: Because a cached read bills at about a tenth of the uncached rate on every provider in the book. Folding it into one input number overstates a cache-heavy workload badly, and it's the most common reason an estimate lands above an invoice.

Q: Why are OpenRouter models missing from the list?
A: Because Culpa's price book carries a wrong cached rate for every OpenRouter row, tracked as an open defect. Offering the model would hand you a number already known to be off by as much as 10x, so it stays out until the rate is fixed.

## Sources
- Anthropic pricing: https://platform.claude.com/docs/en/docs/about-claude/pricing

Run the free Cost Leak Scan: https://app.getculpa.com/scan?source=pseo&slug=llm-api-cost-calculator&cluster=calculator

Machine-readable index of every guide: https://getculpa.com/api/pages
Human-readable index of every guide: https://getculpa.com/guides
Site overview: https://app.getculpa.com/llms.txt

Privacy: Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.