How much 1M tokens dey cost for Claude?

How much be 1M tokens for Claude?

1M tokens mean one million tokens, and na be the unit wey every Claude API (application programming interface) price dey use. No be one single price, because input and output dey get different rates, and each model get its own pair. As of August 2026, one million input tokens cost $1 for Claude Haiku 4.5, $2 for Claude Sonnet 5, and $5 for Claude Opus 5.

Output na the expensive part. For every current model, output rate na five times input rate, so how you split the two go affect your bill pass the headline figure. App wey dey send long documents and return short answers go behave very differently from one wey dey write long answers from short prompt.

This page na about unit economics: wetin one token cost, and how to estimate bill before you build. For where the tokens actually dey go as you dey work, read where tokens dey go inside Claude Code session.

Wetin 1M tokens dey look like

A token na small piece of text wey model dey read or write. Anthropic rough guide be say one token na every 4 characters, or about 0.75 English words. So, one million tokens na around 750,000 words, or roughly 4 MB of plain text.

Published estimates for common inputs give better idea of the size.

[
  {
    "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"
  }
]

With those rates, 1M tokens na about 400 average web pages wey person read once, or eight research papers of that size. E fit be one pass over a mid-sized codebase, or one month of light chat use for one person.

Treat all of this as estimate. Code, JSON and text for languages wey no be English dey pack fewer words inside one token, so the 0.75 ratio na the optimistic end. Another thing dey change the count: Claude Opus 4.7 and later, including Opus 5 and Sonnet 5, dey use newer tokenizer wey produces roughly 30 percent more tokens for the same text than Sonnet 4.6 and earlier. Claude Haiku 4.5 dey use the older tokenizer. So, count wey you measure for Haiku 4.5 go understate the count for Sonnet 5 when input dey identical. That means straight price-per-million comparison across that boundary no fair. Count the same prompt against both models before you decide.

Claude dey charge how much for every 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 dey use introductory pricing of $2 for input and $10 for output reach 31 August 2026. From 1 September 2026, standard rate go apply: $3 for input and $15 for output. Claude Opus 5 dey cost $5 and $25.

Rates fit change. Treat every figure for this page as worked example wey get August 2026 date, and confirm the current numbers for the official pricing page before you approve budget.

Context length no dey change the rate. For Claude 4.6 and later, dem dey bill the complete 1M token context window with standard pricing. So, 900,000 token request cost the same per token as 9,000 token request. Long prompt cost more because e get more tokens, and no separate long-context rate dey apply.

The arithmetic wey dey survive price change

Every bill na two multiplications plus one addition.

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

Write am as code wey you fit 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 one go print 0.0126. Request wey send 4,300 input tokens and collect 400 output tokens back go cost about 1.3 cents for Sonnet 5. Keep the two rates for one place inside your code. When price change, edit two lines, and every estimate for your system go change with am.

Real app estimate wey dem don work out

Take support assistant for example. Its system prompt and product documentation together na 4,000 tokens. Dem dey go with every request because Messages API no dey keep state, and model no remember anything between calls. User question dey add about 300 tokens. Answer dey use about 400. So each request get 4,300 input tokens and 400 output tokens.

One million input tokens fit cover about 232 requests of this kind. If app dey receive 1,000 requests every day, e dey use 4.3 million input tokens daily. So “1M tokens” no reach 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"
  }
]

For Claude Opus 5, this traffic cost $31.50 per 1,000 requests. For Sonnet 5, na $12.60. If you reduce am to Claude Haiku 4.5, e go cost $6.30, and warm prompt cache for Sonnet 5 go reduce am further to $5.40.

Multiply am by 30 for one month of this traffic. Sonnet 5 at list rates na about $378 every month. The same app with warm cache na about $162. Your model choice and caching decision each get more value than any rate wey you fit negotiate at this traffic volume. Which model to run na another question. The cheapest one wey passes your evaluations na the winner: how to choose between Opus, Sonnet and Haiku explains how to test am properly.

Prompt caching dey cut the repeated part

That 4,000 token prefix dey identical for every request, and you dey pay full input price for am every time. Prompt caching dey store the processed prefix and charge reduced rate when e reuse am.

Cache read cost na 0.1 times the base input rate. Cache writing cost na 1.25 times base for the 5 minute lifetime, or 2 times base for the 1 hour lifetime. So the 5 minute cache don pay for itself after one read, because the write cost 0.25 extra while each read dey save 0.9. The 1 hour cache need two reads to break even.

The simplest way to turn am on na one 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 wey come back:

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

Those three input counters dey billed at three different rates and dem add up to your real input volume: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Cost estimate wey read only input_tokens go dey badly wrong once caching dey on.

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

The prefix must be byte-identical. Cache lookup na prefix match, so timestamp or the user's name for the top of your system prompt go change am for every request. Then you go pay 1.25 times base input every time and never read even once. The symptom na cache_creation_input_tokens staying high while cache_read_input_tokens stay 0. Put cache_control on the last block wey content dey the same across requests, and put everything wey dey change after am. If you change your tools definitions, e go invalidate the whole cache below dem, because invalidation dey run down the order tools, then system, then messages.

