How much is 1M tokens in Claude?

How much is 1M tokens in Claude?

1M tokens means one million tokens, and it is the unit every Claude API (application programming interface) price is quoted in. There is no single price for it, because input and output are billed at different rates and each model carries its own pair. As of August 2026, one million input tokens costs $1 on Claude Haiku 4.5, $2 on Claude Sonnet 5 and $5 on Claude Opus 5.

Output is the expensive half. On every current model the output rate is five times the input rate, so the split between the two decides your bill more than the headline figure does. An app that sends long documents and returns short answers behaves very differently from one that writes long answers from a short prompt.

This page is unit economics: what a token costs, and how to estimate a bill before you build. For where the tokens actually go while you work, read where the tokens go inside a Claude Code session.

What 1M tokens looks like

A token is a chunk of text the model reads or writes. Anthropic's rough guide is one token per 4 characters, or about 0.75 words of English. One million tokens is therefore around 750,000 words, or roughly 4 MB of plain text.

Published estimates for common inputs give a better feel for the scale.

[
  {
    "label": "Average web page (10 kB)",
    "tokens": "2,500"
  },
  {
    "label": "Documentation page (100 kB)",
    "tokens": "25,000"
  },
  {
    "label": "Research paper PDF (500 kB)",
    "tokens": "125,000"
  }
]

At those rates, 1M tokens is about 400 average web pages read once, or eight research papers of that size. It is one pass over a mid-sized codebase, or a month of light chat use for one person.

Treat all of that as an estimate. Code, JSON and text in languages other than English pack fewer words into a token, so the 0.75 ratio is the optimistic end. One more thing shifts the count: Claude Opus 4.7 and later, which includes Opus 5 and Sonnet 5, use a newer tokenizer that produces roughly 30 percent more tokens for the same text than Sonnet 4.6 and earlier. Claude Haiku 4.5 uses the older tokenizer. So a count you measured on Haiku 4.5 understates the count on Sonnet 5 for identical input, which means a straight price-per-million comparison across that boundary is not fair. Count the same prompt against both models before you decide.

What Claude charges per million tokens

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug 2026)",
    "input_usd": 2,
    "output_usd": 10
  },
  {
    "label": "Sonnet 5 (from 1 Sep 2026)",
    "input_usd": 3,
    "output_usd": 15
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25
  }
]

Claude Sonnet 5 is on introductory pricing of $2 input and $10 output through 31 August 2026. From 1 September 2026 the standard rate applies: $3 input and $15 output. Claude Opus 5 sits at $5 and $25.

Rates move. Treat every figure on this page as a worked example dated August 2026, and confirm the current numbers on the official pricing page before you sign off a budget.

One thing that does not change the rate is context length. On Claude 4.6 and later the full 1M token context window is billed at standard pricing, so a 900,000 token request costs the same per token as a 9,000 token one. A long prompt costs more because it is more tokens, and no separate long-context rate applies.

The arithmetic that survives a price change

Every bill is two multiplications and one addition.

cost = (input_tokens  / 1,000,000) * input_rate
     + (output_tokens / 1,000,000) * output_rate

Written as code you can run:

INPUT_RATE = 2.00    # USD per million input tokens, Sonnet 5, August 2026
OUTPUT_RATE = 10.00  # USD per million output tokens

def cost(input_tokens, output_tokens):
    return (input_tokens * INPUT_RATE + output_tokens * OUTPUT_RATE) / 1_000_000

print(f"{cost(4300, 400):.4f}")

That prints 0.0126. A request that sends 4,300 input tokens and gets back 400 output tokens costs about 1.3 cents on Sonnet 5. Keep the two rates in one place in your code. When a price changes you edit two lines, and every estimate in your system moves with it.

A worked estimate for a real app

Take a support assistant. Its system prompt and product documentation come to 4,000 tokens, and they go out on every single request, because the Messages API is stateless and the model remembers nothing between calls. A user question adds about 300 tokens. An answer runs about 400. That is 4,300 input and 400 output per request.

