How Claude Token Pricing Actually Works
Every Claude API call is billed in tokens, not requests, and not every token costs the same.
The same request can mix four different token types, each with its own price, and the model you pick multiplies all of them at once.
For a tech lead sizing a production workload, understanding this cost model is the difference between a rough guess and a defensible budget line.
This page builds the mental model: what a token is for billing purposes, why input and output are priced asymmetrically, and how caching splits the input side into two more prices again.
Summary
- Core Idea: Claude billing has four token categories per model (input, output, cache write, cache read), and each has its own per-million-token price.
- Why It Matters: A workload's real cost depends on the mix of these four categories, not just a single "price per call" number, and that mix shifts as you adopt caching or batching.
- Key Concepts: input tokens, output tokens, cache creation tokens, cache read tokens, per-MTok pricing, model tier.
- When to Use: Sizing a new feature's API budget, comparing model tiers for a task, or explaining a surprise invoice line to a stakeholder.
- Limitations / Trade-offs: Pricing is a moving target across model generations and promotional windows, so any number quoted here is a snapshot, not a permanent constant.
- Related Topics: token counting, prompt caching, model tiering, Batch API pricing.
Foundations
A token is the unit Claude's pricing meter runs on, not a word or a character.
Roughly, a token is a few characters of English text, so a short paragraph might be 40 to 60 tokens, and a long system prompt can run into the thousands.
Every Messages API response includes a usage object that reports exactly how many tokens of each type were consumed, so you never have to guess after the fact.
The simplest version of the pricing model has two categories: input tokens (everything you send, including system prompt, tool definitions, and conversation history) and output tokens (everything the model generates back).
Output tokens are priced meaningfully higher than input tokens for every Claude model, typically around five times higher.
That asymmetry exists because generating each output token requires a full forward pass through the model, while a large batch of input tokens can be processed together in parallel during the initial read.
A quick snapshot of per-million-token (MTok) pricing as of mid-2026 makes the spread across tiers concrete:
| Model | Input / MTok | Output / MTok |
|---|---|---|
| Claude Haiku 4.5 | ~$1 | ~$5 |
| Claude Sonnet 5 | ~$2 (intro, through 2026-08-31) | ~$10 (intro) |
| Claude Opus 4.8 | ~$5 | ~$25 |
| Claude Fable 5 | ~$10 | ~$50 |
Two things jump out immediately: output is always roughly 5x input within a given model, and the gap between the cheapest and most expensive model is roughly 10x on input and 10x on output.
Mechanics & Interactions
The two-category model above is the simplified version.
Once you introduce prompt caching, the input side splits into two further categories with their own prices: cache creation tokens (the cost of writing a reusable prefix into the cache for the first time) and cache read tokens (the discounted cost of reusing that prefix on a later call).
A cache write costs more than a normal input token, typically around 1.25x the base input rate for the standard 5-minute TTL, because the system does extra work to store the prefix for reuse.
A cache read, by contrast, is dramatically cheaper than a normal input token, often around a tenth of the base rate, because Claude skips reprocessing that segment of the prompt entirely.
This means a single request's usage object can report input tokens, output tokens, cache creation tokens, and cache read tokens simultaneously, each billed at its own rate:
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=500,
system=[{"type": "text", "text": long_prompt, "cache_control": {"type": "ephemeral"}}],
messages=[{"role": "user", "content": "Summarize the policy above."}],
)
usage = response.usage
# usage.input_tokens, usage.output_tokens,
# usage.cache_creation_input_tokens, usage.cache_read_input_tokensThe practical consequence is that a workload's blended cost per request is not a single number, it is a weighted average across up to four prices, and that average shifts every time your cache hit rate changes.
A workload that reuses a large system prompt across thousands of calls per day will see its effective per-request cost fall sharply after the first call pays the cache-write premium, because every subsequent call pays the much cheaper cache-read rate instead of full input price.
A common reasoning mistake is treating "input tokens" as a single fixed cost when comparing models: a model with a higher headline input price can still be cheaper in practice if it needs fewer total tokens to accomplish the same task, or if a large share of its input becomes cache reads.
Advanced Considerations & Applications
At production scale, three levers interact to determine your real spend: which model tier handles a given task, how much of the input prefix is cacheable, and whether the workload can tolerate asynchronous Batch API processing for roughly half the price.
None of these levers are mutually exclusive.
A well-tuned pipeline often routes classification-style tasks to Haiku, caches a shared system prompt across all tiers, and pushes non-urgent bulk work through the Batch API, compounding three separate discounts.
| Lever | Typical Saving | Best Fit |
|---|---|---|
| Model tiering (Haiku vs Opus/Fable) | Up to ~10x on both input and output | Routing by task complexity, not one model for everything |
| Prompt caching (cache read vs fresh input) | Up to ~90% on cached-hit tokens | Repeated system prompts, tool schemas, long shared context |
| Batch API | ~50% off synchronous pricing | High-volume, latency-tolerant workloads |
None of these numbers are static across the industry's release cycle.
Model generations retire and reprice, promotional intro pricing windows expire (Sonnet 5's intro pricing here is explicitly time-boxed through 2026-08-31), and cache discount percentages have shifted between provider updates in the past.
The durable takeaway is the shape of the cost model, four token categories, priced independently, multiplied by whichever model tier you route to, rather than any specific dollar figure.
For that reason, treat the numbers in this article as a snapshot for reasoning about trade-offs, and verify current figures against the live pricing page before finalizing a budget or an ADR.
Common Misconceptions
- "Input and output tokens cost the same." They do not, output is priced roughly 5x higher than input for every current Claude model, because generation is a fundamentally more expensive operation than reading.
- "A cache write is free, or the same price as a normal call." A cache write costs more than an uncached input token, the discount only appears on the read side, on later calls that reuse the same prefix.
- "The cheapest model is always the cheapest choice." A cheaper model that needs more retries, longer prompts, or produces lower-quality output that requires human rework can cost more end to end than a pricier model that gets it right the first time.
- "Token count is the same as character or word count." A token is roughly a few characters, but the exact mapping depends on the text and the tokenizer, which is why the API's token-counting capability exists instead of a fixed formula.
- "Pricing is fixed and safe to hardcode." Intro pricing windows expire, model generations retire, and discount percentages for caching and batching have changed before, so pricing assumptions belong in a config value you can update, not a hardcoded constant.
FAQs
Why is output more expensive than input for every Claude model?
Generating each output token requires a sequential forward pass through the model, while input tokens can be processed together during the initial prompt read, which is a fundamentally more parallelizable operation.
How many token price categories exist in total?
Four in the general case: input, output, cache creation, and cache read. A request without caching only touches the first two.
Is a cache write ever cheaper than a plain input token?
No, a cache write is always priced above the base input rate, because it does extra work to persist the prefix for later reuse. The savings only materialize on the read side.
Does a longer cache TTL cost more?
Yes, a longer TTL option (such as 1 hour instead of the default 5 minutes) carries a higher cache-write cost multiplier, since the entry has to survive longer before it can be evicted.
Why does Sonnet 5's pricing table show two different numbers?
Sonnet 5 launched with time-boxed intro pricing that reverts to a higher rate after a fixed date (2026-08-31 in the current pricing snapshot). Always check which rate applies to your billing period.
If I never use caching, do I still pay four token prices?
No, without any cache_control breakpoints in your request, only input and output tokens apply. Cache creation and cache read tokens only appear once you opt into caching.
Is the 10x price gap between Haiku and Fable justified?
It reflects a genuine capability and cost-to-serve gradient across the model family, not an arbitrary markup, which is exactly why model tiering by task difficulty is a real cost lever rather than a false economy.
Can I predict a request's exact cost before sending it?
You can estimate the input side closely using the Messages API's token-counting capability before the call, but the output token count is only known after generation completes, since it depends on what the model actually writes.
Does the token type mix change over the life of a conversation?
Yes, in a multi-turn conversation with a cached system prompt, later turns typically show a growing share of cache-read tokens relative to fresh input tokens, since the shared prefix keeps hitting cache.
Should I hardcode these prices in my application code?
No, treat pricing as configuration you can update, not a constant baked into business logic, since intro windows expire and model generations get repriced on their own schedule.
Is a low-cost model always the wrong choice for hard reasoning tasks?
Not necessarily as a blanket rule, but a lower-tier model that fails a hard task and needs escalation to a stronger model on retry ends up paying for both calls, which can erase the tiering savings for that specific task class.
What's the fastest way to sanity-check a real invoice against this model?
Sum each token category from your logged usage objects over a billing period, multiply by that category's per-MTok rate, and compare the total against the invoice line, that reconciliation catches pricing assumption drift early.
Related
- Token Economics Basics - counting tokens and estimating cost before you send a request.
- Sonnet 5 vs Opus 4.8 vs Fable 5: A Cost-Per-Task Comparison - the pricing table applied to real task costs.
- Model Tiering: Routing Simple Tasks to Haiku, Hard Tasks to Opus - turning the price gradient into a routing decision.
- Prompt Caching ROI: When Cache Writes Actually Pay Off - the break-even math behind the cache write/read split.
Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5 - and the official
anthropicPython SDK (latest 0.x release). Model names, pricing, and SDK versions move quickly - verify current specifics at platform.claude.com/docs before relying on them.