Read an AI pricing page as a list of separate meters, not one price. Input tokens, output tokens, cache writes, cache reads, batch, long prompts, region choice and tool use can each carry their own rate. A fair estimate multiplies your real usage by each meter that applies to your workload.
The meters you will usually find
Anthropic's pricing page is a good example of how many dimensions exist. It has columns for base input, cache writes at two durations, cache hits, and output. Further sections cover prompt caching, data residency, fast mode, batch processing, long context, tool use, and managed agent runtime. This post does not repeat any rates, because they change. It shows what to look for.
| Meter | Question to ask |
|---|---|
| Input tokens | Is there a different rate above some prompt length? |
| Output tokens | Do reasoning tokens bill as output? |
| Cache write | Does a longer cache lifetime cost more to write? |
| Cache read | How does it compare with base input? |
| Batch | Is there a discount, and does it stack with caching? |
| Region | Does choosing a region change the multiplier? |
| Speed tier | Is a faster mode priced above standard? |
| Tools | Do web search, code execution or other tools bill per use? |
| Runtime | Do hosted agents bill for session time as well as tokens? |
Read these notes carefully
The context window documentation says thinking tokens are billed as output tokens, and the Anthropic pricing page says some multipliers stack with others. It also notes that for one model, prompts above a size threshold use a higher rate. Footnotes like these decide whether an estimate is right.
Another trap is a tokenizer change. The token counting page says newer tokenizers can produce about 30 percent more tokens for the same text on some models. The same price per token then yields a different bill. See same price per token, same bill, a myth.
Build an estimate in five steps
- Pick one real task, such as summarizing a document or fixing a bug.
- Measure its tokens: input, output, any reasoning, and how much input is repeated across calls.
- List the meters that apply: cache reads for the repeated part, tools if used, batch if it can wait.
- Multiply each by the rate on the current page, in a spreadsheet you keep with a date.
- Multiply by expected volume, then add a margin for retries and growth.
Cost per task beats cost per token for decisions, as argued in cost per task, not cost per token.
Subscription plans are a different meter
A flat plan replaces token meters with usage windows. The help center for one provider describes a five-hour session limit and a weekly limit. See why subscriptions have usage limits. Do not compare a plan fee to a token rate without translating your actual use.
Keep the estimate honest
Date your spreadsheet and link the pricing page you used. Re-check it each quarter, and after any model change. Never quote a rate in a customer document without a date and source.
Worked example: estimating one task with placeholder rates
Use symbols instead of real rates. Let I be the input rate, O the output rate, CR the cache read rate and CW the cache write rate, each per million tokens. A task has 20,000 input tokens, of which 15,000 are a repeated prefix, and 1,000 output tokens.
| Scenario | Cost expression |
|---|---|
| No caching | 20,000 x I + 1,000 x O |
| Caching, first call | 5,000 x I + 15,000 x CW + 1,000 x O |
| Caching, later calls | 5,000 x I + 15,000 x CR + 1,000 x O |
Divide each by one million to convert. Fill in the rates from the current page and you can see where the break-even sits. The pricing page says cache writes cost more than base input and reads cost much less, so caching wins when you read the prefix enough times within its lifetime. Run the same table for batch, region and any tool charges that apply.
A spreadsheet layout
- Column A lists the task. Column B is input tokens, C output tokens, D reasoning tokens if any, E repeated prefix tokens.
- A rates sheet holds each meter, the date you read it and the URL.
- Formulas reference the rates sheet, never typed numbers.
- A volume sheet holds tasks per month, with a low, expected and high case.
- A notes column records assumptions such as cache lifetime and batch eligibility.
Questions for the vendor
If you buy through a sales contact instead of a public page, ask: which meters apply, whether committed spend changes any rate, how limits are set, what happens at a cap, how a model retirement is handled, and what notice you get before a price change. The Anthropic page itself mentions volume discounts and enterprise arrangements as separate topics, so rates may differ from the page for large buyers.
Reading a page that has changed
Pricing pages change without announcement. Save a dated copy of the page you used, either as a PDF or as a screenshot with the URL, next to your spreadsheet. When someone asks why a forecast was off, you can show what the page said on the day. If a new meter appears, such as a new tool charge or a speed tier, add a row for it and ask whether it applies to your workload. A blank row with a note is better than an unknown.
Red flags in your own estimate
A few patterns suggest an estimate is wrong. If it uses a single blended rate for input and output, it hides the effect of output length. If it ignores reasoning tokens, it will under-count on models that think before answering. If it assumes every request hits the cache, it overstates savings. If it uses last year's model's token counts for a new model, it ignores tokenizer differences. If it has no retry allowance, it ignores failed calls. And if no one has dated it, nobody can tell whether the page changed.
Fix these in the spreadsheet itself: separate columns for each meter, a reasoning column, a cache hit rate input, a retry percentage and a date cell at the top.
What this means for you
A pricing page is a menu of meters, and your bill depends on which ones your workload touches. Before you compare options, list the meters that apply to you and estimate your usage on each. A rate that looks low can cost more if your task writes long answers, and a rate that looks high can cost less if most of your input is cached.
Common mistakes
Typical mistakes are using one blended rate, ignoring reasoning tokens, assuming a perfect cache hit rate, comparing token prices across models without recounting tokens, leaving out retries and forgetting to date the estimate. Another is to treat a plan fee and a token rate as the same kind of number. Build the estimate per task from measured tokens, keep each meter in its own column and link the page you used.
Try it yourself
Click through it at your own pace, or open it full screen. It builds an inventory of what a project depends on. A good cost estimate starts the same way: list every meter that applies before you total anything.
Quick check
Is output priced the same as input?
Usually not. See input vs output tokens for why the two meters differ.
Do discounts combine?
Some do. The Anthropic pricing page says certain multipliers stack, including batch and data residency. Confirm on the page for your provider.
How often should I recheck prices?
At least quarterly, and whenever you change model, region or tier.
Sources
- Pricing, Claude API documentation
- Context windows, Claude API documentation
- Token counting, Claude API documentation
Last reviewed: 19 October 2026.