One million input tokens buys about 232 requests of that shape. At 1,000 requests a day the app consumes 4.3 million input tokens daily, so "1M tokens" is under six hours of traffic.

[
  {
    "label": "Opus 5, list rates",
    "cost_per_1k_usd": "31.50"
  },
  {
    "label": "Sonnet 5, list rates",
    "cost_per_1k_usd": "12.60"
  },
  {
    "label": "Sonnet 5, Batch API",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Haiku 4.5, list rates",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Sonnet 5, warm prompt cache",
    "cost_per_1k_usd": "5.40"
  }
]

On Claude Opus 5 that traffic costs $31.50 per 1,000 requests. On Sonnet 5 it is $12.60. Dropping to Claude Haiku 4.5 brings it to $6.30, and a warm prompt cache on Sonnet 5 goes lower still at $5.40.

Multiply by 30 for a month of that traffic. Sonnet 5 at list rates is about $378 a month. The same app with a warm cache is about $162. Your model choice and your caching decision are each worth more than any rate you will negotiate at this volume. Which model to run is its own question, and the cheapest one that passes your evaluations wins: choosing between Opus, Sonnet and Haiku covers how to test that properly.

Prompt caching cuts the repeated part

That 4,000 token prefix is identical on every request, and you pay full input price for it every time. Prompt caching stores the processed prefix and charges a reduced rate to reuse it.

A cache read costs 0.1 times the base input rate. Writing the cache costs 1.25 times base for the 5 minute lifetime, or 2 times base for the 1 hour lifetime. So the 5 minute cache pays for itself after one read, because the write costs 0.25 extra while each read saves 0.9. The 1 hour cache needs two reads to break even.

The simplest way to turn it on is a single top-level field:

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "You are a helpful assistant.",
    "messages": [
      {"role": "user", "content": "What are the key themes in Pride and Prejudice?"}
    ]
  }'

Then read the usage block that comes back:

{
  "usage": {
    "cache_creation_input_tokens": 5120,
    "cache_read_input_tokens": 1800,
    "input_tokens": 50,
    "output_tokens": 503
  }
}

Those three input counters are billed at three different rates and they sum to your real input volume: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. A cost estimate that reads only input_tokens will be badly wrong once caching is on.

Two things stop a cache from paying off, and both fail silently.

The prefix must be byte-identical. Cache lookup is a prefix match, so a timestamp or the user's name at the top of your system prompt changes it on every request. You then pay 1.25 times base input every time and never read once. The symptom is cache_creation_input_tokens staying high while cache_read_input_tokens stays 0. Place cache_control on the last block whose content is the same across requests, and put everything that varies after it. Changing your tools definitions invalidates the whole cache below them, because invalidation runs down the order tools, then system, then messages.

The prefix must be long enough. The minimum cacheable length is 512 tokens on Opus 5, 1,024 on Sonnet 5 and 4,096 on Haiku 4.5. A shorter prompt is not cached and no error is returned. The 4,000 token prefix in the example above caches on Sonnet 5 and does not cache on Haiku 4.5, because 4,000 is under that model's floor. When both counters read 0, nothing was cached.

Batch processing halves the rate

The Batch API processes requests asynchronously at 50 percent off both input and output. In the example above that turns $12.60 per 1,000 requests into $6.30. The discount stacks with prompt caching, so a cached batch job is the cheapest way to run bulk work.

What you give up is latency, which makes batch wrong for anything a person is sitting and waiting for. It fits overnight classification and document backfills.

Why chat costs grow inside one conversation

Because the API keeps no state, your client resends the whole conversation on every turn. Token usage inside one chat therefore grows with the square of its length, not in a straight line.

