1M tokens for Claude cost wetin exactly

How much be 1M tokens for Claude?

1M tokens mean one million tokens, and na the unit wey every Claude API (application programming interface) price dey use. No be one fixed price, because input and output get different rates, and every 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 side. For every current model, output rate na five times the input rate. So, the split between input and output dey affect your bill pass the headline figure. App wey dey send long documents and return short answers go behave very differently from app wey dey write long answers from short prompt.

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

Wetin 1M tokens look like

A token na one chunk of text wey model dey read or write. Anthropic rough guide be say one token dey equal about 4 characters, or around 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 go make the scale easier to understand.

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

For those rates, 1M tokens na about 400 average web pages if you read each one once, or eight research papers of that size. E fit cover one complete pass over a medium-sized codebase, or one month of light chat use for one person.

Take all of this as estimate. Code, JSON, and text for languages wey no be English dey pack fewer words into one token, so 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 with identical input. This means say direct price-per-million comparison across that boundary no fair. Count the same prompt against both models before you decide.

Wetin Claude dey charge 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 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 for input and $25 for output.

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

One thing wey no change the rate na context length. For Claude 4.6 and later, dem dey bill the full 1M token context window with standard pricing, so request wey get 900,000 tokens costs the same per token as one wey get 9,000 tokens. Long prompt costs more because e get more tokens, and no separate long-context rate dey apply.

Arithmetic wey go still work even when 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}")

E go print 0.0126. Request wey send 4,300 input tokens and receive 400 output tokens go cost about 1.3 cents for Sonnet 5. Keep the two rates for one place inside your code. When price change, you go edit two lines, and every estimate for your system go change with am.

Estimate wey work for real app

Take support assistant. E system prompt and product documentation together na 4,000 tokens, and dem dey go with every request because Messages API stateless and model no dey 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 handle 1,000 requests every day, e go consume 4.3 million input tokens daily. So "1M tokens" no go 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, while warm prompt cache for Sonnet 5 go reduce the cost further to $5.40.

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

Prompt caching repeated part wey dey cut cost

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 lower 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 every read dey save 0.9. The 1 hour cache need two reads to break even.

The easiest 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 seriously wrong once caching don turn on.

Two things fit stop cache from paying off, and both of dem 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 get even one read. The symptom na cache_creation_input_tokens staying high while cache_read_input_tokens stay 0. Put cache_control for the last block wey content dey the same across requests, then put everything wey dey vary after am. If you change your tools definitions, e invalidate the whole cache below dem, because invalidation dey run according to this 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. Prompt wey short pass this no dey cached, and e no return any error. 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 below that model's minimum. When both counters read 0, nothing dey cached.

Batch processing dey cut rate by half

Batch API dey process requests asynchronously with 50 percent discount for both input and output. For the example wey dey above, this turn $12.60 per 1,000 requests into $6.30. The discount fit combine with prompt caching, so cached batch job na the cheapest way to run bulk work.

The thing wey you sacrifice na latency. Because of this, batch no fit work for anything wey person dey wait for. E fit work for overnight classification and document backfills.

Wetin make chat cost dey grow inside one conversation

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

Make we use turns wey average 500 tokens. Turn 1 send 500 input tokens. Turn 2 send 1,000. Turn 20 send 10,000. If you sum am with n(n+1)/2, 20-turn conversation don send about 105,000 input tokens, even though the transcript itself na only 10,000 tokens long.

Na why chat feature fit cost pass wetin the transcript show, and why caching the stable prefix or summarising older turns dey pay for itself for long threads. Agent wey dey loop through tool calls get the same pattern, and e worse: every tool result remain for the history and dey resend 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 token before you guess

Make you stop dey derive token count from word count. The API fit count am for you at no extra cost, 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 }

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

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

Bill dey come from wetin else

Tokens na the main part of the bill. But some charges 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 for Opus 5, before your own schemas join. Ten tool descriptions wey too long fit double small prompt.
• Web search cost $10 for every 1,000 searches. This one dey 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. Documentation page wey get 100 kB roughly get 25,000 of dem.
• If you request US-only inference with inference_geo for Claude 4.6 and later, e go 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 usage volume. If your usage dey below one level, flat monthly plan fit win completely, and API compared with Claude subscription dey run that comparison with real numbers.

FAQ

How much does 1M tokens cost in Claude?

E depend on the model, and whether the tokens na input or output. As of August 2026, one million input tokens 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 these models. Sonnet 5 go move to $3 input and $15 output on 1 September 2026. Rates dey change, so confirm dem 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 for 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 counts no 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 prefix wey dem write but never read cost 25 percent more than sending am normally. E pay for itself from the first read. E fit fail in two ways, and both happen silently. If the cached prefix change between requests, the lookup no go match because na 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, cache no dey do anything.

Why my bill grow pass my message count?

Because the whole conversation dey resend for every turn. Messages API no dey hold state, so turn 20 of a chat carry all the 19 earlier turns as input again. If turns dey average 500 tokens, one 20 turn conversation send about 105,000 input tokens, even though the transcript only get 10,000 tokens. Agent loops behave the same way because every tool result remain for the history. Cache the stable prefix, or summarise older turns and remove dem from the request.