Why is Claude so expensive? The token math

Why is Claude expensive? The short answer

Claude is expensive for four reasons that stack on top of each other. Output tokens are priced at five times the rate of input tokens. The API keeps no memory of your conversation, so the whole history is sent again and billed again on every turn. An agent turns one question into dozens of API calls, and each call carries that growing history. On top of all that, the frontier model is priced against the difficulty of the work it does, not against the cost of running a small model.

A token is a piece of text. As a rough guide, one token is about four characters, or about 0.75 words of English. Rates are quoted per million tokens, written MTok (million tokens). Every rate below is the published Claude API rate as of August 2026.

Most surprise bills come from the second and third reasons on that list. People usually arrive believing the answers Claude writes are what costs money. In an agent session, the writing is often less than one tenth of the bill.

The published rates, so we agree on the numbers

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "cache_read_usd": "0.10"
  },
  {
    "label": "Sonnet 5, to Aug 31 2026",
    "input_usd": 2,
    "output_usd": 10,
    "cache_read_usd": "0.20"
  },
  {
    "label": "Sonnet 5, from Sep 1 2026",
    "input_usd": 3,
    "output_usd": 15,
    "cache_read_usd": "0.30"
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25,
    "cache_read_usd": "0.50"
  }
]

Look at the shape rather than the absolute numbers. Every model charges exactly five times more for output than for input. Opus 5 costs 5 dollars per million input tokens and 25 dollars per million output tokens. Haiku 4.5 costs 1 and 5. So the distance from the cheapest model to the most expensive one is five times, and the distance from reading to writing is also five times.

Sonnet 5 sits at introductory pricing of 2 and 10 dollars per million through August 31, 2026. From September 1, 2026 it moves to 3 and 15. Rates move with model releases, so check the current ones before you build a budget on them.

The last column is the cache read rate. It decides most bills. Come back to it after the arithmetic.

Why do output tokens cost five times input tokens?

Reading and writing are not the same amount of work. Input tokens are processed in one pass. The model reads the whole prompt at once and the work runs in parallel across it, which is why a 60,000 token prompt does not take 60,000 times longer to read than a 1,000 token prompt.

Output tokens are produced one at a time. Each new token needs its own pass through the model, and it needs every token before it as context. Writing 1,000 tokens means 1,000 passes, one after another. That serial work cannot be spread out the way reading can, so each output token holds the hardware for longer.

This is why "make the answer shorter" is a weaker lever than people expect. It works on the smaller half of an agent bill.

Why is my whole conversation billed again on every turn?

The Claude API is stateless. There is no conversation sitting on Anthropic's side that you are adding one message to. Each request carries the entire message history, and the model reads all of it before writing anything. So turn 30 is billed for turns 1 through 29 as well.

That means the cost of a conversation grows faster than its length. Turn 1 bills a small context. Turn 40 bills a large one. Add up all forty turns and you have paid for many times the number of tokens that were ever written.

[
  {
    "turn": 1,
    "context_tokens": "20,000"
  },
  {
    "turn": 5,
    "context_tokens": "32,000"
  },
  {
    "turn": 10,
    "context_tokens": "45,000"
  },
  {
    "turn": 15,
    "context_tokens": "55,000"
  },
  {
    "turn": 20,
    "context_tokens": "64,000"
  },
  {
    "turn": 25,
    "context_tokens": "74,000"
  },
  {
    "turn": 30,
    "context_tokens": "84,000"
  },
  {
    "turn": 35,
    "context_tokens": "92,000"
  },
  {
    "turn": 40,
    "context_tokens": "100,000"
  }
]

The session above starts at 20,000 tokens, which is the system prompt, the tool definitions and the first files the agent opened. By turn 40 the context holds 100,000 tokens. Average that across all forty turns and you get roughly 60,000 tokens read per request.

Why does an agent cost so much more than a chat?

A chat is one request per question. An agent is one request per step. Reading a file is a step. Running a test is a step. Reading the test output is a step. Editing the file is a step. Forty steps to finish one task is ordinary for a coding agent.

Two extra costs ride along with tool use. The tool definitions are input tokens on every single request, because the model has to be told what tools exist each time. Anthropic publishes the overhead: the tool use system prompt is 286 tokens on Opus 5 with tool_choice set to auto, plus the tokens of your own tool schemas. Some server-side tools carry a separate fee as well. Web search is billed at $10 per 1,000 searches on top of the tokens the results consume.