Take turns that average 500 tokens. Turn 1 sends 500 input tokens. Turn 2 sends 1,000. Turn 20 sends 10,000. Sum that with n(n+1)/2 and a 20 turn conversation has sent about 105,000 input tokens, while the transcript itself is only 10,000 tokens long.

That is why a chat feature costs more than its transcript suggests, and why caching the stable prefix or summarising older turns pays for itself on long threads. An agent that loops over tool calls has the same shape, and worse: every tool result stays in the history and is resent on every later turn. Putting a hard spending limit on an agent you run yourself matters most here, because that growth is automatic and nobody is watching it.

Count the tokens before you guess

Stop deriving token counts from word counts. The API counts them for you, at no charge, on a rate limit separate from message creation.

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

The response holds one field:

{ "input_tokens": 14 }

Feed it your real system prompt and tool definitions, with a representative user message, then put the number into the cost function above. The endpoint takes the same body as a message request, so images and PDFs count correctly too. Two caveats matter. The count is an estimate and can differ slightly from the billed figure. It is also measured with the tokenizer of the model you pass, so pass the model you will actually run.

Output tokens cannot be counted in advance, because they do not exist yet. Cap them with max_tokens, then measure the real distribution from usage.output_tokens on live traffic.

What else lands on the bill

Tokens are most of the bill. A few items are not tokens, and they surprise people.

• Tool definitions become input tokens on every request. The tool use system prompt alone adds 286 to 406 tokens on Opus 5, before your own schemas. Ten verbose tool descriptions can double a small prompt.
• Web search is charged at $10 per 1,000 searches, on top of the tokens the results consume when they enter the context.
• Web fetch adds no fee of its own, but the fetched page becomes input tokens. A 100 kB documentation page is roughly 25,000 of them.
• Asking for US-only inference with inference_geo on Claude 4.6 and later applies a 1.1 multiplier to every token category, cache reads and writes included.

Whether the API is the right thing to buy at all depends on your volume. Below a certain level of use a flat monthly plan wins outright, and the API measured against a Claude subscription runs that comparison with real numbers.

FAQ

How much does 1M tokens cost in Claude?

It depends on the model, and on whether the tokens are input or output. As of August 2026 one million input tokens costs $1 on Claude Haiku 4.5, $2 on Claude Sonnet 5 under introductory pricing, and $5 on Claude Opus 5. Output costs five times the input rate on each of those models. Sonnet 5 moves to $3 input and $15 output on 1 September 2026. Rates change, so confirm them on the official pricing page before you commit a figure to a budget.

Is 1M tokens the same as 1M words?

No. One token is roughly 4 characters of English, or about 0.75 words, so one million tokens is around 750,000 words. That ratio is only a guide. Code, JSON and languages other than English use more tokens per word. Claude Opus 4.7 and later also use a newer tokenizer that produces roughly 30 percent more tokens for identical text than Claude Sonnet 4.6 and earlier, so counts are not portable between model generations. Measure with the free /v1/messages/count_tokens endpoint, passing the model you plan to run.

Does prompt caching always save money?

No. A 5 minute cache write costs 1.25 times the base input rate, so a prefix that is written and never read costs 25 percent more than sending it plainly. It pays for itself from the first read. It fails in two ways, both silent. If the cached prefix changes between requests, the lookup never matches, because it is an exact prefix match. If the prefix is shorter than the model's minimum cacheable length, which is 1,024 tokens on Sonnet 5 and 4,096 on Haiku 4.5, nothing is cached and no error is returned. When cache_creation_input_tokens and cache_read_input_tokens both read 0, the cache is doing nothing.

Why did my bill grow faster than my message count?

Because the whole conversation is resent on every turn. The Messages API holds no state, so turn 20 of a chat carries all 19 earlier turns as input again. With turns averaging 500 tokens, a 20 turn conversation sends about 105,000 input tokens while the transcript is only 10,000 tokens long. Agent loops behave the same way, since every tool result stays in the history. Cache the stable prefix, or summarise older turns and drop them from the request.