T
Glossary
Token-Based Pricing
Token-based pricing charges for language model use by the token, the unit a model splits text into before processing it. The billable quantity is the token count of a request plus its response, and the rate depends on which category each token falls into rather than on the token itself.
Key Takeaways
Anthropic publishes five separate rates for a single model. Claude Opus 5 lists $5 per million input tokens, $6.25 for a 5-minute cache write, $10 for a 1-hour cache write, $0.50 for a cache hit, and $25 for output.
That's a 50x spread between the cheapest and dearest token on one model, so a token count alone can't price a request.
Cache rates are published as multipliers of base input: 1.25x for a 5-minute write, 2x for a 1-hour write, and 0.1x for a read.
Multipliers stack. Anthropic states its cache multipliers "stack with other pricing modifiers, including the Batch API discount and data residency", where US-only inference adds 1.1x across every token category.
Marketplace billing abandons tokens entirely and converts to a currency proxy, where "One hundred (100) CCU represents $1.00 USD of fees".
How many rates does one token have?
Five, on a current Anthropic model, and that's before any multiplier applies. The category a token lands in matters far more than the count, which is the thing most billing implementations get wrong when they meter "tokens" as a single metric.
Anthropic's published rates for Claude Opus 5, read on 1 September 2026:
Token category | Rate per million tokens |
|---|---|
Base input | $5 |
5-minute cache write | $6.25 |
1-hour cache write | $10 |
Cache hit or refresh | $0.50 |
Output | $25 |
A million tokens costs $0.50 or $25 depending only on which column it belongs to. Any meter that emits a single tokens count and multiplies by one rate will be wrong by up to 50x on the same traffic, which is why the meter definition for a model has to carry the category as a dimension rather than collapsing it.
The rate levels also move by model. The same table lists Claude Sonnet 5 at $2 input and $10 output, and Claude Fable 5 at $10 and $50. Model identity is a second required dimension, so the minimum viable usage event here carries a token count tagged with both a model and a category.
What multipliers stack on top of the base rate?
Cache behavior and inference geography, and Anthropic documents them as multipliers rather than absolute prices, which tells you they compose. Its own wording: these multipliers "stack with other pricing modifiers, including the Batch API discount and data residency."
The published modifiers:
5-minute cache write: 1.25x base input price
1-hour cache write: 2x base input price
Cache read or hit: 0.1x base input price
US-only inference via inference_geo, on Claude 4.6 and later: 1.1x on all token categories, cache writes and reads included
Because they compose, the break-even on caching is arithmetic rather than intuition, and Anthropic states it outright: caching "pays off after one cache read for the 5-minute duration (1.25x write), or after two cache reads for the 1-hour duration (2x write)." Pay 1.25x once, read at 0.1x, and you're ahead on the first reuse.
For anyone reselling model access, the stacking is the part that hurts. A cost model built on base input and output rates silently misses a 1.1x residency multiplier applied across every category, and that error compounds on the highest-volume accounts rather than the smallest.
Why can't customers predict a token bill?
Because none of the three inputs to the bill are visible to the customer before they send the request. They control the prompt, and that's roughly it.
What the customer can't see in advance:
The output token count, which carries the most expensive rate and is decided by the model, not the request.
Whether a given input token hits cache or writes it, a 12.5x difference between $0.50 and $6.25 on the same content.
Which model actually served the request, if the product routes across models.
What tokenization does to their text, since a token is not a word and the count is a property of the tokenizer.
That's the argument for putting credit burn-down or a quota in front of raw token billing. Neither makes the bill predictable, but both give the customer a ceiling while the meter stays per-token. Providers reach the same conclusion from the other direction, which is what the CCU conversion is: on Marketplace Platforms, Anthropic bills a currency proxy where 100 CCU represents $1.00, so the invoice stops mentioning tokens at all.
Related terms
Token pricing pulls in the metering vocabulary fast, since the unit is the hard part.
AI Token Pricing works through how a token bill gets calculated and where reselling margin goes.
Usage Event is the record that has to carry the model and category before a rate can touch it.
JSON Meter is where those dimensions get defined for aggregation.
Credit Burn-Down is the pattern most AI products put in front of per-token rates.
Consumption-Based Pricing is the parent model token pricing is one instance of.
Quota is how a customer bounds an unpredictable token bill.
FAQ
Is token-based pricing the same as usage-based pricing?
Token-based pricing is one kind of usage-based pricing, distinguished by its unit. Usage-based pricing covers any model where the bill tracks consumption, whether the unit is an API call, a gigabyte, or a resolved ticket. Tokens are a harder unit than most, because the same nominal unit carries several different prices.
Why do cached tokens cost less?
The provider has already done the work of processing that content and stores the result, so a cache read skips computation the cache write already paid for. Anthropic prices a read at 0.1x base input for that reason. The write costs more than a normal input token, at 1.25x or 2x depending on how long the cache should live, which is the fee for storing it.
Should I bill my own customers per token?
Only if they can connect tokens to something they value. Reselling tokens at a markup exposes you to every rate category and multiplier above while giving the customer a number they can't forecast. Most teams meter tokens internally for cost tracking and bill the customer in a unit tied to their outcome, then use the token data to check margin.
How do you meter tokens accurately for billing?
Emit one event per request carrying the model, the token category counts, and an idempotency key, then let aggregation apply the right rate to each category. The failure mode is collapsing input, output, cache write, and cache read into one number at the point of emission, because that data can't be recovered afterwards.
Back to glossary
