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 costs 5 times input on every Claude and GPT-6 model and 6 times on Gemini 3.1 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. The shape is the same everywhere: the first request writes a prompt prefix into the cache, and later requests that reuse that exact prefix read it at a steep discount. What differs is the price of the write.

• ▸ Claude. Mark a breakpoint with cache_control. A write costs 1.25 times base input for the 5 minute cache or 2 times for the 1 hour cache. A hit costs 0.1 times base, 0.05 times on Opus 5.5 and 0.025 times on Fable 5.1. Each hit also resets the timer.
• ▸ OpenAI. Caching is automatic on repeated prefixes. GPT-6 models list a cache write at 1.25 times input and a cached read at 0.05 to 0.1 times input.
• ▸ Gemini. Implicit caching has no write premium. Explicit caches bill a read rate of 0.1 times input plus storage per 1M tokens per hour, so a cache you keep alive all day has a fixed cost.

So the hit rate decides everything. Each miss pays the write price for the whole prefix, each hit pays the read price. On Claude with the 5 minute cache, the premium is 0.25 times and each hit saves 0.9 times, so one reuse pays for the write. On a quiet endpoint where requests are farther apart than the cache lifetime, almost every request is a miss and caching costs more than it saves. The hint under the cache inputs tells you which side of that line your traffic sits on. Matching is on an exact prefix, so keep timestamps and changing retrieval blocks at the end of the prompt.

Your token counts are estimates

This calculator does not tokenize anything. It multiplies the numbers you hand it. The token counter gives exact GPT counts and estimates for Claude and Gemini. If your numbers come from a characters divided by 4 rule of thumb instead, expect 10 to 15% error on English prose and worse elsewhere:

• ▸ Code. Indentation, braces, punctuation and camelCase splits push you nearer 2.5 to 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.