Claude API Cost Calculator and Formula

The exact cost formula for a Claude API call

Anthropic prices by the token, quoted per million, which is the core of how Anthropic billing works. Every Messages API response returns an usage object with the two numbers you need: input_tokens and output_tokens. The base formula is:

cost = (input_tokens * inputRate + output_tokens * outputRate) / 1,000,000

inputRate and outputRate are USD per 1,000,000 tokens, and depend on the model.

That is the whole thing when you are not using prompt caching. Read the usage object right after the request returns, plug in the two counts, apply the rates for the model you called, and divide by a million.

The cache adjustment

Prompt caching splits input into three buckets, and each bills at a different multiple of the input rate. Cached reads are cheap, cache writes cost a small premium, and fresh input is full price. The usage object exposes cache_read_input_tokens and cache_creation_input_tokens alongside the fresh input_tokens. The full formula adds those two terms:

cost = ( input_tokens              * inputRate
       + cache_read_input_tokens     * inputRate * 0.1
       + cache_creation_input_tokens * inputRate * 1.25
       + output_tokens               * outputRate
       ) / 1,000,000

Cache read  = 0.1x the input rate  (served from cache, cheap)
Cache write = 1.25x the input rate (5 minute cache, small premium)

Cache reads land at one tenth of the normal input price. That is why a stable system prompt served from cache barely registers on the bill, while the same prompt sent fresh on every call is one of the most expensive things you can do. More on that mistake below.

A worked example on every current Claude model

Take one request: 2,000 input tokens and 500 output tokens, no caching. Here are the current Claude prices per million tokens, input and output. Confirm them on the Anthropic pricing page before you rely on any number, because they change.

Model               Input $/M    Output $/M
-------------------------------------------------
Claude Haiku 4.5    1.00         5.00
Claude Sonnet 4.6   3.00         15.00
Claude Opus 4.8     5.00         25.00

Model IDs: claude-haiku-4-5, claude-sonnet-4-6, claude-opus-4-8
All figures per 1,000,000 tokens. Current as of July 2026.

Now run the formula for each model. Input is 2,000 tokens, output is 500 tokens, everything divided by a million:

Haiku 4.5:   (2000 * 1 + 500 * 5)  / 1,000,000 = (2000 + 2500)   / 1,000,000 = $0.004500
Sonnet 4.6:  (2000 * 3 + 500 * 15) / 1,000,000 = (6000 + 7500)   / 1,000,000 = $0.013500
Opus 4.8:    (2000 * 5 + 500 * 25) / 1,000,000 = (10000 + 12500) / 1,000,000 = $0.022500

The spread is the point. The identical request costs five times as much on Opus as on Haiku, and three times as much on Sonnet. Same tokens, same prompt, five times the bill. Model choice is the single biggest lever you have on Claude cost, which is why you want Claude API cost per user broken out before you decide which feature runs on which model.

Notice how much output weighs

On all three models output costs five times its own input rate. In the Opus example, 500 output tokens contributed 12,500 of the 22,500 total, more than the 2,000 input tokens did. A feature that generates long responses is priced very differently from one that reads a long document and returns a short answer, even at the same token count.

Cost per 1,000 typical requests

Per call the numbers look like rounding error. Multiply by a thousand and the model choice becomes a real line item. Same 2,000 input, 500 output request, times 1,000:

Cost per 1,000 requests (2,000 input + 500 output tokens each)

Model               Per request    Per 1,000 requests
-----------------------------------------------------------
Claude Haiku 4.5    $0.004500      $4.50
Claude Sonnet 4.6   $0.013500      $13.50
Claude Opus 4.8     $0.022500      $22.50

A product doing a thousand of these calls is choosing between $4.50 and $22.50. Scale that to the real request volume of an active feature and the difference between Haiku and Opus is the difference between a rounding error and a meaningful monthly cost. For the trade beyond raw price, see Claude API cost optimization.

Streaming changes nothing about cost

A common assumption is that streaming is cheaper or more expensive. It is neither. Streaming changes how the response reaches you, delivered token by token instead of all at once, but the billed token counts are identical. The same input_tokens and output_tokens land on the usage object either way.

What streaming changes is perception. When you watch output arrive in real time, a long response feels like it is costing you as it goes, so people overestimate streamed calls and underestimate the quiet non streaming ones. Ignore the feeling and read the tokens. A 500 token response costs the same whether it appeared instantly or streamed over four seconds.

Estimating your monthly cost from daily volume

Once you have the cost of one representative request, the monthly projection is arithmetic. Pick a request size that matches your real traffic, compute its cost, then scale:

monthly cost = cost per request * requests per day * 30

Example: Sonnet 4.6, 2,000 input + 500 output tokens per request
  cost per request = $0.0135
  at 10,000 requests/day:
    $0.0135 * 10,000       = $135 per day
    $135 * 30              = $4,050 per month

Change the model and the number moves hard. The same 10,000 requests a day on Haiku 4.5 is $45 per day and about $1,350 a month. On Opus 4.8 it is $225 per day and about $6,750 a month. The projection is only as good as your estimate of the average request size, so recompute it whenever your prompts grow or your traffic mix shifts.

If you want to model this against your own plan pricing instead of a flat request count, run the numbers through the interactive cost calculator.

Three estimation mistakes that inflate real bills

1. Forgetting that output costs far more than input

Output is five times the input rate on every current Claude model, so token count alone does not tell you the cost. A feature that reads a long prompt and returns a short answer is cheap. A chatty feature that generates long responses on the same input is expensive. Estimate the output tokens honestly, not just the prompt you send.

2. Ignoring cache reads

If you use prompt caching and only count the fresh input, you will overestimate cost, because cache reads bill at one tenth of the input rate. A request with 500 fresh input tokens, 1,500 cache read tokens, and 500 output tokens on Sonnet 4.6 works out cheaper than the naive full price version:

Sonnet 4.6, with caching:
  (500 * 3 + 1500 * 3 * 0.1 + 500 * 15) / 1,000,000
  = (1500 + 450 + 7500) / 1,000,000
  = $0.009450

Same request billing all 2,000 as fresh input:
  (2000 * 3 + 500 * 15) / 1,000,000 = $0.013500

Same tokens, but the cached version costs about 30 percent less. If your estimate assumes every input token is full price, it is wrong in the expensive direction.

3. Forgetting the system prompt bills on every call

Your system prompt is input tokens, and it is sent on every single request. A 1,000 token system prompt on a million calls is a billion input tokens before the user has typed a word. People estimate the cost of the user message and quietly leave out the fixed overhead that dwarfs it. Count the system prompt in your input, and cache it if it is stable, or you will underestimate the bill by the size of the prompt times your request volume.

Let Weckr calculate this per user, automatically

Doing the math once is easy. Doing it per user, per feature, on every call, from current pricing, while Anthropic reprices over time, is the part that turns into a maintained price table you forget to update. Weckr wraps your existing Anthropic client in two lines and recomputes cost server side from the live pricing table on every request, so you never hardcode a rate.

Every call is recorded as a per user and per feature cost, across OpenAI, Anthropic, and Gemini in one place, so you can see which customers cost you more in Claude spend than they pay you. See it on seeded data with no signup at the live demo, and wire it in with two lines from the Weckr docs.

FAQ

From formula to a bill you can trust

The formula never lies, but a napkin estimate of the user message does. Real Claude bills come in higher than expected because output outweighs input, cache reads get ignored, and the system prompt rides along on every call. Count all of it, recompute from current rates, and the projection holds. This is one step in the complete guide to AI cost and margin management. See your real per user Claude cost at the live demo.