Every tool result is also permanent context. A command that prints 3,000 lines puts those 3,000 lines into every request for the rest of the session. The per-session token usage that Claude Code reports makes this visible: watch the input number climb right after a noisy command.

The arithmetic on one real session

Here is a realistic hour of agentic coding on Opus 5. Forty API requests. The context grows from 20,000 to 100,000 tokens, so it averages about 60,000 tokens per request. The model writes about 700 tokens per request, which is a mix of short tool calls and a few longer blocks of code.

Requests in the session:      40
Average context per request:  60,000 tokens

Total input tokens billed:    40 x 60,000                    = 2,400,000
Input cost on Opus 5:         2,400,000 x $5 / 1,000,000     = $12.00

Total output tokens:          40 x 700                       =    28,000
Output cost on Opus 5:        28,000 x $25 / 1,000,000       =  $0.70

Session total                                                = $12.70

[
  {
    "label": "Input, context re-read",
    "billed_tokens": "2,400,000",
    "cost_usd": "12.00"
  },
  {
    "label": "Output, code and tool calls",
    "billed_tokens": "28,000",
    "cost_usd": "0.70"
  }
]

Look at the split. Reading cost 12.00 dollars and writing cost 0.70 dollars, so the output you actually read is about five percent of the bill. The model wrote 28,000 tokens and was billed for reading 2,400,000. Nobody typed 2.4 million tokens. The same 100,000 tokens were read over and over.

Lever 1: prompt caching, which is the largest one

Prompt caching stores the processed form of a stable prefix of your prompt. On the next request that prefix is read from cache instead of being processed again. Writing to the cache costs 1.25 times the input rate for the five minute cache, or 2 times for the one hour cache. Reading from it costs 0.1 times the input rate. On Opus 5 that is 0.50 dollars per million instead of 5 dollars.

Apply that to the session above. Each of the 100,000 tokens is written to the cache once as the conversation grows. The other 2,300,000 input tokens become cache reads.

Tokens written to cache:      100,000
Cache write at 1.25x input:   100,000 x $6.25 / 1,000,000    = $0.63

Tokens read from cache:       2,300,000
Cache read at 0.1x input:     2,300,000 x $0.50 / 1,000,000  = $1.15

Output cost, unchanged                                       = $0.70

Session total                                                = $2.48

You mark the cacheable part with a cache_control field. Put the breakpoint after the content that does not change between turns: the system prompt and the tool definitions. A long document you keep referring to belongs in that same stable block.

{
  "model": "claude-opus-5",
  "system": [
    {
      "type": "text",
      "text": "<long, stable instructions>",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "..."}]
}

The order of your prompt now decides money. A cache hit needs an exact match from the very start of the prompt, so anything that changes on every request has to sit after everything that does not. Put a timestamp at the top of your system prompt and you break the cache on every turn: the whole prefix becomes a miss, and you pay 1.25 times the input rate to write it again.

The response tells you whether it worked. Send a request and read the usage block.

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 256,
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Every response carries a usage object like this one:

{
  "usage": {
    "input_tokens": 105,
    "cache_creation_input_tokens": 7345,
    "cache_read_input_tokens": 7123,
    "output_tokens": 239
  }
}

A repeat request that still shows 0 in cache_read_input_tokens means the cache is not being hit. The usual cause is that something before your breakpoint changed. The five minute cache also expires, so a request sent six minutes later is a miss followed by a fresh write.

Lever 2: send the easy turns to a smaller model

Most turns in an agent session are not hard. Opening a file, running a formatter, reading a diff. Those do not need the frontier model. Routing them to Haiku 4.5 moves the input rate from 5 dollars per million down to 1.

[
  {
    "label": "Opus 5, no caching",
    "session_cost_usd": "12.70"
  },
  {
    "label": "Opus 5, cached",
    "session_cost_usd": "2.48"
  },
  {
    "label": "Sonnet 5, cached",
    "session_cost_usd": "0.99"
  },
  {
    "label": "Haiku 4.5, cached",
    "session_cost_usd": "0.50"
  }
]

The same session costs 12.70 dollars on Opus 5 with no caching, 2.48 with caching, 0.99 on Sonnet 5 with caching, and 0.50 on Haiku 4.5 with caching. Caching alone removes about eighty percent of the bill. Model choice removes most of what is left.

Here is the honest caveat. A cheaper model that gets the answer wrong costs you the whole session again, plus your own time. Route by how hard the task is, not by price. The rule cuts upward too: Claude Fable 5 lists above Opus 5 at $10 and $50 per million, so read what those rates buy you before you send a turn there. Choosing between Opus, Sonnet and Haiku goes through where each one holds up.

