Four things drive a Claude bill. The price list is not one of them.
Four things drive a Claude bill, and the published price per token is rarely the one that hurts: tokens attached per case, turns per case, whether caching and batching are used, and which model and platform answer each step. Pexon forecasts all four against real cases before a rollout is signed.
The rate card is public. Your token count is not.
Almost every Claude cost conversation starts with the price per million tokens, which is the one number in the whole model that is published, comparable and outside your control. It is also the least useful, because two companies paying the same rate can be two orders of magnitude apart on the invoice. The difference is not the price. It is how many tokens a single piece of work consumes and how many times it consumes them.
When we rebuild a client's forecast, the term we end up correcting is almost never the rate. It is tokens per case — the retrieved context, the tool definitions, the conversation history replayed on every turn — because that is the term nobody had a number for and everyone had a feeling about. That is why this page describes mechanics rather than euros: the mechanics are stable, and the price list on any given day is one click away from the vendor who owns it.
What actually moves the number
Four levers, in the order they usually matter. The first two are design decisions in your own application. The third is a pair of configuration choices Anthropic publishes multipliers for. The fourth is the only one that looks like procurement, and it is the smallest of the four in most rollouts we see.
| Driver | What it does to the bill | What decides it |
|---|---|---|
| Tokens attached per case | Scales linearly with adoption, so it is the one term that grows precisely when the rollout is going well | Retrieval design, tool schema size, and how much conversation history is replayed on every turn |
| Turns per case | Every tool call resends the whole conversation as input, so an agent loop bills the same context repeatedly | Whether the workflow is one call or an agent loop, and where the loop is allowed to stop |
| Caching and batching | Cache reads bill at 0.1x the base input rate; the Message Batches API bills at 50 percent for work that can wait | An engineering decision inside your own code, not a procurement decision at the vendor |
| Model and platform per step | Changes the rate card itself, and residency, batch and caching multipliers stack on top of each other | Routing policy, and whether inference is contractually required to stay in one geography |
Multipliers as published by Anthropic: prompt caching (cache read 0.1x base input, five-minute write 1.25x, one-hour write 2x, and a minimum cacheable prefix of 512 to 4,096 tokens depending on model) and batch processing (50 percent of the standard rate, most batches under an hour, requests expiring unbilled after 24 hours). These multipliers stack with each other and with data residency, so they compound rather than compete.
Count tokens on real work, not on a demo prompt
The forecast that survives contact with production is built from measured tokens per case, and Anthropic gives you the measurement for free. The count_tokens endpoint returns the input token count for a request against the model you name, is not billed, and takes the same payload shape as a real call — system prompt, tools, images and PDFs included. There is no reason to guess.
# Free. Returns {"input_tokens": N} for the model you name.
# Run it over a sample of real cases, not the shortest one you have.
curl https://api.anthropic.com/v1/messages/count_tokens \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d @one-real-case.json- Pick one real queue you intend to automate, and take a sample of cases from it — not a demo prompt, and not the shortest ticket you could find.
- Run each case through count_tokens against the exact model you plan to call, because token counts are not portable across model generations.
- Count the turns a case actually needs end to end, including retries, tool calls and the ones a human sends back.
- Multiply tokens by turns by the published rate, then apply the caching and batch multipliers you can honestly commit to shipping.
Endpoint behaviour, tokenizer differences between model generations, and the free-tier rate limits: Anthropic token counting documentation.
Euros per million tokens is not a budget
Convert the four drivers into one figure and the conversation changes shape: cost per case. Tokens per case, multiplied by turns per case, multiplied by the rate of the model that answers, gives you cost per resolved ticket, per reviewed contract, per generated report. That is the number a finance function can compare against what the work costs today, and it is the number that decides whether the rollout continues after the pilot budget runs out.
It also reprices the levers correctly. A caching decision that removes most of a repeated prefix moves cost per case immediately, because a prefix written once and read once bills 1.35x against 2x for sending it twice — cheaper from the second call onward, every call after that widening the gap. Negotiating the rate card does not come close to that, and it is the thing most procurement teams spend their effort on.
The model is usually not the biggest line
Once a rollout passes pilot, the lines that grow fastest are not tokens. They are the evaluation and regression suite that tells you a model change did not break an answer, the retrieval layer that supplies the context those tokens are made of, the identity and logging plumbing that makes the assistant auditable to someone other than the team that built it, and the engineering time to keep all three correct while the model line-up turns over underneath them.
None of that appears on a pricing page, which is exactly why cost surprises arrive after the pilot budget rather than during it. A forecast that only prices inference is not wrong about inference. It is silent about the majority of the spend.
Cost questions, answered one page at a time
What buyers ask about Claude cost
How much does Claude cost for a company?
There is no single figure, and any page that gives you one is quoting a price list that has already changed. Anthropic and the cloud platforms publish a rate per million tokens; what a company pays is that rate multiplied by how many tokens each piece of work consumes and how many turns it takes. The rate is public. The multiplier is yours, and it is the half worth measuring.
Does prompt caching actually reduce a Claude bill?
Yes, wherever the same prompt prefix is reused. Anthropic prices cache reads at 0.1x the base input token rate, a five-minute cache write at 1.25x and a one-hour write at 2x. A prefix written once and read once therefore costs 1.35x, against 2x for sending it twice uncached, so caching is already cheaper on the second call — provided the prefix is stable and long enough to be cacheable at all.
What is the cheapest way to run high-volume Claude workloads?
For work that does not need an answer in the next second, the Message Batches API. Anthropic prices batched requests at 50 percent of the standard rate; most batches finish within an hour, requests expire after 24 hours, and expired requests are not billed. Overnight classification, extraction and evaluation runs are usually the easiest half of a bill to remove.
Why did our Claude bill rise after we moved to a newer model?
Often because the tokenizer changed rather than the price. Anthropic documents that models from Claude 4.7 onward use a newer tokenizer that produces roughly 30 percent more tokens for the same text, and billing follows the count of the model you actually call. Token counts measured against an older model are not a valid forecast for a newer one.
How do we forecast a Claude bill before signing anything?
Count tokens on real work rather than on a demo prompt. Anthropic's count_tokens endpoint is free and returns the input token count for a request against the model you name, so you can take a sample of real cases from the queue you intend to automate, measure tokens per case, multiply by turns per case, and only then apply the published rate.
Are Claude seats cheaper than the Claude API?
They are not comparable, because they buy different things. Seats buy interactive use by a named person and cap at what one person can consume in a day. API usage buys automated work whose volume follows a process rather than a headcount. Most companies past pilot run both, and the common budgeting error is forecasting the second with a per-seat mental model.
Where does the money actually go once a Claude rollout passes pilot?
Rarely into tokens alone. The lines that grow after pilot are the evaluation and regression suite, the retrieval layer that supplies context, the identity and logging plumbing that makes the assistant auditable, and the engineering time to keep all three correct as models change. Those are the costs a pilot budget never contains.
Not a sales call. An architecture call.
Thirty minutes with the architect who would actually run the engagement.