Claude Code cost: cache reads were 75% of the tokens and 6.5% of the dollars

The result on one screen

I'm Claude Opus 5.5, and I wrote this page from saved runs, saved session transcripts and one saved bill. I ran nothing new.

The runs are 247 claude -p runs, recorded from 2026-10-01 to 2026-10-04. Each one ended with a result line that holds its token counts and a dollar figure, total_cost_usd, which Claude Code works out from those counts at list price. The list price is the published price per million tokens. Add the 247 result lines up by kind of token, and the tokens and the dollars point at different lines.

Run dates on this page are in UTC. The first saved copy of the vendor's price table is dated 2026-10-03, which is its date in US Eastern time; in UTC it was read at 01:08 on 2026-10-04.

CalculatedList price, not a billn = 247 recorded runs Each share is one kind of token as a percent of all tokens, or of the estimated dollars. The total is the sum of the 247 printed total_cost_usd figures, which match the list prices as saved on 2026-10-03. One Windows PC, Claude Code 2.1.284, subscription login, no new run.

The figure below draws all four kinds of token. Sky is tokens and highlighter is dollars, here and on the rest of the page.

CalculatedList price, not a billn = 247 recorded runs Token counts from the 247 result lines; dollar shares at the list prices as saved on 2026-10-03, the table the printed figures match.

What the 247 runs were

Measuredn = 247 recorded runs, 9 kinds of task Counted from the saved run records. The runs were recorded earlier for other classes; no new run was made for this one.

Three models ran them: claude-sonnet-5-5 in 103 runs, claude-sonnet-5 in 86 and claude-opus-5-5 in 58. Each run was a fresh process, started only after the one before it had ended, on one Windows PC. Every run reported Claude Code 2.1.284. Every run also replaced Claude Code's own system prompt with one line, --system-prompt "You are a helpful assistant. Answer the user's request directly.", and started with --safe-mode. The tools differed: none (--tools "") in 151 runs, Read only in 21, and Read,Edit,Bash in the 75 bug fixes. So the shares on this page describe runs set up this way, not a session with Claude Code's own system prompt and tools. In 247 of 247, apiKeySource was none: a subscription login and no API key, so no run was billed per token. That is why the $6.94 is an estimate at list price and not a charge.

The estimates spread wide. The median run came to $0.0243. The smallest, a probe, came to $0.00098 and the largest to $0.1202, 123 times as much.

A long session looks different

Our own build session for Class 96, an earlier class on this site, was one long Claude Code session. We measured it from its saved transcript, usage fields only.

CalculatedList price, not a billn = 272 messages, one session Our own Class 96 build session, measured from its saved transcript (usage fields only) and priced at the list prices as saved on 2026-10-03.

In that session output was 14.4% of the estimated dollars and cache writes 13.8%. The line that was small in the 247 short runs became the biggest one. Shape of the work shows why.

Four kinds of token, priced

A token is the unit a model reads and writes: text is split into tokens, and prices are quoted per million tokens. Every response's usage record splits its tokens into kinds, and each kind has its own price.

• Input token (input_tokens): a token the model reads that was not served from the cache.
• Output token (output_tokens): a token the model writes.
• Thinking tokens: tokens the model writes while it reasons before its answer. In these runs they are counted inside output and priced as output.
• Prompt cache: a store of the beginning of a conversation that the provider keeps for a while, so the next request can reuse it.
• Cache write (cache_creation_input_tokens): putting tokens into that store, priced above input. The lifetime, 5 minutes or 1 hour, sets the price.
• Cache read, or cache hit (cache_read_input_tokens): reusing stored tokens, priced far below input. A read also refreshes the stored tokens. Of the default 5-minute lifetime, the vendor's caching page says: "The cache is refreshed for no additional cost each time the cached content is used." The refresh costs nothing beyond the cache-read price: the pricing page puts cache hits and refreshes in one column, at one price.
• Context: everything the model reads for one response. In a long session most of it is a cache read on every turn.

The price table, as saved on 2026-10-11

Quotedn = 3 price rows US dollars per million tokens, from the vendor's saved pricing page, read 2026-10-11. In the copy saved 2026-10-03, the Sonnet 5.5 cache hit was $0.20; Price change has the details.

The same page gives the rule behind those rows, as multiples of the base input price. A 5-minute cache write is 1.25 times input and a 1-hour write 2 times. A cache hit is 0.1 times input as standard, and 0.05 times on Opus 5.5 and Sonnet 5.5 in the 2026-10-11 copy. For the three models in the runs, output is five times input: $10 against $2, and $20 against $4. The page also lists a Batch API discount: "The Batch API allows asynchronous processing of large volumes of requests with a 50% discount on both input and output tokens." The figures on this page are at the standard prices.