Lever 3: context hygiene

Every token you leave in the context is billed on every remaining turn, so removing a token early is worth far more than removing it late. A 5,000 token file dumped in at turn 5 of a 40 turn session is read 35 more times. That is 175,000 extra input tokens, which is almost a dollar on Opus 5 for one careless paste.

Four habits that move the number:

• Start a fresh session for a new task instead of continuing yesterday's.
• Filter noisy commands before the output reaches the model, with something like head -50, rather than after.
• Ask for the one function you care about, not the whole file.
• When a long session stops making progress, ask for a summary and start again from it. The summary is a few hundred tokens. The transcript is a hundred thousand.

Lever 4: batch anything that is not interactive

The Batch API processes requests asynchronously and takes 50 percent off both input and output. If a job does not need an answer in the next second, batch it. That covers classification, extraction, summarising a backlog, and evaluation runs. The batch discount stacks with prompt caching. It does not apply to an interactive session, because there is nothing there to wait for.

Am I being ripped off?

That is the real question sitting under "why is Claude expensive", so here is a straight answer. The rates are published, they are the same for everyone on the standard tiers, and they are charged per token. Nothing in the bill is discretionary. What the rate card cannot tell you is whether you are getting value, because it prices tokens and you care about outcomes.

So price the outcome instead. The session above cost 12.70 dollars uncached. If it shipped a feature that would have taken you an hour, that is cheap. If it spent forty turns going in a circle, the same 12.70 dollars bought nothing, and the rate was never the problem.

This is the part worth remembering. Your bill scales with tokens, not with value. A productive session and a wasted session at the same length cost the same. That is why the four levers matter more than the rate card: you cannot negotiate the price per token, but you decide how many tokens the job takes.

So track dollars per completed task, not dollars per month. If that number falls while you tune caching and routing, your setup is improving even when the monthly total rises, because the total is rising from doing more work.

What does not lower your bill

Some popular advice does very little. Telling the model to "be concise" trims output, and output was five percent of the example bill. Shortening your own question saves a few hundred tokens against a 60,000 token context. Turning off extended thinking helps only where thinking tokens were a real share of your output, and the usage block tells you that instead of leaving you to guess.

A bigger context window is not itself a cost either. On Claude 4.6 and later, the full one million token window is billed at the standard per-token rate, so a 900,000 token request costs the same per token as a 9,000 token one. The window size does not set the price. What you choose to put in the window does.

Two more things belong in planning rather than in a single session. If your use is daily and interactive, compare pay per token against a flat plan: the API and subscription cost comparison does that sum. And if an agent runs unattended on a server, set a hard spend cap before you tune anything else, which is what cost controls for an AI agent on a VPS covers. For a plain sense of scale, what one million Claude tokens actually buys turns the rate card into pages of text.

FAQ

Why did my Claude bill jump when I started using an agent?

Because an agent sends many requests per question, and every request carries the whole conversation so far. A chat sends one request per question. A coding agent sends one request per step, and forty steps for one task is normal. Each of those requests is billed for the full context, so a session that ends at 100,000 tokens can be billed for over two million input tokens in total. Read input_tokens and cache_read_input_tokens in the API response to see it directly.

Does prompt caching really cut the bill that much?

In the worked example it took the session from 12.70 dollars to 2.48 dollars, because a cache read costs one tenth of the input rate. The saving depends entirely on your hit rate. With the five minute cache it pays for itself after a single read, since the write costs 1.25 times input and the read costs 0.1 times. If your prompt changes near the start on every request, you get no hits at all and you pay the write premium for nothing. Confirm with cache_read_input_tokens before you assume it is working.

Should I just use Haiku for everything?

No. Haiku 4.5 costs 1 dollars per million input tokens against 5 for Opus 5, so the saving is real on simple high volume work such as classification and routing. A wrong answer on hard work costs more than the model saved, because you pay for the retry and for your own time on top. The pattern that holds up is mixed: the small model for mechanical turns, the frontier model for the turn that needs judgement.

Is the API cheaper than a Claude subscription?

It depends on how steady your usage is. A subscription is a fixed monthly price with usage limits attached. The API is pay per token with no ceiling, which is cheaper when your usage is light or comes in bursts, and more expensive when you use it heavily every working day. Take your average tokens per day from the usage block, price them at your model's rate, then compare that figure against the plan price.