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 Claude API (application programming interface) model prices are 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 of rates. Claude Haiku 5.5 carries two pairs: one for prompts up to 100,000 tokens and a higher one for prompts above that. As of October 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 glossary puts one token at roughly 3.5 English characters on models before Claude 4.7. Anthropic's model overview says one million tokens holds about 750,000 words on those models, and at 3.5 characters a token that is roughly 3.5 million characters, about 3.5 MB of plain English text. On the newer tokenizer introduced with Claude Opus 4.7, the same million tokens holds about 555,000 words, or roughly 2.5 million characters.

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 those word counts are 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",
    "input_usd": 2,
    "output_usd": 10
  },
  {
    "label": "Sonnet 4.6",
    "input_usd": 3,
    "output_usd": 15
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25
  }
]

Claude Sonnet 5 costs $2 input and $10 output. Anthropic first sold that price as an introductory rate through 31 August 2026, then made it the standard price and cancelled the planned rise to $3 and $15. Claude Opus 5 sits at $5 and $25. The Fable models sit above that chart entirely: Claude Fable 5 and the newer Claude Fable 5.1 both list at $10 input and $50 output, so whether those rates are worth paying depends on which jobs you actually point it at.

Anthropic's current lineup is newer than the models costed on this page. Claude Opus 5.5 lists at $4 input and $20 output, Claude Sonnet 5.5 at $2 and $10, and Claude Haiku 5.5 from $0.10 and $0.50. Opus 5, Sonnet 5, Haiku 4.5 and Fable 5 are now listed as legacy models that are still available, so the worked examples below still run as written. What Haiku 5.5 costs and where it fits covers the cheapest of the new models.

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

These rates say what Claude costs but not whether it is the cheaper option for your workload, and three jobs costed on both Claude and ChatGPT shows where each API comes out ahead.

One thing that does not change the rate is context length, with one exception. On Claude 4.6 and later models, except Claude Haiku 5.5, 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. Claude Haiku 5.5 is priced by prompt length instead: a request whose prompt is over 100,000 tokens pays $0.50 input and $2.50 output per million rather than $0.10 and $0.50, and cache reads and writes count toward that threshold.

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, October 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.

On the models in this page's price chart and worked examples (Haiku 4.5, Sonnet 5, Sonnet 4.6 and Opus 5), and on Fable 5, a cache read costs 0.1 times the base input rate. Some newer models charge less for a read: Opus 5.5 and Sonnet 5.5 charge 0.05 times, and Fable 5.1 and Mythos 5.1 charge 0.025 times. Writing the cache costs 1.25 times base for the 5 minute lifetime, or 2 times base for the 1 hour lifetime. So on the 0.1 times models 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 sent as base64 count correctly too. It rejects server tools such as web search and web fetch, and images or documents passed by URL or file reference. 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. Hitting a usage ceiling on a plan is usually what starts that question, and the routes out of a limit run from waiting out the window to moving that work onto metered API calls. 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 October 2026 one million input tokens costs $1 on Claude Haiku 4.5, $2 on Claude Sonnet 5, and $5 on Claude Opus 5. The newer Claude Haiku 5.5 starts at $0.10 per million input tokens for prompts up to 100,000 tokens, and charges $0.50 above that. Output costs five times the input rate on each of those models. 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. On models before Claude Opus 4.7, Anthropic puts one token at roughly 3.5 English characters and says one million tokens holds about 750,000 words. On the newer tokenizer that Claude Opus 4.7 and later use, one million tokens holds about 555,000 words, because that tokenizer produces roughly 30 percent more tokens for identical text than Claude Sonnet 4.6 and earlier. Those ratios are only a guide. Code, JSON and languages other than English use more tokens per word, and 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.