This calculator vs. a blended per-token estimate
"Multiply my monthly tokens by the $/M rate on the pricing page" is a one-line estimate. It also assumes every input token is billed the same, which is the assumption cached-token pricing exists to break.
What each approach actually involves
The blended estimate takes one rate -- almost always the fresh-input rate, since that is the number a pricing page leads with -- and multiplies it by the whole month's input tokens, cached and fresh lumped together, then adds output cost. One rate, one multiplication, done.
This calculator takes the same fresh-input, cached-input, and output rates a pricing-page lookup gives you and asks for the month's fresh input, cached input, and output tokens as three separate figures, then prices each token class at its own rate for up to four providers at once.
| Worked example | Blended (fresh rate on everything) | This calculator (split by token class) |
|---|---|---|
| 5,000,000 fresh input + 45,000,000 cached input + 2,000,000 output tokens/month, at $3.00 / $0.30 / $15.00 per million | $180.00/month — 50,000,000 input tokens × $3.00, plus $30.00 output | $58.50/month — $15.00 fresh input + $13.50 cached input + $30.00 output |
These are the calculator's own default inputs and the Anthropic (Claude) example row preloaded on the calculator page, so you can load them there and check the arithmetic yourself. Blending overstates this workload by $121.50/month -- about 3.1x the real total -- entirely from billing 45,000,000 cached tokens at the fresh rate instead of the cached rate. That gap tracks the workload's cached share directly: at 90% cached input (this example's share), most of the bill is the rate the blended estimate got wrong. See why prompt caching changes the math for why that share runs high on agentic and long-context workloads specifically.
| Question | Where to answer it |
|---|---|
| I want a provider's current fresh-input, cached-input, or output rate. | The provider's own pricing page — this calculator never fetches or asserts that for you. |
| I just want a rough monthly ceiling and don't know or care about my cache share. | A blended estimate is fine as a ceiling — it is usually an overstatement, not an understatement, of the split total. |
| I want to compare providers, or know what caching is actually worth on my workload. | This calculator — free, instant, private, no account. |
This tool needs no account and no sign-in: it is a static page, the arithmetic runs in your browser, and once it has loaded it keeps working with the connection off.
Common questions
What is the blended-per-token shortcut this page compares against?
Taking a provider's headline $/million-token rate -- almost always the fresh-input rate, since that is the number a pricing page leads with -- and multiplying it by the month's total input tokens, cached and fresh together, then adding output cost on top. It is a one-line estimate: no separate cache rate, no split, one multiplication.
How much can a blended estimate overstate the bill?
On this calculator's own default example workload (5,000,000 fresh input, 45,000,000 cached input, 2,000,000 output tokens per month) at Anthropic's example rates ($3/M fresh input, $0.30/M cached input, $15/M output), the split calculation totals $58.50/month. Blending -- billing all 50,000,000 input tokens at the $3 fresh rate -- totals $180.00/month, about 3.1x the real figure and $121.50/month higher, entirely from treating cached tokens as if they were fresh.
Does a blended rate always overstate cost, or can it understate it too?
It depends which single rate gets picked, and a headline rate is the fresh-input rate far more often than not, so overstating is the common direction. Picking the cached rate instead and applying it to fresh tokens too would understate the bill -- but that requires already knowing the cached rate exists and choosing to (wrongly) apply it everywhere, which is not the shortcut anyone reaches for by habit. Either way, the fix is the same: stop picking one rate and use each token class's own rate.
Does this page assert any provider's actual cache discount?
No. The $3.00 / $0.30 / $15.00 example rates above are the same illustrative placeholders preloaded on the calculator page, not a claim about Anthropic's or any provider's current pricing. Paste in each provider's own current rates from its pricing page before relying on either number.
Open the LLM API Pricing Calculator to split your own workload, or read why prompt caching changes the math.