LLM Cost Calculator.

Input and output are two prices

Every provider bills two meters, not one. Tokens you send are input; tokens the model generates are output, and output is always the expensive side. In the dropdown above, output runs 5× input on every Claude tier, 6× on GPT-5.4 and GPT-5.5, and 8× on Gemini 2.5 Pro.

That gap is hardware, not margin games. Your prompt is processed in one parallel prefill pass, while output emerges one token at a time, each needing a full forward pass — a sequential, memory-bandwidth-bound loop. So classification, extraction and routing are cheap per request, while drafting and code generation are not. At a 5× ratio, 200 extra output tokens cost exactly what 1,000 extra input tokens cost.

Prompt caching redraws the maths

Caching is the biggest lever on this page, and the checkbox above only gestures at it. The shape is the same everywhere: pay a premium once to write a prompt prefix into the cache, then pay a steep discount whenever a later request reuses that exact prefix. Anthropic makes it explicit — mark a breakpoint with cache_control, writes cost 1.25× base input on the 5-minute TTL (2× for an hour), reads roughly 0.1×. OpenAI and Google discount repeated prefixes automatically rather than charging for the write.

The break-even is trivial: the write premium is 0.25× and every hit saves 0.9×, so one reuse inside the TTL pays for it. It fails two ways. Matching is on an exact prefix, so a timestamp or re-ordered retrieval block near the top invalidates everything after it — keep volatile parts last. And the TTL is short, so a low-traffic endpoint pays the premium more often than it collects the discount. The checkbox here assumes half your input hits cache at 0.1×, or 0.55× on input overall, and charges nothing for writes.

Your token counts are estimates

This calculator does not tokenize anything — it multiplies the numbers you hand it. If those came from the token counter here, or any characters ÷ 4 rule of thumb, expect 10–15% error on English prose and worse elsewhere:

• ▸ Code. Indentation, braces, punctuation and camelCase splits push you nearer 2.5–3 characters per token, so a prose-tuned estimate undercounts a diff.
• ▸ Non-English text. Tokenizer vocabularies are English-dominated, so Cyrillic, Devanagari, Arabic and CJK routinely cost two to four times as many tokens.
• ▸ High-entropy strings. UUIDs, hashes, base64 and minified JSON have no learned merges and fragment almost character by character.
• ▸ Reasoning tokens. Billed as output whether or not the API hands the text back to you — the line item that surprises people on thinking models.
• ▸ Images and audio. Converted to tokens by a per-tile or per-second formula, billed at the input rate.

Providers also use different tokenizers, so the same string counts differently on Claude, GPT, and Gemini. When it matters, count with the provider's own.

Batch mode is 50% off, mostly unclaimed

Anthropic, OpenAI, and Google all sell the same deal: submit work asynchronously and pay roughly half list on both meters, in exchange for a turnaround measured in minutes to 24 hours. Same models, half the invoice.

Anything a human is not waiting on belongs in the right-hand column: embedding backfills, evals, nightly enrichment, bulk classification. To model it, pick Custom and halve both prices.

The agent loop is where bills explode

The single biggest surprise on a real invoice: an agent does not make N cheap calls — it re-sends the entire conversation every turn. Each tool result is appended, and the whole transcript, system prompt and tool definitions included, goes back over the wire next turn. Input cost grows quadratically with turn count.

Concretely: a 3,000-token system-and-tools header, 1,200 tokens added per turn, 20 turns. Turn one sends 3,000 input tokens; turn twenty sends 25,800; the run totals 288,000 for an average of 14,400 per call. Estimating it as "20 calls at the opening prompt size" understates the bill by nearly 5×.

So the input tokens / request field above wants the average across turns, and requests per day means tasks per day times turns per task. Caching also stops being optional here: an agent conversation grows purely by appending, the ideal cache shape. And it is why capping an agent by request count, not tokens, protects nothing.