What you will be able to do
- Estimate the cost of a request from its input and output token counts and the model's per-million-token prices
- Explain how the batch discount, fast mode, US-only inference and cache multipliers change the rate, and which of them combine
- Count a request's input tokens with the count_tokens endpoint before sending it, including when you compare tokenizers for a migration
- Reconcile actual spend from the usage fields on each response and from the Usage and Cost Admin API, and read them next to your rate limits
Key concept
Three-part input total — Prompt caching lets a request reuse a stored copy of a prompt prefix that ends at a marked cache breakpoint. Because of that, a response reports its input in three separate fields, and each field is billed at its own rate: tokens read from cache, tokens written to cache, and uncached tokens after the last breakpoint. You only get the real input size, and the real input cost, by adding all three.
1.Input and output tokens have separate prices
Claude bills by the token, and the price depends on which direction the token travels. [Tokens](lesson:5.1) are the units the model reads and writes. Everything you send in a request counts as input, and everything Claude generates counts as output. Each model has one price for input and another for output, both quoted in US dollars per million tokens (MTok).
| Model | Input | Output |
|---|---|---|
| Claude Fable 5.1 | $10 / MTok | $50 / MTok |
| Claude Opus 5.5 | $4 / MTok | $20 / MTok |
| Claude Sonnet 5.5 | $2 / MTok | $10 / MTok |
| Claude Haiku 4.5 | $1 / MTok | $5 / MTok |
On every model in that table, an output token costs five times as much as an input token. That changes how you read a cost estimate. Take a Sonnet 5.5 request with 10,000 input tokens and a 2,000-token answer: the input costs $0.02, and the much shorter output also costs $0.02. If you only budget for prompt length, a workload that writes long answers will cost more than you planned.
Input means more than the text you typed. With tool use, the input includes the tools parameter (each tool's name, description and schema), every tool_use and tool_result block in the conversation, and a system prompt the API adds automatically when tools are present. Server-side tools such as web search also charge per use on top of their tokens. A large tool catalogue is therefore paid for again on every turn.
Checkpoint 1 of 6· Check yourself
A Claude Sonnet 5.5 request sends 10,000 input tokens and gets back 2,000 output tokens. How do the input and output costs compare?
Sonnet 5.5 charges $2 per MTok for input and $10 per MTok for output. 10,000 × $2/M and 2,000 × $10/M both come to $0.02.
“Claude Sonnet 5.5The best combination of speed and intelligence | $2 / MTok | $10 / MTok”Source: platform.claude.com
Sources1
2.Modifiers that change the per-token rate
The base price is only a starting point. Several request settings multiply it. Batch processing, explained in [Message Batches API and realtime vs batch](lesson:2.3), halves both input and output prices in exchange for asynchronous delivery. Fast mode, covered in [Effort levels and fast mode](lesson:5.3), goes the other way: on Claude Opus 5.5 it charges $8 input and $40 output per MTok, twice the standard rate. Setting inference_geo to US-only on Claude 4.6 and later models adds 1.1x to every token category.
Three of the rows below concern prompt caching. A prompt prefix that stays the same from request to request can be cached, and you mark where that prefix ends with a cache_control breakpoint. When a request arrives, the system checks whether the prefix up to the breakpoint is already cached. If it is, those tokens are a cache read; if not, the full prompt is processed and the prefix is stored as a cache write.
| Modifier | Effect on price | Limits |
|---|---|---|
| Batch API | 50% off input and output tokens | Fast mode cannot be batched |
| Fast mode (Opus 5.5) | $8 / MTok input, $40 / MTok output | Claude API (first-party) only |
| US-only inference_geo | 1.1x on input, output, cache writes and cache reads | Claude 4.6 and later models |
| 5-minute cache write | 1.25x base input price | Only on the tokens written |
| 1-hour cache write | 2x base input price | Only on the tokens written |
| Cache read (hit) | 0.1x base input (0.05x on Opus 5.5, 0.025x on Fable 5.1) | Only on the tokens read |
These modifiers combine. Cache multipliers apply together with the batch discount, so a batched request that reads a cached prefix gets both discounts. Fast mode pricing also stacks with caching and data residency, but you can't combine it with batch. Context length is not a modifier. Claude 4.6 and later models bill the full 1M-token window at the standard per-token rate, so a very long request costs more only because it has more tokens.
Checkpoint 2 of 6· Check yourself
Which pricing combination cannot be used?
Fast mode stacks with caching and data residency multipliers, but you can't submit a fast-mode request through the Batch API.
“Fast mode is not available with the Batch API.”Source: platform.claude.com
3.Counting tokens before you send
The count_tokens endpoint tells you a request's input size without running the model. It accepts the same structured input as message creation (system prompt, tools, images and PDFs) and returns one number, input_tokens. That makes it the right tool for cost estimates: count a representative request once and multiply by expected volume, without paying for inference. The endpoint is free, but it has its own requests-per-minute limit that depends on your usage tier.
Checkpoint 3 of 6· Fill the gap
Which method returns the input token count without generating a response?
client = anthropic.Anthropic()
response = client.messages. ? (
model="claude-opus-5-5",
system="You are a scientist",
messages=[{"role": "user", "content": "Hello, Claude"}],
)
print(response.json())messages.count_tokens takes the same arguments as messages.create and returns {"input_tokens": 14} for this request, without any inference.
Source: platform.claude.comThe count has three limits. First, it ignores caching. You can include cache_control blocks, but the result is the raw input size, not what you'd pay after cache hits. Second, some inputs that the Messages API accepts are rejected here: most server tools, the MCP connector, and image or document blocks that use a url or file source. Send images and PDFs as base64 if you need them counted. Third, the count depends on which model you pass.
The model dependence matters when you migrate. Fable 5.1, Mythos 5.1, Fable 5 and Mythos 5 use the tokenizer introduced with Opus 4.7, and the same prompt comes out about 30 percent larger on it than on older models. Cost dashboards built from old counts will then underestimate. To find the real difference, count the same request twice, once with your current model and once with the new one, and compare the two input_tokens values.
Checkpoint 4 of 6· Exam question
A document-analysis pipeline caches a 40,000-token reference manual using an ephemeral cache_control breakpoint with the default TTL. Analysts submit follow-up questions against the manual in bursts, but gaps between bursts are frequently 8 to 10 minutes. The team observes that cache reads are not occurring for most follow-up bursts, so they keep paying the full cache-write price again. What change best fits this usage pattern?
Correct answer: A — Set the cache_control ttl to "1h" so the manual stays cached across the longer gaps between analyst bursts, avoiding repeated 5-minute cache writes
- A. Correct. The default ephemeral cache TTL is 5 minutes, which is shorter than the observed 8-10 minute gaps, so the cache expires between bursts. The 1-hour TTL option (2x base input price for the write) covers that gap and lets later bursts hit the cache instead of re-writing it.
- B. A fixed 5-minute pre-warm cadence only refreshes the cache if requests actually land within the 5-minute TTL window; it does not address gaps of 8-10 minutes without essentially running a background job indefinitely, and it isn't the direct mechanism Anthropic provides for extending cache lifetime.
- C. Splitting into four breakpoints changes granularity, not TTL; each 10,000-token chunk would still expire after 5 minutes of inactivity under the default TTL, so the same problem recurs.
- D. There is no context-window setting that retains prompt content in server-side memory between sessions; the context window defines the maximum tokens per request, and caching is controlled through cache_control, not context window size.
Checkpoint 5 of 6· Check yourself
A team counts a 50,000-token prompt with count_tokens. The request includes a cache_control breakpoint on a prefix that is already cached. What does the endpoint report?
Caching only happens when a message is actually created. The count is the full input regardless of breakpoints.
“No, token counting provides an estimate without using caching logic.”Source: platform.claude.com
Sources3
4.Tracking actual spend and how close you are to limits
Each response's usage object records what you were actually billed for, and the input side is split three ways. cache_read_input_tokens were read from cache, cache_creation_input_tokens were written to cache, and input_tokens are the uncached tokens after the last breakpoint. A common mistake is to log input_tokens alone. With a 200,000-token cached document and a 50-token question, that field shows 50 even though 200,050 tokens went in.
The Usage and Cost Admin API gives you totals for the whole organization. It needs an Admin API key. Its /v1/organizations/usage_report/messages endpoint returns token counts in 1m, 1h or 1d buckets, and you can filter or group by model, workspace, API key, service tier, inference_geo or speed. The cost report returns amounts in USD, which finance teams use to reconcile internal records against Anthropic billing. The Console Usage and Cost pages show the same data, and both can be exported as CSV.
curl "https://api.anthropic.com/v1/organizations/usage_report/messages?\
starting_at=2025-01-01T00:00:00Z&\
ending_at=2025-01-08T00:00:00Z&\
group_by[]=model&\
bucket_width=1d" \
-H "anthropic-version: 2023-06-01" \
-H "x-api-key: $ANTHROPIC_ADMIN_KEY"The same three input fields also show how close you are to your rate limits, which are explained in [Rate limits, spend limits and service tiers](lesson:2.1). On most models, input_tokens and cache_creation_input_tokens count toward input tokens per minute (ITPM), but cache_read_input_tokens do not. A higher cache rate therefore lowers both cost and pressure on ITPM. The Console Usage page plots hourly peak ITPM next to your cache rate and your current limit, so one chart shows both effects.
Checkpoint 6 of 6· Match them up
Match each usage field to what it counts
Tap a term, then the definition that fits it.
The three fields together make up total input. input_tokens alone covers only the part after the last breakpoint.
“Important: input_tokens does NOT represent all input tokens, only the portion after your last cache breakpoint.”Source: platform.claude.com
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.The input_tokens field in the response is the request's total input size.Why is that wrong?
input_tokens only covers uncached tokens after the last cache breakpoint. Total input is that plus cache_read_input_tokens plus cache_creation_input_tokens.
Covered in Tracking actual spend and how close you are to limits
2.A token count measured on an older model still holds after moving to a model with a newer tokenizer.Why is that wrong?
The endpoint counts with the tokenizer of the model you pass, so count the same request under both models and compare the results.
Covered in Counting tokens before you send
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“The total number of input tokens sent to the model (including in the tools parameter)”
↩︎ Input and output tokens have separate prices“Claude Sonnet 5.5The best combination of speed and intelligence | $2 / MTok | $10 / MTok”
↩︎ Input and output tokens have separate prices“specifying US-only inference through the inference_geo parameter incurs a 1.1x multiplier on all token pricing categories”
↩︎ Modifiers that change the per-token rate“A 900k-token request is billed at the same per-token rate as a 9k-token request.”
↩︎ Modifiers that change the per-token rate“These multipliers stack with other pricing modifiers, including the Batch API discount and data residency.”
↩︎ Prediction“Fast mode is not available with the Batch API.”
↩︎ Checkpoint - 2.
“The system checks if a prompt prefix, up to a specified cache breakpoint, is already cached from a recent query.”
↩︎ Modifiers that change the per-token rate“total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens”
↩︎ Key concept“Important: input_tokens does NOT represent all input tokens, only the portion after your last cache breakpoint.”
↩︎ Exam trap 1“Important: input_tokens does NOT represent all input tokens, only the portion after your last cache breakpoint.”
↩︎ Checkpoint - 3.
“Token counting is free to use but subject to requests per minute rate limits based on your usage tier.”
↩︎ Counting tokens before you send“count the same request twice, once with your current model and once with the model you plan to move to”
↩︎ Counting tokens before you send“The token counting endpoint counts under the tokenizer of the model you pass.”
↩︎ Exam trap 2“No, token counting provides an estimate without using caching logic.”
↩︎ Checkpoint - 4.https://platform.claude.com/docs/en/api/rate-limitsOfficial docs
“For most Claude models, only uncached input tokens count toward your ITPM rate limits.”
↩︎ Tracking actual spend and how close you are to limits - 5.
“Cost reconciliation: Match internal records with Anthropic billing for finance and accounting teams”
↩︎ Tracking actual spend and how close you are to limits - 6.https://support.claude.com/en/articles/9534590-cost-and-usage-reporting-in-the-claude-consoleOfficial docs
“Rate Limit Use: Visualizations of input and output tokens per minute compared with the overall ITPM or OTPM rate limit.”
↩︎ Tracking actual spend and how close you are to limits