Claude API Pricing: What You Are Actually Billed For

Search for Claude API pricing and you get tables. Tables are the part of a pricing page most likely to be wrong by the time you read it, because rates move and blog posts do not. Anthropic publishes the current per-model rates itself, on its pricing documentation, and that page is the only one worth trusting for a figure.

What is worth explaining instead is the structure, because the structure barely changes and it is what decides your bill. Once you know which dimensions you are billed on, you can read any table published on any day and work out what you will spend.

You are billed on more than one kind of token

The headline is per-token pricing split into input and output. On every model, output tokens cost more per token than input tokens, and usually by a wide multiple. That single fact reorders most cost intuitions. A job that reads a large document and returns a short verdict is cheap. A job that reads a short brief and writes at length is not, even though the second one moves far fewer tokens in total.

So the first question to ask about any feature you are costing is not how much text is involved, it is which direction the text is going.

Caching is a separate rate, not a discount

Prompt caching lets you reuse an already processed part of a prompt across requests, and it is billed on its own lines rather than folded into input. Writing to the cache costs more than sending the same tokens as ordinary input. Reading from it costs a fraction of the ordinary input rate.

That shape has a consequence worth internalising: caching is an investment that has to be earned back. Paying the premium once and then reading the cached content back many times is a large saving. Paying it and then never reading it back is a loss. Caches also expire, so how often your traffic arrives matters as much as how large the cached block is.

The Batch API trades latency for cost

Requests that do not need an answer now can be submitted asynchronously through the Batch API, which is discounted on both input and output. Backfills, evaluation runs, nightly enrichment and bulk classification are the natural fits. Anything a person is waiting on is not.

Tool use adds tokens you did not write

Giving a model tools adds input tokens beyond your own prompt: the tool definitions themselves, and an additional system prompt the API includes to enable tool use. Tool results come back as input too. None of this is hidden, and all of it is easy to forget when estimating from the length of your prompt alone.

Server-side tools can also carry their own usage-based charges on top of tokens, so a feature that looks like one API call may be billed on two dimensions.

A token is not a fixed amount of text

Different model generations use different tokenizers, which means the same string does not produce the same token count on every model. Comparing two models by their per-token rate alone is therefore not a comparison of what they will cost you. The comparison you want is rate multiplied by the tokens that model actually produces for your text.

This is the single most common error in cost estimates built from a pricing table, and it is the reason to count before you multiply.

Estimating before you build

The method is unglamorous and works. Take one representative request, count its input tokens with a token counter, decide roughly how long you expect the response to be, then apply the current published rates and multiply by your expected volume. Our LLM cost calculator does the arithmetic and lets you compare models side by side.

Do that once for the busiest path in your product and you will usually find the bill is dominated by one thing, not spread evenly. Three levers move it: which model handles the request, how much context you resend on every call, and how much you ask the model to write. Caching and batching are refinements on top of those, and neither rescues a design that sends a large prompt to an expensive model to produce a long answer nobody reads.

For more on building on top of these models, see the rest of our writing.