The prefix must be long enough. The minimum cacheable length na 512 tokens for Opus 5, 1,024 for Sonnet 5 and 4,096 for Haiku 4.5. If prompt short pass that, dem no go cache am and no error go return. The 4,000 token prefix for the example above dey cache for Sonnet 5 but e no dey cache for Haiku 4.5, because 4,000 dey under that model's floor. When both counters read 0, nothing dey cached.

Batch processing dey cut rate for half

Batch API dey process requests asynchronously, and e dey give 50 percent discount for both input and output. For the example wey dey above, e dey turn $12.60 for every 1,000 requests to $6.30. This discount fit join with prompt caching, so cached batch job na the cheapest way to run plenty work.

Wetin you sacrifice na latency. Na why batch no good for anything wey person dey wait for. E fit well for classification wey run overnight and document backfills.

Why chat cost dey grow inside one conversation

Because API no dey keep state, your client dey resend the whole conversation for every turn. So token usage inside one chat dey grow according to the square of the chat length, no be straight line.

Assume say each turn get average of 500 tokens. Turn 1 send 500 input tokens. Turn 2 send 1,000. Turn 20 send 10,000. If you add am with n(n+1)/2, one 20 turn conversation don send about 105,000 input tokens, while the transcript itself na only 10,000 tokens long.

Na why chat feature fit cost pass wetin the transcript dey show. Na also why caching the stable prefix or summarising older turns dey pay for itself for long threads. Agent wey dey loop over tool calls get the same pattern, and e fit worse: every tool result dey remain for the history and API dey resend am for every later turn. Putting a hard spending limit on an agent you run yourself matter pass for here, because that growth dey happen automatically and nobody dey monitor am.

Count the tokens before you guess

No dey calculate token count from word count again. The API dey count am for you at no extra charge, with rate limit wey 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 get one field:

{ "input_tokens": 14 }

Send your real system prompt and tool definitions, together with one representative user message, then put the number inside the cost function above. The endpoint dey use the same body as message request, so images and PDFs go count correctly too. Two things important. The count na estimate, and e fit differ small from the amount wey dem bill. The count also dey use the tokenizer for the model wey you pass, so pass the model wey you actually go run.

You no fit count output tokens beforehand because dem never exist yet. Use max_tokens to cap dem, then measure the real distribution from usage.output_tokens for live traffic.

Wetin else dey add to bill

Tokens na most of the bill. But some items no be tokens, and dem dey surprise people.

• Tool definitions become input tokens for every request. The tool use system prompt alone adds 286 to 406 tokens on Opus 5, before your own schemas. Ten tool descriptions wey too long fit double small prompt.
• Web search dey cost $10 for every 1,000 searches, on top of the tokens wey the results use when dem enter the context.
• Web fetch no get separate fee, but the page wey e fetch becomes input tokens. A 100 kB documentation page na roughly 25,000 of dem.
• To ask for US-only inference with inference_geo on Claude 4.6 and later dey apply 1.1 multiplier to every token category, including cache reads and writes.

Whether API na the correct thing to buy at all depend on your volume. Below one level of use, flat monthly plan fit win completely, and API compared with Claude subscription dey run that comparison with real numbers.

FAQ

1M tokens dey cost how much for Claude?

E depend on the model, and whether the tokens na input or output. As of August 2026, one million input tokens dey cost $1 for Claude Haiku 4.5, $2 for Claude Sonnet 5 under introductory pricing, and $5 for Claude Opus 5. Output cost five times the input rate for each of those models. Sonnet 5 go change to $3 input and $15 output on 1 September 2026. Rates dey change, so confirm them for the official pricing page before you put any figure for budget.

1M tokens na the same thing as 1M words?

No. One token na roughly 4 characters of English, or about 0.75 words, so one million tokens na around 750,000 words. That ratio na only guide. Code, JSON and languages wey no be English dey use more tokens per word. Claude Opus 4.7 and later versions also use newer tokenizer wey dey produce roughly 30 percent more tokens for the same text than Claude Sonnet 4.6 and earlier versions. So token counts no dey portable between model generations. Measure am with the free /v1/messages/count_tokens endpoint, and pass the model wey you plan to run.

Prompt caching always dey save money?

No. A 5 minute cache write cost 1.25 times the base input rate. So if you write a prefix and never read am, e go cost 25 percent more than sending am normally. E pays for itself from the first read. E fit fail in two ways, and both failures happen silently. If the cached prefix change between requests, the lookup no go match because e must be an exact prefix match. If the prefix short pass the model minimum cacheable length, wey be 1,024 tokens for Sonnet 5 and 4,096 for Haiku 4.5, nothing go cache and no error go return. When cache_creation_input_tokens and cache_read_input_tokens both read 0, the cache no dey do anything.

Why my bill grow faster than my message count?

Because the whole conversation dey resend for every turn. The Messages API no dey hold state, so turn 20 of a chat carries all 19 earlier turns as input again. If turns average 500 tokens, one 20 turn conversation sends about 105,000 input tokens, while the transcript na only 10,000 tokens long. Agent loops dey behave the same way because every tool result remains for the history. Cache the stable prefix, or summarise older turns and remove them from the request.