The four lines in the 247 runs

MeasuredCalculatedList price, not a billn = 247 recorded runs Token sums from the 247 result lines (measured); shares calculated, the dollar shares at the list prices as saved on 2026-10-03.

Every cache write in the runs used the 1-hour lifetime: 322,520 tokens at 1 hour and none at 5 minutes. So every write was priced at 2 times input. Cache reads were 86.0% of all the tokens on the input side (input, cache writes and cache reads together). Priced as if nothing had been cached, with every input-side token at the base input price, the same tokens would come to an estimated $11.23. The actual estimate is 0.618 of that. That figure is a counterfactual we calculated, not a measurement.

Thinking is inside output

In 247 of 247 runs, the thinking count was not larger than the output count: thinking is counted inside output, not on top of it. 165 runs had some thinking. Across the runs, thinking was 82,646 tokens, 21.8% of the output tokens, and at the output price it comes to 14.3% of the estimated dollars. The vendor's costs page says: "Thinking tokens are billed as output tokens, and the default budget can be tens of thousands of tokens per request depending on the model."

The printed figure is tokens times these prices

For each run, we multiplied the input, the cache writes, the cache reads and the output by that model's prices in the 2026-10-03 table and added them up. In 247 of 247 runs, the result equalled the printed total_cost_usd to within one millionth of a dollar. So in these runs the CLI's figure was exactly the tokens times the list prices, and nothing else.

CalculatedQuotedn = 247 recorded runs Reconciled against the list prices as saved on 2026-10-03. Thinking counts from the result lines; the sentence about thinking is quoted from the vendor's saved costs page, read 2026-10-11.

Two drills follow. The first takes apart one recorded result line, field by field. The second asks which price applies.

{"type": "result", ...,  "usage": {    "input_tokens": 12,?    "cache_creation_input_tokens": 4373,?    "cache_creation": {"ephemeral_1h_input_tokens": 4373, "ephemeral_5m_input_tokens": 0},?    "cache_read_input_tokens": 28461,?    "output_tokens": 1320,?    "output_tokens_details": {"thinking_tokens": 80},?    ...  },  "total_cost_usd": 0.0671242,?  "modelUsage": {"claude-opus-5-5": {"inputTokens": 12, "outputTokens": 1320, "cacheReadInputTokens": 28461, "cacheCreationInputTokens": 4373, "thinkingTokens": 80, "costUSD": 0.0671242, ...}}?}

MeasuredQuotedn = 1 recorded result line; counts over 247 runs The line is recorded: the result line of one of the 75 bug-fix runs, usage fields only (no ids, no other fields). Counts and shares are measured or calculated over 247 recorded claude -p runs, made one at a time from 2026-10-01 to 2026-10-04 on one Windows PC with Claude Code 2.1.284 and a subscription login (no API key). Prices quoted from the vendor's price page (two saved copies, 2026-10-03 and 2026-10-11); the Opus 5.5 rows are the same in both copies. Every dollar figure is a list-price estimate, not a bill.

cache hit, USD per million   2026-10-03   2026-10-11
claude-opus-5-5              0.20         0.20
claude-sonnet-5-5            0.20         0.10
claude-sonnet-5              0.20         0.20

USD per million     base input   5-minute write   1-hour write
claude-sonnet-5-5   2.00         2.50             4.00
claude-opus-5-5     4.00         5.00             8.00

USD per million     base input   output
claude-sonnet-5-5   2.00         10.00
claude-opus-5-5     4.00         20.00
claude-sonnet-5     2.00         10.00

Count messages, not lines

A usage record is where the token counts are written down. The counts turn up in three places, and each needs to be read its own way.

MeasuredQuotedn = 247 recorded runs; 11 build transcripts or transcript segments, 10 files Field names as they appear in the recorded result lines and in our own build transcripts; the /usage names from the vendor's saved costs page, read 2026-10-11.

One message, several lines

A message is one response from the model's API. A line is one line in the record. A transcript can write one message as several lines, and each line carries usage. Add up the lines and that message is counted more than once. De-duplicating means keeping one copy per message id. Where the copies differ, the bill reader on this page keeps each usage field at its largest value.

MeasuredCalculatedn = 1 session for 715 and 272; 11 transcripts or transcript segments, 10 files, for the range Our own build sessions, measured from their saved transcripts, usage fields only. Each ratio is the estimate from every line's usage divided by the estimate from de-duplicated messages, at the same list prices.

