Back to UsageCut

How to calculate your real Claude Code cost (most calculators get this wrong)

8 min read

On this page

A Claude Code session bills against four separate numbers, not one: fresh input, cache write, cache read, and output, each at its own rate, added up on every turn the session runs. Nearly every free calculator that turns up when you search for one prices exactly one of those numbers - plug in a token count, multiply by the input price, done. That math is correct for a single API request and wrong for a Claude Code session, because a session re-sends its whole history every turn, and almost none of that history bills at the input rate.

TL;DR: the real formula is (fresh input x price) + (cache write x price) + (cache read x price) + (output x price), summed across every turn. On real measured Claude Code sessions, cache reads alone are 93.9% of billed tokens - so a calculator that only prices what you typed misses nearly the entire bill. Worked example below, plus an interactive version that runs the same math for your own usage pattern.

The four numbers that actually make up your bill

Anthropic bills Claude API usage in four buckets, each at its own per-million-token rate: fresh input (what gets sent that wasn't already cached), cache write (new content entering the cache for the first time), cache read (anything already cached that gets sent again), and output (what the model writes back). A single API call mostly uses one or two of these. A Claude Code session uses all four, every turn, because Claude Code has no memory between calls - it resends the entire conversation so far as context on every single turn, and everything already sitting in that context gets billed again as a cache read.

That re-send is the part a generic pricing calculator has no way to model, because it isn't a fact about the model - it's a fact about how Claude Code's session loop works. Prompt caching and compaction, explained covers the mechanism in more depth; what matters here is just the billing consequence: your token count for a session is not your prompt, it's your prompt plus everything the session has accumulated so far, re-billed over and over.

Work it out for yourself, with real rates

Take a session that racks up 600,000 total billed tokens - a realistic medium-length session on this project's own modeled anchor (roughly 31,600 tokens of context per turn across about 20 turns). Split across the four buckets using this project's own measured session composition (1,037 real Claude Code sessions, deduped by message id) and priced at Sonnet 5's current published rates:

A 600K-token session, Sonnet 5, priced correctly

Split by this project's own measured session composition, priced at current published rates

Fresh input
3.0K tok
$0.0060 at $2/M
Cache write
29K tok
$0.073 at $2.5/M
Cache read
563K tok
$0.113 at $0.2/M
Output
4.2K tok
$0.042 at $10/M
Real session cost: $0.234Pricing only the fresh-input slice: $0.0060~39x undershoot

Swap in a different model and the split stays the same - session composition is a workflow fact, not a model fact - but the price per bucket changes. That's the entire formula. No step in it is exotic; the part that trips up a generic calculator is buckets two and three, because most tools built for "price my API call" never ask about them.

The sticker price isn't the real price, for any model

The same four-bucket math applies whichever model a session runs on, and it moves every model's effective price a long way from its sticker input rate - because cache reads, not fresh input, dominate the token count regardless of which model is doing the work:

Sticker input price vs. real session-weighted price, per model

Per million total tokens, this project's own measured session mix applied to each model's published rates

$1
$0.20
Haiku 4.5
$2
$0.39
Sonnet 5
$5
$0.98
Opus 4.8
Sticker input price
Real session-weighted price

Every model lands at roughly a fifth of its sticker input rate once the real cache-heavy mix of a Claude Code session is applied - a generic calculator quoting sticker price alone overstates all three by about the same multiple.

Sonnet 5's real session-weighted price lands around a fifth of its sticker input rate; the same discount applies to Opus and Haiku. A calculator that only quotes a model's input price - without applying the session's actual cache mix - overstates the real cost of every model by roughly the same multiple, which is why comparing models on sticker price alone gives a misleading picture of what switching would actually save.

Why a generic pricing calculator undershoots

Look at what a typical "Claude API pricing calculator" actually asks for: a token count and a model, then it multiplies. If you don't know Claude Code re-bills your whole history every turn, the number you'd naturally type in is the size of what you just typed - your actual prompt, not the accumulated session. On the 600,000-token session above, the fresh-input slice alone is only about 3,000 tokens. Price just that slice at Sonnet 5's input rate and you get a number roughly 39 times smaller than what the session actually costs, because the other 597,000 tokens - the cache writes and, overwhelmingly, the cache reads - never entered the calculation at all.

This isn't a knock on those tools being badly built. A single-request pricing calculator is solving a real, different problem: "what does this one API call cost." Claude Code sessions are a compounding sequence of calls that share a growing cache, and that's a session-level question a request-level calculator was never built to answer.

| | Generic API pricing calculator | A Claude Code session calculator | | --- | --- | --- | | What you enter | A token count you already know | Your usage pattern (sessions/day, workload, model) | | Buckets priced | Usually input + output | Fresh input, cache write, cache read, output | | Knows about re-sent context | No - prices one request | Yes - models what a whole session accumulates | | Answers | "What does this API call cost?" | "What does my Claude Code usage cost per month?" |

See it worked out for your own usage

The Claude Code Cost Calculator runs this exact four-bucket formula against a usage pattern you set - sessions per day, workload size, model - instead of a token count you'd have to already know, then compares the result to Pro, Max 5x, and Max 20x. It's still an estimate, built from a modeled session-composition mix, not a replacement for your real logs. For that, the free UsageCut scan reads your own transcripts directly and reports what your sessions actually cost, no modeling required.

Honest limits

This formula prices API-rate usage; it doesn't tell you what a flat-rate Pro or Max subscription is "worth" in the same units, because Anthropic doesn't publish a token-to-plan conversion - Max exists to raise a rate-limit ceiling, not to meter tokens. Whether the Max plan is worth it is a separate question the formula here can only inform, not settle. And Sonnet 5's current per-bucket rates carry introductory pricing through 2026-08-31 - re-check the published rates after that date rather than trusting a cached number, from this guide or anywhere else.

FAQ

  • Will a Claude Code cost calculator match what I actually get billed? Only roughly. It models a token load from a usage pattern or an average session composition, then prices it at Anthropic's published rates - your real files, prompts, and tool use will pull the true number up or down from there. A local scan of your own transcripts is the only way to get the exact figure instead of a modeled one.
  • Why do most Claude API pricing calculators give a lower number than what I actually see billed? Because they price a single request - usually just input and output - and have no way to know that Claude Code resends the entire session as context on every turn. If you plug in only the tokens you typed, you're pricing a small fraction of what actually gets billed.
  • What's the actual formula for Claude Code cost? (fresh input tokens x input price) + (cache write tokens x cache-write price) + (cache read tokens x cache-read price) + (output tokens x output price), summed across every turn of the session. Cache read is usually the largest bucket by token count; cache write is usually the most expensive per token.
  • Does the 1M context window change the formula? No - it changes how much can accumulate before compaction, not which buckets get billed or at what rate. A bigger window that fills up just means more cache-read tokens getting re-billed each turn.
  • Which model is cheapest for Claude Code once caching is accounted for? Rank order by sticker input price and by session-weighted effective price come out the same - Haiku, then Sonnet, then Opus - but the gap narrows once caching is applied, since cache reads are priced far below each model's input rate regardless of which model you pick.
  • How does this compare to what Pro or Max actually costs me? Pro and Max are flat monthly allowances gated by rate limits, not metered token buckets, so there's no exact conversion. This formula shows what the same usage would cost billed at raw API rates, which is the only fair number to weigh against a plan's flat price.

Every rate and every bucket above is real - Anthropic's currently published pricing and this project's own measured session mix, not a guess. Your own sessions won't match this worked example exactly, and the only way to know by how much is to look: run the free scan against your actual Claude Code history.

See your own numbers

These are aggregates from real sessions. Your setup is different - run the free scan and get the breakdown for your own Claude Code history. It runs locally; nothing about your code or prompts leaves your machine.

npx usagecutRun a free scan →

NeoMade by Neo

UsageCut by ClockedCode - not affiliated with Anthropic. The figures on this page are measured on real Claude Code sessions and labeled measured or estimated where it matters.