What Claude Code actually charges per token, rate by rate
8 min read

On this page
Claude Code bills five separate per-token rates, not one: base input, a 5-minute cache write, a 1-hour cache write, a cache read, and output, each priced on its own and charged fresh every turn. For Sonnet 5, the model Claude Code runs by default today, those come to $2, $2.50, $4, $0.20, and $10 per million tokens. Almost everything a session re-sends after its first message bills at that $0.20 cache-read rate, not the $2 you'll see quoted everywhere else - which is why the input price alone tells you almost nothing about what a session actually costs.
/usage line (1.2k input, 5.3k output, 940K cache read, 50K cache write) comes out to about $0.37, roughly 82% less than the same tokens would cost with caching off entirely. Rate table and the full math are below.What Claude Code actually charges per token right now
Anthropic prices five things per model, per million tokens: base input, a 5-minute-TTL cache write, a 1-hour-TTL cache write, a cache read, and output. Fetched fresh from Anthropic's own pricing page for the three models Claude Code actually offers you a choice between:
Anthropic's currently published pricing, fetched 2026-08-17
The multipliers are the constant part: a 5-minute cache write always costs 1.25x the base input rate, a 1-hour write always costs 2x, and a cache read always costs 0.1x - across Opus, Sonnet, and Haiku alike. Only the dollar amount underneath the multiplier changes with the model. That's worth knowing on its own, because it means switching models moves every one of your five rates by the same ratio at once, not just the one you were thinking about.
One honesty check before the math: these are the API's published per-token rates, and they're also exactly what Claude Code's /usage command uses to compute the dollar figure it shows you. If you're on a Pro or Max subscription, that figure is informational - your seat is a flat monthly allowance, not a per-token bill - but it's still computed from these same rates, so everything below explains where that number on your screen actually comes from either way.
Why cache reads are nearly all of your bill but not most of the cost
Claude Code has no memory between API calls. Every turn resends the whole conversation so far, and anything already sitting in the prompt cache from a previous turn comes back as a cache read instead of fresh input. On a session that runs more than a couple of turns, that means the overwhelming majority of what gets billed is cache-read tokens, not anything you actually typed.
Measured on this project's own 1,037 real Claude Code sessions
The reason cache-read dominance and cost dominance aren't the same thing comes straight from the multipliers above: a cache write at 1.25x-2x is the most expensive of the five rates per token, while a cache read at 0.1x is the cheapest. On this project's own measured Claude Code history (1,037 real sessions, deduped by message id, priced at Opus rates), cache-read tokens are 93.9% of everything billed but only 44.0% of the dollar cost - while cache-write tokens are a mere 4.9% of tokens but 37.8% of the cost, nearly as much as cache-read despite being twenty times smaller by volume. Fresh input and output, the two rates every generic pricing calculator actually prices, are a combined 1.2% of tokens and 18.2% of cost. Volume and price pull in opposite directions, and the write rate is why: it costs more per token specifically so that a read a few turns later can cost almost nothing.
What a real session costs, rate by rate
Anthropic's own cost-tracking documentation ships a real example of what /usage prints for a session: 1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write, priced there at an older Sonnet generation for a $0.55 total. I ran that exact token breakdown back through the math at Sonnet 5's current rates, since Sonnet 5 is what Claude Code actually defaults to now:
1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write
Two things stand out. First, the $0.125 cache-write line and the $0.188 cache-read line together account for 85% of the total, even though the cache-write tokens are only 5% of the token count - the same write-expensive, read-cheap pattern from the section above, just on one concrete session instead of a corpus average. Second, the counterfactual: if none of those 940,000 cache-read tokens and 50,000 cache-write tokens had been cached at all - if every one of them had gone through the API as plain fresh input instead - the same session would have cost $2.04, not $0.37. Prompt caching isn't a minor optimization on top of the sticker price here; for a session shaped like this one, it's the difference between $0.37 and $2.04 for identical work.
What actually moves the per-token number down
Nothing here changes which five rates apply - only which ones you actually pay for, and how much of each:
- The 1-hour cache only pays for itself with reuse. A 1-hour write costs 2x input versus 1.25x for a 5-minute write, so it only comes out ahead if you'll read that content back at least twice within the hour. A single long-running session that reads its own history on every turn clears that bar easily; a string of short, unrelated sessions usually doesn't.
- Model choice moves all five rates together. Dropping from Opus to Sonnet or Haiku doesn't just cut the input price - it cuts the cache-write and cache-read rates by the same ratio, which matters more than it looks like given how much of a session's tokens are cache reads.
- Subagents don't get to use the longer TTL. Subagent transcripts run on the 5-minute cache regardless of what TTL the main session is using, so a workflow that fans out to a lot of subagents pays the 1.25x write rate more often than a single-thread session doing equivalent work. Reducing Claude Code's context window usage covers the setup habits that shrink what gets cached in the first place, which is the lever underneath all five rates at once.
/cleardoesn't reprice anything already paid for - it just stops paying for it going forward. Clearing mid-task throws away a cache you already paid the write premium on; if you'll need that context again soon, you eat another write instead of reusing the read you already earned.
If your bill still looks high after accounting for all of this, the rates aren't the problem - what's actually accumulating in context before it gets cached is. Why Claude Code token usage runs high covers that side of it, separately from the per-token math here.
Flat plans, clouds, and the other billing exceptions
This is API-rate math, and a few real setups don't run on it cleanly. On a Claude for Teams or Enterprise seat, usage draws from a shared per-seat allowance on a rolling window rather than metering these five rates directly against a bill - the rates still compute what /usage shows you, but they aren't what you're actually charged. On Amazon Bedrock, Google Cloud, or Microsoft Foundry, pricing runs through each cloud's own marketplace conversion and regional multipliers instead of the numbers above. Claude 4.6-and-later models running with inference_geo: "us" carry a flat 1.1x multiplier across all five rates, on top of everything else here. And the Batch API's 50% discount doesn't apply to Claude Code at all - Claude Code is an interactive session, and batch pricing is for asynchronous, non-time-sensitive requests.
FAQ
- What does Claude Code actually charge per token? Five separate rates: base input, a 5-minute cache write (1.25x input), a 1-hour cache write (2x input), a cache read (0.1x input), and output. The dollar amount under each depends on the model; the multipliers between them don't.
- Why is my bill mostly cache-read tokens if cache reads are the cheapest rate? Because Claude Code resends your whole conversation every turn, and by the second or third turn almost all of that resend is content already sitting in cache. High token volume at a low per-token rate can still add up to a large share of the dollar total - on this project's own measured sessions, cache reads are 93.9% of tokens and 44.0% of cost.
- Is cache write really more expensive than a regular input token? Yes - 1.25x the base input rate on a 5-minute cache, 2x on a 1-hour cache. It costs more specifically because it's what makes every later read of that same content cost 90% less; caching pays for itself after one read on the 5-minute tier or two reads on the 1-hour tier.
- Do these rates apply if I'm on the Pro or Max plan? Not as a direct bill - your seat is a flat monthly allowance, not a per-token charge. But
/usagestill computes its dollar figure from these exact rates, so they're what that number on your screen is built from either way. - Does switching models change the cache rates too, or just the input price? All five rates move together by the same ratio when you switch models - input, both cache-write tiers, cache read, and output all scale off the same base price, so a model switch reprices your whole session, not just the part you were thinking about.
Every rate above came straight from Anthropic's currently published pricing and this project's own measured session data, not a modeled guess. The real four-bucket cost formula walks through combining these rates into a full session estimate if you want to work out your own number by hand, or the interactive cost calculator runs the same math for a usage pattern you set. For the exact split your own sessions actually run, the free UsageCut scan reads your real transcripts directly instead of estimating from an average.
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 →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.