LLM API Cost Calculator
Price a workload from your own token counts, with cache reads and writes as separate lines. Fill in the two rate fields with the numbers on your invoice and the built-in table is ignored entirely.
llm-cost.txt
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Multiplying `input_tokens` by the input rate
With caching on that field is the uncached remainder, not the prompt. A dashboard built on it under-reports by exactly as much as the cache is working.
Instead:Add `cache_creation_input_tokens` and `cache_read_input_tokens` before multiplying, at their own rates.
Trying to cut an output-dominated bill with prompt caching
Caching touches input only, and output is priced several times higher. On a workload dominated by output it changes nothing measurable.
Instead:Ask for less: a conciseness instruction or a lower effort level. Trim the prompt when input dominates, not before.
Pricing against a published rate table
Rates change, introductory pricing expires, and negotiated or partner-platform rates differ from list. A forecast built on someone else's table drifts from the invoice with nothing to signal it.
Instead:Use the rates on your own invoice. This tool takes them as input for exactly that reason.
Why the forecast and the invoice disagree
Three things account for almost every gap: output is priced several times higher than input, cache reads and writes are separate line items, and the field most people multiply by is not the whole prompt.
input_tokens is the uncached remainder
The full prompt is input_tokens plus cache_creation_input_tokens plus cache_read_input_tokens. A dashboard that reads the first field and multiplies by the input rate under-reports a cached workload by exactly as much as the cache is working, so the better your caching, the more wrong the number. If an agent that ran for hours shows a four-thousand-token prompt, this is why.
Output costs several times what input does
The ratio is typically five to one. A workload whose bill is dominated by output gets no help from prompt caching, which only touches the input side. The lever there is asking for less: a conciseness instruction, or a lower effort level, moves the number where trimming the prompt does not.
A cache write is more expensive than an ordinary input token
1.25x at the five minute TTL, 2x at one hour. Writes with no reads against them are pure loss, and that combination is common: a prefix that changes slightly every request writes a fresh cache every time and reads nothing. Check cache_read_input_tokens on a real response before assuming caching is helping.
Enter your own rates
The built-in table has a date on it and is a convenience, not an authority. Published rates change, introductory rates expire, and partner platforms bill separately. Set input-rate and output-rate to the figures on your invoice and the table is ignored entirely, which is the mode this calculator is really for.
What this cannot see
Your token counts, which are the whole input to the arithmetic. This page has no tokenizer, calls no API and does not estimate from character counts, because a bad estimate on a cost forecast is worse than no forecast. Measure with the provider's token counting endpoint against a representative prompt. It also does not know about batch discounts, committed-use pricing, priority tiers or anything else negotiated on your account: those change the rate, so put the changed rate in.