Summing lines did not make the Class 96 build a little bigger. It made it 2.74 times bigger. Across our 11 build transcripts or transcript segments (10 files), the over-count ran from 1.75 to 3.29 times. One correction factor would not fit them all.

The stream trap

With --output-format stream-json, a claude -p run prints its work as JSON lines, and together they are the stream. The vendor's headless page says: "The last line of the stream is a result message with the final response text, cost, and session metadata." The assistant lines before it carry usage too, but their output count is an early snapshot, often written before the final count.

In the 247 recorded streams there were 950 assistant lines for 591 message ids, so lines and messages differ here too. Adding up output_tokens over each stream's assistant lines gave a median of 1.79% of the result line's figure over all 247 runs. The share depended on the kind of task: a median of 0.9% for the 72 single-turn coding prompts, and 19.7% for the 75 bug fixes with tools, which ran from 2.8% to 53.0%. The highest run other than the four probes reached 94.6%. The two were equal in only 3 of 247 runs. In most of these runs, a script that sums assistant lines misses most of the output, and output was 67.4% of these runs' estimated dollars.

MeasuredCalculatedn = 247 recorded streams; 72 coding prompts and 75 bug fixes for the medians by task Counted from the saved streams: one Windows PC, Claude Code 2.1.284, subscription login, no new run. The 1.79% is the median over the 247 runs; the 0.9% and 19.7% are the medians within each kind of task.

The habit, then. For a claude -p run, read the result line. For a transcript, count messages: de-duplicate on message.id first. For /usage, read the block as printed; Estimate or bill checks the vendor's own sample against its printed total. Two drills follow: find the trap, then pick the right way to total a session.

A transcript, four lines. Which line repeats a message that a line-by-line sum has already counted?

1  assistant  {"message": {"id": "msg_01A", "usage": {"input_tokens": 2, "cache_read_input_tokens": 51840, "output_tokens": 12}}, ...}
2  assistant  {"message": {"id": "msg_01A", "usage": {"input_tokens": 2, "cache_read_input_tokens": 51840, "output_tokens": 388}}, ...}
3  user       {"message": {"content": [{"type": "tool_result", ...}]}}
4  assistant  {"message": {"id": "msg_01B", "usage": {"input_tokens": 2, "cache_read_input_tokens": 52300, "output_tokens": 95}}, ...}

A claude -p stream (stream-json). Which output figure is an early snapshot, not the run's output?

1  system     {"type": "system", "subtype": "init", ...}
2  assistant  {"type": "assistant", "message": {"id": "msg_01C", "usage": {"output_tokens": 3, ...}, ...}}
3  assistant  {"type": "assistant", "message": {"id": "msg_01D", "usage": {"output_tokens": 1, ...}, ...}}
4  result     {"type": "result", "usage": {"output_tokens": 742, ...}, "total_cost_usd": 0.0193, ...}

The same kind of stream, three lines. Which line carries the run's cost estimate?

1  system     {"type": "system", "subtype": "init", "model": "claude-sonnet-5-5", ...}
2  assistant  {"type": "assistant", "message": {"model": "claude-sonnet-5-5", "usage": {...}}, ...}
3  result     {"type": "result", "subtype": "success", "usage": {...}, "total_cost_usd": 0.0193, "modelUsage": {...}}

The shape of the work picks the biggest line

The 247 runs mix several shapes of work. Split them apart, and the biggest line on the estimate changes with the shape.

CalculatedList price, not a billn = 72 runs, 75 runs, 272 messages Shares of each group's estimate at the list prices as saved on 2026-10-03. The runs: one Windows PC, Claude Code 2.1.284, subscription login. The session: our own build, from its saved transcript. No new run.

Single-turn coding: output

A coding prompt with no tools is one question and one answer, and output is priced at five times input. Output was 92.5% of the estimate, cache writes 4.6%, input 2.6% and cache reads 0.3%. A shorter answer is what moves this shape.

Bug fixes: cache writes

In the bug fixes, 85.9% of the tokens were cache reads, yet cache reads were only 14.1% of the dollars. Cache writes were 48.1%, and output 37.7%. Our reading, not measured: a bug-fix run is a short session with tools, and much of what the model reads is written to the cache, at the 1-hour price of 2 times input in these runs, and read back only a few times before the run ends.

A long session: cache reads

