Guides / llm api cost calculator
LLM API cost calculator
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.
Computed in your browser, in exact decimal
Rates come from Culpa's price book, effective 2026-07-02. Every figure is computed in exact decimal rather than floating point, which is why totals here match an invoice to the cent. Cost is calculated, not provider-reported: it prices the tokens you enter at a published rate.
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.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Mistakes that cost the most
| Mistake | Why it hurts | Do instead |
|---|---|---|
| Modelling with a single blended price per token. | Output usually costs four to six times input, so the blend only holds at one mix. | Enter the three volumes separately. The split is where the money actually sits. |
| Estimating from call count rather than token count. | Calls vary in size by orders of magnitude, so a per-call average describes nothing. | Measure tokens. A call count only helps once you know the tokens behind it. |
| Leaving cached input out of the model. | Cached reads bill at a tenth, so ignoring them overstates a cache-heavy workload. | Enter your cached share. If you don't know it, that's the first thing worth measuring. |
Run this check tonight
- 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 example
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.
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.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| $610.00 | modelled monthly cost of the teardown workload priced across all three rates | calculated | (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 | Both endpoints from the teardown arithmetic at real rates. A range because the split between input and output is modelled. |
What a generic answer can’t know
A rate card is public and your split across the three rates isn't. It comes from your own traffic, it moves whenever a prompt changes, and no provider reports it back to you by feature. Culpa measures it on your infrastructure, keeps your prompts and responses there, and counts the calls to run your plan.
Questions founders ask next
How accurate is this calculator?
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.
Why does it ask for cached input separately?
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.
Why are OpenRouter models missing from the list?
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.
On your infrastructure
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.
How Culpa works
Find the culprit. Not just the total.
Your dashboard shows what you spent. It stops short of who spent it. Culpa shows the conversation, the user and the feature behind it.
Your prompts stay local.
Culpa runs on your own infrastructure. What you send to a model reaches us at no point.
Every dollar has a name.
Follow any charge to the conversation, the user, the feature and the customer behind it.
See the bill before it lands.
Cost your next feature before you ship it. You get the likely bill and the worst case, at best, median, p90 and p99.
Three steps to your first answer.
Change one base URL.
Or drop in the Python or TypeScript library.
Find your most expensive conversation.
In the first session, not the first week.
Cost your next feature before you ship it.
Why the bill went up
Example dashboardCalls traced
418,209
across 3 projects
Spend this week
$378.41
+ $182 vs last week
Failed calls
312
74% retried, and you paid for all of them
+ $182 this week traced to one culprit
Spend over 14 days
Most expensive users
Next week forecast
Graded against reality. Accuracy shown as results land.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Keep reading
Sources: Anthropic pricing. Last reviewed 2026-08-02. Plain text version.