Claude API Pricing Calculator

This Claude API pricing calculator takes what you send in words rather than tokens, and prices it across six current Claude models at once. That distinction matters more than it sounds. Anthropic changed its tokenizer at Claude 4.7, so the same paragraph is a different number of tokens depending on which model reads it, and a calculator that starts from a token count you typed in has already lost the comparison.

Enter a realistic call below. The breakdown shows where the money goes, and the second table prices the identical text across the lineup.

How this Claude API pricing calculator works

Anthropic bills per million tokens, separately for what you send and what comes back. A token is a fragment of a word, and Anthropic puts it at roughly three quarters of a word in English. That estimate predates the tokenizer change, so the calculator treats it as the baseline for the older models, which puts a 750-word prompt at around 1,000 tokens, then adjusts upward for the models on the newer tokenizer before multiplying by the published rate.

The rates below were read from Anthropic's pricing page on 11 August 2026. Treat them as a dated snapshot rather than a permanent fact, because this lineup has moved several times in the past year.

Claude API standard rates in US dollars per million tokens, read from Anthropic's pricing documentation on 11 August 2026. Cache write and read rates are fixed multiples of the input rate.

Model	Input	Output	5-min cache write	1-hour cache write	Cache read
Haiku 4.5	$1	$5	$1.25	$2	$0.10
Sonnet 4.6	$3	$15	$3.75	$6	$0.30
Sonnet 5	$2	$10	$2.50	$4	$0.20
Opus 4.8 and Opus 5	$5	$25	$6.25	$10	$0.50
Fable 5	$10	$50	$12.50	$20	$1

Sonnet 5 is the row that moved after this page first went up. Anthropic launched it at $2 and $10 as introductory pricing through 31 August 2026, with a step up to $3 and $15 scheduled for 1 September. That increase was canceled, and the introductory figures are now the standard price, confirmed on Anthropic's pricing page on 11 August 2026. The calculator uses $2 and $10. Worth noticing what this does to the lineup: Sonnet 5 now costs less than Sonnet 4.6, the older model, on both input and output.

The tokenizer gap, and why cross-model comparisons mislead

Here is the part most calculators miss. Anthropic's own pricing documentation states that Claude 4.7 and later models use a newer tokenizer, and that it produces approximately 30 percent more tokens for the same text. Sonnet 4.6 and earlier models use the previous one. The exact increase varies with the content, so treat 30 percent as the order of the effect rather than a constant.

"Claude 4.7 and later" is a generation label rather than a model you can select, so here is the boundary in terms of what you actually call. On the newer tokenizer: Sonnet 5, Opus 4.8, Opus 5, and Fable 5. On the previous one: Sonnet 4.6 and Haiku 4.5.

Call it the tokenizer gap. It has a specific consequence: a token count is not a property of your text, it is a property of your text on a particular model. Type one token figure into a calculator, switch models, and you are no longer comparing the same work.

Run the numbers on a thousand calls of 750 words in and 750 words out.

The same 750 words in and 750 words out, a thousand calls a month, at standard rates on 11 August 2026.

Priced as	Tokens each way	Per month
Sonnet 4.6, its own tokenizer	1,000	$18.00
Opus 5, its own tokenizer	1,300	$39.00
Opus 5, token count held at 1,000	1,000	$30.00

A calculator that holds the token count fixed quotes Opus 5 at $30.00 against a real $39.00, understating it by nine dollars, or 23 percent.

The direction of that error is what makes it worth naming. It runs one way: it understates whichever model sits on the newer tokenizer, and those are the current models. Anyone comparing an older model against a current one on a shared token figure gets an answer biased toward the upgrade. The bias is about which tokenizer a model uses rather than what it costs, so it shows up even between two models on the same headline rate.

That is the difference between a Claude API cost calculator that compares models honestly and one that looks like it does. Both multiply correctly. Only one converts your text separately for each model before it starts multiplying.

