Free tool · pricing verified 2026-08-02
Most cost estimates are wrong in the same three ways: they forget that tool definitions are billed on every call, they ignore retries, and they compare headline token prices between models whose tokenizers disagree about what a token is. This one accounts for all three.
Prompt + history + retrieved context
Billed on every call, used or not
Estimated monthly spend
—
— per year at this volume
Lost to retries: —/month.
Each of these is computed against your numbers above, in the order I would normally attempt them. Every one assumes you have evals to verify quality did not move — without that, these are guesses rather than optimisations.
This is the table that usually ends the debate about whether routing is worth the engineering effort.
| Model | $/month | Per conv. | vs selected |
|---|
Token multipliers are applied, so this compares cost for the same text, not the same token count. That is why two models with identical headline prices can differ here.
Send me the scenario and I will tell you which lever I would pull first. The message is composed in your browser and pre-filled with your figures.
These are the reasons a careful estimate still comes in under the invoice.
Claude Opus 4.7 and later use a newer tokenizer that produces roughly 30% more tokens for the same text than Claude Sonnet 4.6 and earlier. A model with an identical headline price can therefore cost about 30% more for identical input. Cost models that compare only $/MTok miss this entirely.
Sonnet 5 is $2/$10 per MTok through 31 August 2026, then $3/$15 — a 50% increase. If your forecast assumes current pricing beyond that date, it is roughly 50% light on that line item.
A 5-minute cache write is 1.25x base input price and a 1-hour write is 2x. A cache read is 0.1x. Caching only pays off once content is actually re-read — after one read for the 5-minute tier, two for the 1-hour tier. Caching a prompt that is never reused makes it more expensive, not less.
Tool schemas sit in the input of every request, plus a per-model tool-use system prompt of roughly 286–804 tokens. An agent with fifteen verbose tool definitions pays for all fifteen on every turn, whether it calls them or not — one of the most common invisible costs in agent systems.
Prices verified against provider documentation on the date above. Provider pricing changes; the figure that matters is your own measured cost per conversation. Treat this as a planning model, not an invoice.
All figures in USD per 1,000,000 tokens, verified 2026-08-02.
| Model | Provider | Input | Cached | Output | Batch in/out | Context |
|---|---|---|---|---|---|---|
| Claude Opus 5Newer tokenizer: expect ~30% more tokens for the same text than Sonnet 4.6 and earlier. | Anthropic | $5.00 | $0.500 | $25.00 | $2.50 / $12.50 | 1,000k |
| Claude Sonnet 5Introductory pricing through 31 Aug 2026; rises to $3/$15 on 1 Sep 2026. | Anthropic | $2.00 | $0.200 | $10.00 | $1.00 / $5.00 | 1,000k |
| Claude Haiku 4.5Strong default for classification, extraction and routing sub-tasks. | Anthropic | $1.00 | $0.100 | $5.00 | $0.50 / $2.50 | 200k |
| Claude Fable 5Highest tier. Rarely the right default for high-volume agent traffic. | Anthropic | $10.00 | $1.000 | $50.00 | $5.00 / $25.00 | 1,000k |
| GPT-5.6 Sol | OpenAI | $5.00 | $0.500 | $30.00 | $2.50 / $15.00 | 400k |
| GPT-5.6 Terra | OpenAI | $2.00 | $0.200 | $12.00 | $1.00 / $6.00 | 400k |
| GPT-5.6 LunaCheapest credible option here — useful as the low end of a routing tier. | OpenAI | $0.20 | $0.020 | $1.20 | $0.10 / $0.60 | 400k |
| GPT-5 NanoViable for narrow classification and routing where quality is measurable. | OpenAI | $0.05 | $0.005 | $0.40 | $0.03 / $0.20 | 400k |
Multiply the number of billed API calls by the cost of the tokens in each call. Calls equal conversations × turns per conversation × (1 + retry rate). Tokens per call are the prompt, the conversation history, any retrieved context, and — the part usually forgotten — your tool definitions, which are billed on every single call whether the tools are used or not.
Then split input tokens between cached and uncached, because a cache read costs roughly a tenth of standard input, and apply the output token price separately since output is typically 5× the input price.
Four causes account for most of the gap, in rough order of frequency: conversation history resent in full on every turn so per-turn cost grows with conversation length; tool definitions billed on every call; retries that nothing is counting; and newer models that produce more tokens for the same text because their tokenizer changed.
The last one is genuinely invisible if you compare only headline $/MTok. Claude Opus 4.7 and later produce roughly 30% more tokens for identical text than Claude Sonnet 4.6 and earlier, so equal prices per token do not mean equal cost per word.
Route by task difficulty. Classification, extraction, routing and formatting rarely need a frontier model, and moving those sub-tasks to a cheap model typically recovers 40–70% of spend with no measurable quality loss — provided you have an eval suite to verify that claim rather than assume it.
After that: cache stable prompt prefixes, bound conversation history explicitly, and trim tool definitions. Batch processing gives a further 50% on anything that is not latency-sensitive.
No. A cache write costs more than ordinary input — 1.25× base for the 5-minute tier and 2× for the 1-hour tier — while a read costs 0.1×. Caching only pays off once the content is actually re-read: after one read for the 5-minute tier, two for the 1-hour tier.
Caching a prompt prefix that is never reused makes it more expensive. Cache the system prompt and tool definitions; do not reflexively cache everything.
It is a planning model, not an invoice. Provider prices are verified as of 2026-08-02 and the arithmetic is exact, but your real cost depends on your actual token distribution, which no calculator can know.
Use it to size decisions — is this feature viable, is routing worth doing, what happens at 10× volume — and then measure real cost per conversation in production, which is the number that actually matters.
An agent that costs too much is normally an agent that retries too often, carries too much context, or calls a frontier model for work a cheap one would do. Those are reliability problems wearing a finance costume. The readiness scorecard will tell you which one you have.
Nothing matched. Try “cost”, “loop”, “evals”, or “rates”.