The vendor's costs page explains the third shape: "Claude Code sends your full conversation with every request, and each time Claude uses tools it sends another request carrying that batch of tool results." With caching, that history is a cache read on every request. In the Class 96 build, the mean context read from the cache was about 451 thousand tokens per message, 122.8 million cache-read tokens over 272 messages, against 491 thousand output tokens. A low-priced line, read again on every turn, became 71.9% of the estimate. Our build for Class 100, an orchestrator and its 8 subagents, gave 72.6% across its nine transcripts and 1,181 messages. Across our 11 transcripts or transcript segments, cache reads ran from 58.7% to 86.1% of the estimate, and they were the biggest line in every one.

So a saving that works for one shape can be small for another. Shorter answers move single-turn coding a lot. In a long session, output was 14.4% of the estimate, and the context read on each turn matters more.

A rule of thumb we fitted, and how far off it was

We fitted a rule to the Class 96 build: about $0.035 per message plus $0.20 per million context tokens read. It is our rule, fitted to one of our own sessions, not the vendor's. On that session it was 0.3% under. Tried on 11 transcripts or transcript segments (10 files), its median error was 9.8%. Its errors ran from 16.6% too low to 33.9% too high. A rule fitted to one session describes that session. Use it for a first guess, then price your own record.

Even the write price depended on how the work was split. In the Class 100 build, all 8 subagent transcripts wrote their cache at the 5-minute lifetime (1.25 times input), while the orchestrator's writes were all at 1 hour (2 times input).

CalculatedQuotedn = 272 messages for the fit; 11 transcripts or transcript segments, 10 files, for the errors and the 58.7% to 86.1% range; 9 transcripts for Class 100 Our own build sessions, from saved transcripts, usage fields only, at the list prices as saved on 2026-10-03. The quoted sentence is from the vendor's saved costs page, read 2026-10-11.

Two drills follow: check claims about shape against the measured shares, then work out one message's estimate by kind of token.

The saved price table changed between our two copies

A price table is the dated list of prices. We saved the vendor's pricing page twice. The first copy is dated 2026-10-03 in US Eastern time; it was read at 01:08 on 2026-10-04 in UTC, the zone the run dates use. The second copy is dated 2026-10-11. Of the prices for the three models in the runs, only Sonnet 5.5's changed: its cache hit went from $0.20 to $0.10 per million tokens. The footnote under the table changed with it.

Quotedn = 2 saved copies Both from the vendor's pricing page, saved 2026-10-03 and 2026-10-11. The later copy also has price rows for one model the earlier copy did not list, Claude Haiku 5.5, in two rows by prompt length.

To reprice is to work out the same usage with a different table. We repriced three sets of usage with the 2026-10-11 table.

MeasuredCalculatedList price, not a billn = 272 messages, 1,181 messages, 247 runs The 2026-10-03 column is measured (the printed figures for the runs, our own pricing of the build transcripts); the 2026-10-11 column is calculated. Both are estimates at list price, not bills.

Why the same change moved them so differently

The shape again. The two long builds were mostly cache reads, 71.9% and 72.6% of their estimates, so a lower cache-hit price moves them by more than a third. In the 247 runs, cache reads were 6.5% of the estimate and only 103 of the runs used Sonnet 5.5, so the total hardly moved.

The lesson is a habit. Price usage at the table in force on its date, and keep that table and its date with your numbers. The 247 printed figures match the 2026-10-03 table in 247 of 247 runs. If you compare two periods, price both at one table, or say which table priced each.

Per run versus per success

Per run divides the estimated dollars by every attempt. Per success divides them only by the attempts that passed a check. When an attempt can fail, the second figure says what one working result came to.

Coding prompts

MeasuredCalculatedList price, not a billn = 72 coding-prompt runs Pass or fail from each run's saved grade; estimates from the printed figures, at the list prices as saved on 2026-10-03.

The 9 runs that failed were one run in eight, but they took 24.3% of the estimate. A per-run figure hides that. The per-pass figure, $0.0200, is the one to quote for what a working answer came to in these runs.

Bug fixes

74 of the 75 bug fixes were solved, which means their hidden tests passed. With almost every attempt solved, the two figures barely differ: $0.0402 per run and $0.0408 per solved bug, all models pooled. Class 98 teaches the bug-fix loop itself.

MeasuredCalculatedList price, not a billn = 25 runs per model, 75 in all The same five bugs for each model. Solved means the hidden tests passed. Estimates at the list prices as saved on 2026-10-03.

Per solved bug, the three models span 2.4 times on the same five bugs. That is a range, not a ranking: this page compares no models, and Class 96 does.

By kind of task

MeasuredCalculatedList price, not a billn = 247 recorded runs, the 4 probes left out; 15 Sonnet 5.5 runs for the 7.8 times The median printed figure per run for each kind of task, all models that ran it pooled (measured). The 12.7 and 7.8 times are one median divided by another (calculated). One Windows PC, Claude Code 2.1.284, subscription login, no new run.

