How Much 1M Tokens Cost for Claude?

How much 1M tokens dey cost 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 dem dey bill input and output with different rates, and each model get im 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 both of dem affect your bill pass the main price figure. App wey dey send long documents and return short answers go behave very different 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 your bill before you build. If you wan know where the tokens dey go while you dey work, read where the tokens dey go inside one 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 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 dey 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"
  }
]

For 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 through 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 fit 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 mean say direct price-per-million comparison across that boundary no fair. Count the same prompt against both models before you decide.

Claude dey charge how much 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 until 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. One model dey above this chart completely: Claude Fable 5 get price of $10 for input and $50 for output, so whether those rates worth the money depend on the kind work wey you actually give am.

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

These rates show how much Claude cost, but dem no show whether e be the cheaper option for your workload. Three jobs wey we price for both Claude and ChatGPT show where each API come out cheaper.

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

Arithmetic wey go still work after price change

Every bill na two multiplications and 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 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 update with am.

Estimate wey work for real app

Make we take support assistant. Its system prompt and product documentation total 4,000 tokens, and dem dey send am for every request because Messages API dey stateless and model no dey remember anything between calls. User question add about 300 tokens. Answer dey around 400 tokens. So each request get 4,300 input tokens and 400 output tokens.

One million input tokens fit pay for about 232 requests of this kind. If app dey handle 1,000 requests every day, e dey use 4.3 million input tokens daily. So “1M tokens” na less than 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 switch to Claude Haiku 4.5, e go drop to $6.30, while warm prompt cache for Sonnet 5 go reduce am 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. Your model choice and caching decision each get more effect than any rate wey you fit negotiate at 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 dey cut 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 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 each read 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 bill 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 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 am even once. The symptom na cache_creation_input_tokens staying high while cache_read_input_tokens dey 0. Put cache_control for 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 invalidate the whole cache below dem, because invalidation dey follow 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 shorter no dey cache, 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 above, this one reduce $12.60 per 1,000 requests to $6.30. This discount fit join with prompt caching, so cached batch job na the cheapest way to run bulk work.

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

Wetin make chat cost 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 its 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 add am with n(n+1)/2, conversation wey get 20 turns 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 transcript suggest, 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 history and dem resend am for every later turn. To put hard spending limit on agent wey you run yourself matter pass for here, because that growth dey happen automatically and nobody dey monitor am.

Count tokens before you guess

Stop dey derive token count from word count. API dey count dem 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 }

Feed 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 matter. The count na estimate, and e fit differ small from the amount wey dem bill. The count also use tokenizer for the model wey you pass, so pass the model wey you actually go run.

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

Wetin else dey enter the bill

Tokens na the biggest part of the bill. Some other items no be tokens, and dem dey surprise people.

• Tool definitions dey become input tokens for every request. The tool use system prompt alone dey add 286 to 406 tokens for 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 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.
• If you ask for 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. When you reach usage ceiling for a plan, na usually then this question start, and the ways to move beyond a limit range from waiting for the window to reset to moving that work to metered API calls. Below one particular usage level, flat monthly plan win completely, and the API compared with a Claude subscription do that comparison with real numbers.

FAQ

1M tokens 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 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 change to $3 input and $15 output on 1 September 2026. Rates fit 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 English characters, 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 produces roughly 30 percent more tokens for the same text than Claude Sonnet 4.6 and earlier versions, so counts no dey transferable 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 don pay for itself from the first read. E fit fail in two ways, and both failures dey silent. If the cached prefix change between requests, the lookup no go match because na exact prefix match. If the prefix short pass the model's 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 full conversation dey send again for every turn. Messages API no dey keep state, so turn 20 of a chat carry all the earlier 19 turns as input again. If turns average 500 tokens, one 20 turn conversation send about 105,000 input tokens, even though the transcript na only 10,000 tokens long. Agent loops dey 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.