This does not mean the newer models are poor value. Anthropic's stated reason for the change is that the tokenizer contributes to better performance, and a model that resolves a task in one attempt can be cheaper than one that needs three. The point is narrower: compare on text, not on tokens, and let the per-model conversion happen inside the calculation.

Where prompt caching changes the answer

Caching is the largest lever in the calculator, and the one most likely to be modeled wrongly. You mark a stable opening section of your prompt, Anthropic stores the processed version, and later calls that begin with identical text read it back at a tenth of the input rate.

The catch is that storing it costs more than not caching at all. A five-minute cache write is billed at 1.25 times the input rate, and a one-hour write at twice the rate. So caching is a bet that you will reuse the stored prefix enough times to earn back the premium. Work it through and the thresholds are exact: a five-minute cache turns profitable on the second call inside its window, and a one-hour cache on the third. Below that, caching costs more than doing nothing, silently, with no error to tell you.

The calculator makes this visible. Set the reuse figure to 1 and it reports the loss rather than a saving. This is the failure mode that catches scheduled automations, which often fire once an hour or once a day and rarely land two calls inside a single cache window.

There is a second trap underneath that one, and it is quieter. Every model sets a minimum length for the section you are caching, and below it the cache does not engage at all. There is no error and no warning. The call returns normally, the counters read zero, and the bill is identical to not caching. Haiku 4.5 is where this bites hardest: its minimum is 4,096 tokens, roughly 3,100 words, and that is the highest of any model in this calculator. The obvious pick for a cost-conscious beginner is the hardest one to get caching working on. Opus 5 and Fable 5 sit at 512, and Sonnet 4.6, Sonnet 5 and Opus 4.8 at 1,024. The calculator checks your reusable prefix against the minimum for the model you picked, and when it falls short it prices the workload as uncached and says so, because that is what the API would charge.

Numbers from a real measurement rather than the arithmetic alone: in a run of 29 live API calls, five identical calls on an 8,587-token prompt cost 66 percent less with caching than without. That is well short of the 90 percent usually quoted, because the 90 percent describes the cached portion of the input alone and not a whole bill.

You can reproduce that figure in the calculator above rather than taking it on trust. Choose Haiku 4.5, set the input to about 6,440 words and the output to about 18, five calls, caching on, the reusable share at 100 percent, a five-minute lifetime, and five calls per window. It returns a saving within a fraction of a point of the measured 66 percent. That agreement is the check that the model of caching here matches what the API actually charged, rather than what the arithmetic hoped it would.

The Batch API is the other lever in the calculator and the least explained anywhere. It takes 50 percent off both input and output, and the discount stacks with caching, so the two combine rather than competing. The cost is time: batch work is asynchronous, so you submit a job and collect it later instead of getting an answer back in the same request. For anything a person is waiting on it is unsuitable. For overnight summarizing, backfills, and bulk classification it halves the bill for no change in output.

One benefit the calculator does not price, worth knowing anyway: on most current models, tokens read from cache do not count toward your input tokens per minute limit, while fresh input and cache writes do. Caching buys throughput headroom as well as a lower bill.

What this calculator does not model

Stating the gaps plainly, because a cost tool that hides its assumptions is worse than no tool.