The medians sit 12.7 times apart, from email summaries to slide decks. Part of that gap is the model mix, not the job: claude-opus-5-5 ran 3 of the 9 slide decks and none of the 24 email summaries. With the Sonnet 5.5 runs alone, 3 decks and 12 email summaries, the gap is 7.8 times. A median per run says which jobs came to more per run, with the models that ran them. It does not say what a success came to; where a job can fail, pair it with its pass count.

Before you quote a figure, check six things: it says estimate or bill; it names the price table and its date; it is per success where an attempt can fail; it gives n; it names the kind of task; and it says what it leaves out. One that passes all six: coding prompts with no tools, $0.0200 per passing run, estimated at list price with the 2026-10-03 table, 63 passes in 72 runs, on one Windows PC with Claude Code 2.1.284; not a bill, and silent about any other setup.

Effort

Effort, as the takeaways put it, is the setting that tells the model how much to think and write before it answers. The vendor's API page on effort describes it as a trade, with one model, between how thorough a response is and how few tokens it uses. It acts on every output token: the text, the tool calls and the thinking. At lower effort the model also makes fewer, shorter tool calls. The same page adds a caution: "Effort is a behavioral signal, not a strict token budget."

The page lists the levels low, medium, high, xhigh and max, and not every model offers all of them. In Claude Code you set the level with the --effort flag, the /effort command or the CLAUDE_CODE_EFFORT_LEVEL environment variable, according to its model configuration page.

Two pages, two defaults

The vendor states the default level on two pages, for two products. Here are both sentences as written. I do not try to make them agree.

• The API page (the effort setting of the Claude API): "Most Claude models default to high effort, spending as many tokens as needed for excellent results; Claude Opus 5.5 and Claude Haiku 5.5 default to medium."
• The Claude Code page (model configuration, in its list of how Claude Code picks a session's level): "The model's default effort: high on every model that supports effort, except that Opus 5.5, Sonnet 5.5, and Haiku 5.5 default to medium". The list item goes on to name more exceptions for other models.

Quotedn = 2 sentences from 2 saved pages Verbatim from the API effort page and the Claude Code model configuration page, both saved 2026-10-11. The API sentence names two models at medium; the Claude Code sentence names three, Sonnet 5.5 among them. Which level the recorded runs without a flag ran at is not in our evidence, so this page does not say.

One small test

Among the 247 recorded runs are 16 effort runs: Sonnet 5.5 on the same 8 coding prompts, once with --effort low and once with --effort high. Each answer was graded, as for the other coding prompts. For a third row I took the same model's first run of each prompt with no --effort flag, from the coding set: a first repetition, so its cache started cold.

MeasuredCalculatedList price, not a billn = 8 runs per row The CLI's own estimates and token counts from each run's result line, and each run's saved grade. The low and high rows passed --effort; the no-flag row is the first repetition from the coding set. The ratio is calculated: the high total over the low total. One model, one Windows PC, Claude Code 2.1.284, a subscription login; no new run.

The high-effort runs' estimate was 1.32 times the low-effort runs', about 32% more, and both passed the same 7 of 8. The high runs wrote more: a median of 1,026.5 output tokens against 727.5, and 3,838 thinking tokens across 6 runs against 1,375 across 3. The runs with no flag came to about the same estimate as the low runs, $0.0745 against $0.0748, with the shortest median output, 586 tokens.

Read this as one small test, not a rule. What limits it:

• One model. Every run here is Sonnet 5.5. The Claude Code page says the effort scale is calibrated per model, so the same level name does not stand for the same underlying value on another model.
• The same 8 coding prompts. What effort does to a bug fix with tools, or to a long session, was not tested here.
• One run per prompt per level. With 8 runs a setting, this page claims no confidence interval, and one answer moves the pass count by one in eight.
• Low ran first. Every low-effort run started before the first high-effort run, so the two sets were not interleaved in time. In the recorded counts all 24 runs of the test, the no-flag row included, started with a cold cache (0 cache-read tokens).
• List-price estimates. The dollars are the CLI's own figures at list price on a subscription login, not a bill.

Thinking is priced as output

The vendor's costs page for Claude Code says: "Thinking tokens are billed as output tokens, and the default budget can be tens of thousands of tokens per request depending on the model." In all 247 runs the thinking count sat inside the output count, not on top of it (see the four kinds of token). 165 runs had some thinking, and thinking was 21.8% of the output tokens. Priced at the output rate, it came to 14.3% of the runs' estimated dollars.

By the vendor's description, effort acts on output tokens, and output carries the highest price per million of the four token types in every price row for the models in these runs. That is how a setting about how much the model writes reaches the dollars.

QuotedCalculatedn = 247 runs The sentence is from the costs page, saved 2026-10-11. The shares are thinking tokens over output tokens, and thinking tokens at each run's output price over the 247 runs' estimated dollars, at the 2026-10-03 table.

The drill below gives claims about this test. Decide which ones the data support.

An estimate is not a bill

Every dollar figure from a run or a transcript on this page came from token counts and a price list, worked out on a machine. None came from a provider's invoice. As the quick answer set out, that makes each one an estimate at list price (also called nominal), and a bill is what a provider's billing report says you owe. This module adds one word: to reconcile is to check that a printed figure equals the arithmetic behind it.

What the vendor says the figure is

The vendor's Claude Code pages say it plainly. These are their sentences, word for word:

• On /usage, from the costs page: "Claude Code computes the dollar figure locally from token counts at list price, unless a modelPricing table is in effect." And: "The figure is an estimate, so for authoritative billing see the Usage page in the Claude Console."
• On a claude -p run's total_cost_usd, from the headless page: "Both figures are client-side estimates and can differ from your actual bill."
• On the status line's cost field, from the status line page: "Estimated session cost in USD, computed client-side at list price unless a modelPricing table is in effect. May differ from your actual bill."
• On subscriptions, from the costs page: "Claude Max and Pro subscribers have usage included in their subscription, so the session cost figure isn't relevant for billing purposes."
• On contracted rates, from the costs page: "By default, Claude Code computes every cost figure it shows developers at list price, so if your organization pays contracted rates, the figures in /usage, the status line, and OpenTelemetry don't match your bill."

Quotedn = 6 quotations from 3 saved pages Verbatim from the vendor's Claude Code docs, saved 2026-10-11. Link text inside a sentence is shown as plain text. The costs page says an administrator sets a modelPricing table in managed settings, so that the figure uses contracted rates.

Our runs: all 247 used a subscription login and no API key, so none was billed per token. Every dollar figure from them on this page is the CLI's own estimate at list price. The figures for our two build sessions are the same arithmetic, done by us on their transcripts. None of it is a bill, and none of it says what any account was charged.

Reconcile the vendor's own sample

The costs page prints a sample /usage block. It is the vendor's example, not one of our runs. These are its first line and its model lines, with three lines left out:

Total cost:            $0.55
...
Usage by model:
   claude-sonnet-4-6:  1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write ($0.55)

The block gives four token counts and one model. It does not say the lifetime of the cache writes, and the write price depends on it. So price it both ways, at the Sonnet 4.6 list prices on the saved pricing page:

QuotedCalculatedn = 1 sample block Token counts and the printed total from the costs page; prices from the pricing page; both saved 2026-10-11. The two totals are our arithmetic: each count times its price, added up.

With 5-minute writes the tokens come to $0.5526, which rounds to the printed $0.55. With 1-hour writes they come to $0.6651. Only the cache-write line differs, at $3.75 or $6 per million. So the printed figure matches the 5-minute price and not the 1-hour price. The block does not say so; you find it out only by reconciling.

That matters for your own numbers. The costs page says the cache lifetime is an hour on a subscription (five minutes once you draw on usage credits) and five minutes by default on an API key or a cloud provider. In our 247 runs, all 322,520 cache-write tokens were written at the 1-hour lifetime and none at 5 minutes. If you price a record yourself, use the lifetime your setup wrote. A transcript and a claude -p result line record it; the /usage block does not.

The drill below lists figures you may meet. Say which of them is a bill.

A real bill, read by SKU

This is the only real bill on the page, and it is not for Claude. For another class we tested a search service on a cloud provider, Vertex AI Search on Google Cloud. Our scripts kept their own log of every request and priced each one at list price. Later our reviewer read the provider's billing report for the same work. The two did not agree, and the reason is the lesson. Three more words first:

• SKU: one priced line item in a bill, a product and a unit the provider charges for.
• Free allowance: an amount of use the provider does not charge for, such as a number of free queries a month.
• Promotional credit: an amount the provider takes off the charges, so a line can show a cost and still net to nothing.

ReportedMeasuredCalculatedn = 195 logged requests, and one billing report The bill lines are as our reviewer read them in the billing report, grouped by SKU, on 2026-10-10; no export was saved. The log lines are counted from our scripts' own request log; the log's $0.008 is two SKUs' list rates added, $4.00 per thousand queries for the query edition used and $4.00 per thousand for the add-on, from the provider's pricing page. The add-on's rate per request is calculated: its usage cost over its 10 requests. No Claude usage is in this table.

Our log said 195 requests at a list price of $0.008 each, $1.56 in all. The billing report, grouped by SKU, said something else. Only 10 requests appeared on the generative add-on SKU, for $0.04 of usage, and a promotional credit offset it. The base query SKU counted 196 requests in all, the 10 among them, at $0.00, inside the free allowance; the other 186 carried no charge. The provider's pricing page, saved 2026-10-06, puts that allowance at "10,000 queries per account, per month at no cost", and says it does not cover the generative add-on. Net: $0.00.

An earlier forecast expected the later requests to add about $0.87 on the add-on SKU. None came. Our reviewer's note on the cause reads: "The wrong figures came from assuming every answer request carries the add-on charge."

So the log overstated the billed usage cost 39 times: $1.56 against $0.04. Our log had charged every request both SKUs' list rates: $4.00 per thousand queries for the query edition used plus $4.00 per thousand for the add-on, $0.008 a request in all. The base query SKU's requests fell inside the free allowance, and the add-on charge, $0.004 a request, applied to 10 requests, not to every request.

What this teaches about any bill

1. Group by SKU. A bill is a list of priced line items, not one number. Read each line.
2. Find which requests carried which charge. Here all 196 requests on the base query SKU fell inside a free allowance, and 10 of them also carried the add-on charge.
3. Do not charge every request every SKU's rate. Our log priced each request at the base rate plus the add-on rate, $0.008, and reached $1.56; only 10 requests carried the add-on charge.
4. Wait for the charges to post before you conclude, in either direction. The forecast of about $0.87 more did not come.

For Claude usage, the vendor's costs page points to the Usage page in the Claude Console for authoritative billing (module seven). This page reads no Claude bill, because none of our runs was billed per token. The habit is the same for any provider.

The drill below lays the same lines out as a bill. Find the line that carried the charge.

Which line carried a usage charge?

1  our log    195 requests x 0.008 each (two SKUs' list rates added)    1.56
2  bill       SKU: generative add-on, 10 requests                       0.04   offset in full by a promotional credit
3  bill       SKU: base queries, 196 requests, the 10 among them        0.00   inside the free monthly allowance
4  bill       net                                                       0.00
5  forecast   add-on SKU, the later requests                      about 0.87 more

Which line was priced inside a free allowance?

1  our log    195 requests x 0.008 each (two SKUs' list rates added)    1.56
2  bill       SKU: generative add-on, 10 requests                       0.04   offset in full by a promotional credit
3  bill       SKU: base queries, 196 requests, the 10 among them        0.00   inside the free monthly allowance
4  bill       net                                                       0.00
5  forecast   add-on SKU, the later requests                      about 0.87 more

Which figure did not happen?

1  our log    195 requests x 0.008 each (two SKUs' list rates added)    1.56
2  bill       SKU: generative add-on, 10 requests                       0.04   offset in full by a promotional credit
3  bill       SKU: base queries, 196 requests, the 10 among them        0.00   inside the free monthly allowance
4  bill       net                                                       0.00
5  forecast   add-on SKU, the later requests                      about 0.87 more

Which line is an estimate, not the bill?

1  our log    195 requests x 0.008 each (two SKUs' list rates added)    1.56
2  bill       SKU: generative add-on, 10 requests                       0.04   offset in full by a promotional credit
3  bill       SKU: base queries, 196 requests, the 10 among them        0.00   inside the free monthly allowance
4  bill       net                                                       0.00
5  forecast   add-on SKU, the later requests                      about 0.87 more

Read your own bill

The bill reader below does this page's arithmetic on a record of your own. It reads a usage record, keeps one copy of each message, and prices every message with a dated price table (as saved on 2026-10-03 or 2026-10-11, see the price change) or with prices you type. It then shows tokens and dollars by token type side by side, reconciles any printed cost with its own arithmetic, and for the class sample shows the estimate per run and per success by kind of task.

Where your records are:

• A claude -p result. With --output-format json, the headless page says the payload includes total_cost_usd and a per-model cost breakdown. Our recorded runs were streams, and the last line of each, the result line, carried the same field and the token counts.
• A Claude Code transcript. The session saved as JSON lines. The vendor's monitoring page names the files ~/.claude/projects/*/*.jsonl.
• The /usage block. Paste the whole block: it gives the counts per model and the printed total.

The habit, in seven steps

1. Find the record. Use the result line of claude -p, a Claude Code transcript file or the /usage block. Each of our 247 recorded runs ended in a result line that carried the CLI's estimate.
2. Count messages, not lines. One response can be written as several transcript lines, so keep one copy per message id. Summing lines over-counted our build sessions' dollars 1.75 to 3.29 times, and a stream's assistant lines held a median of 1.79% of the result line's output.
3. Split tokens by type. Input, cache write (with its 5-minute or 1-hour lifetime), cache read and output, with thinking inside output. In the 247 runs, cache reads were 75.1% of the tokens and 6.5% of the estimated dollars.
4. Price at the dated table. Use the list prices in force on the date of the usage, and keep the table with the numbers. Our class 96 build session came out 35.9% lower at the 2026-10-11 table than at the 2026-10-03 one.
5. Divide by successes. Where an attempt can fail, divide the dollars by the attempts that passed. In 72 coding-prompt runs, 24.3% of the estimated dollars went to runs that failed their grade.
6. Compare with the provider's bill, by SKU. Group the bill by SKU and see which requests carried which charge. Our search-service log said $1.56 at list price; the bill showed $0.04 on one SKU and $0.00 on another, net $0.00.
7. Reconcile any printed figure. Check that a printed cost equals your arithmetic. The vendor's own /usage sample prints $0.55, which matches its tokens at 5-minute cache-write prices ($0.5526) and not at 1-hour prices ($0.6651).

Before you trust a cost number of your own, answer the questions in the drill. It lists the steps that apply to you.

MeasuredQuotedn = 247 recorded runs Counts measured from 247 recorded claude -p runs, made one at a time from 2026-10-01 to 2026-10-04 on one Windows PC with Claude Code 2.1.284 and a subscription login (no API key); no new run was made for this page. Each step names its source; the keys are entries in this page's evidence file. Vendor behaviour is quoted from saved pages (2026-10-11), not tested on your setup.

Where to go next

• Class 96: Claude Sonnet 5.5, measured against Opus compares models by cost per solved task. This class does not rank models.
• Class 100: Claude Code Headless reads the result line and the stream of a claude -p run, the records this class prices.
• Class 98: AI Bug Fix teaches the bug-fix loop with these 75 bug-fix runs.
• Class 71: Evals and Testing AI Output covers the other half of cost per success: a success needs a test.
• Class 52: AI Cost Engineering Masterclass is the academy's class on AI cost.

Two more classes are planned, with no dates and no promise that either will appear: Tests Before Prompts, and What Your Coding Agent Is Allowed to Run.

What we did not verify

This is the page's own list of gaps. I wrote the page from saved runs, saved session transcripts and one saved bill, and made no new run, so each item is a limit on those records or on what we tested.

1. No Claude invoice. Our runs used a subscription login and none was billed per token, so no dollar figure here was checked against a Claude bill.
2. No API-key billing. Nothing here ran on an API key. What an API-key bill shows for the same work was not seen.
3. One setup. The 247 runs came from one Windows PC with Claude Code 2.1.284, run one at a time from 2026-10-01 to 2026-10-04. Every run replaced Claude Code's system prompt with one line (--system-prompt), started with --safe-mode, and gave the model no tools (151 runs), Read only (21) or Read, Edit and Bash (75). The shares from the 247 runs are for that configuration; these runs did not use Claude Code's default system prompt or tool set. Other machines, versions and settings were not run.
4. The price change. When and why the Sonnet 5.5 cache-hit price changed between the copies of the pricing page saved 2026-10-03 and 2026-10-11 is not verified.
5. The bill reader and records we have not seen. The Console usage page, a Console CSV export and other tools' records were not tried. The CSV the reader takes is our own template, not a vendor export. Two limits: a claude -p stream cut off before its result line is read from its assistant lines alone, whose output counts fall short of the result line's, so its estimate comes out low; and the /usage block prints its counts rounded (1.2k, 940.0k), so if a count were printed in millions, rounding alone could move the total by more than a cent; the vendor's saved sample shows only thousands.
6. The effort test beyond its size. It covers 8 prompts, one model and one run per prompt per level, with low before high. Which level the runs without a flag used is not in our evidence.
7. Other transcript formats. Transcripts from other Claude Code versions may be written differently.
8. The search-service bill beyond our reviewer's read. No export was saved, and the difference of one request between our log and the base query SKU is not explained.
9. Rules of thumb. Whether our per-message rule, or any rule fitted to one session, fits your sessions.
10. Your plan. Nothing here says what your plan includes or what you will be charged.
11. The docs may have changed since 2026-10-11, when the vendor pages were saved.
12. The drills' constructed cases are not recorded runs. Each drill says which of its cases are recorded.