• Token estimates are approximations. Converting words to tokens at three quarters of a word per token is a rule of thumb. Code, tables, other languages, and unusual formatting all shift it. For billing-exact figures, read the usage object Anthropic returns on every call.
• Fast mode is excluded. Opus 5 and Opus 4.8 can run at premium rates under fast mode, which the calculator does not offer.
• US-only inference is excluded. Pinning inference to the United States on Claude 4.6 and later applies a 1.1 times multiplier across input, output, and both cache categories.
• Tool use adds tokens. Tool definitions, tool calls, and their results all bill as input, and enabling tools adds a system prompt of a few hundred tokens.
• Server-side tools bill separately. Web search is charged per search on top of tokens.
• Retries are not counted. A call that completes and returns an answer you cannot use bills again when you retry it. Whether a call that errors bills at all depends on where it fails, so treat a retry-heavy workload as costing more than the figures here without assuming a particular multiple.
• Calls are assumed to run one after another. The "calls per cache window" figure assumes each call finishes before the next begins. Fire several at once against a cold cache and they can each be billed a cache write with no reads between them, which we measured at roughly three and a half times the sequential cost.
• Extended thinking is not counted. Thinking tokens bill at the output rate, and on reasoning-heavy work they can exceed the visible reply. If you run with thinking enabled, add your thinking budget to the output figure.
• Multi-turn and tool loops are not modeled. Each call here is treated as standing alone with a constant input. An agent loop resends a transcript that grows with every turn, so a scenario making several calls per run costs more than the per-call figure times the number of calls.
• Anything variable inside the cached section breaks it. A timestamp, today's date, or a reordered tool definition sitting above the cache mark invalidates the whole prefix, turning every call into a fresh write at 1.25 or 2 times the input rate. In practice this is the most common reason caching fails to pay. Keep everything that changes strictly below the mark.
• Images and documents are not counted. The word-count model has no way to express a scanned invoice or a screenshot, which bill as input tokens too.
• The one-hour cache is modeled without refresh-on-use. Anthropic documents that using a five-minute cache refreshes its lifetime. We could not confirm the same for the one-hour cache, so the calculator assumes it does not refresh. If it does, long-running schedules are cheaper than shown here.

That last one connects to something worth reading before you scale a workload up: the limits that govern how fast you can call at all. We cover those, and the throttling patterns that keep an automation inside them, in the Make and Claude workflows guide.

If you have not set up billing yet, getting a Claude API key and capping what it can spend is the place to start, and it covers the spend limit that stops any of these estimates from running away. For a guided route from nothing to three working automations, the AI-Curious Starter is a 30-day plan built around the same stack.

Common questions

How much does the Claude API cost per month?

It depends on volume, model, and how much of your prompt repeats. As an anchor, a thousand calls a month of roughly 750 words in and 750 words out costs about $6 on Haiku 4.5, about $18 on Sonnet 4.6, and about $39 on Opus 5 at the rates published on 11 August 2026. Prompt caching can take a substantial share off the input side when the same prefix is reused inside a cache window. Enter your own figures above rather than relying on those anchors, because output length moves the total more than most people expect.

Why does the same text cost more on newer Claude models?

Two reasons stack. The newer models carry a higher per-token rate, and Claude 4.7 and later also use a newer tokenizer that produces approximately 30 percent more tokens for the same text. The second reason is the one that surprises people, because it does not appear on a price list. Comparing models on a fixed token count hides it, which is why this calculator converts from words separately for each model.

Does prompt caching always reduce the bill?

No, and the cases where it does not are common. Writing to a five-minute cache costs 1.25 times the standard input rate and a one-hour cache twice that rate, so a call that stores a prefix and never reuses it costs more than the same call without caching. A five-minute cache needs a second call inside the window to break even, and a one-hour cache needs a third. Scheduled jobs that run hourly or daily often miss the window entirely and pay the premium on every run.

What is the cheapest Claude model for an automation?

On rate alone Haiku 4.5 is the least expensive of the current lineup at $1 and $5 per million tokens, and it also uses the older tokenizer, so it is cheaper twice over on the same text. Rate is not the whole cost though. A model that needs several attempts at a task can cost more than a pricier one that gets it right first time, and Haiku 4.5 has the highest minimum prompt length of the six models priced here, 4,096 tokens, before caching engages at all. Anthropic sets that same 4,096 minimum on Opus 4.5 and Opus 4.6, which this calculator does not price. Price the workload, then test whether the cheaper model actually does the job.

How accurate is estimating tokens from a word count?

Close enough for budgeting and not close enough for reconciliation. Roughly three quarters of a word per token holds reasonably well for ordinary English prose, and drifts on code, structured data, and other languages. Use it to decide whether a workload costs dollars or hundreds of dollars a month. When you need the real number, every API response reports exact token counts in its usage object, broken out by fresh input, cache writes, cache reads, and output.