A 200k context window is not a feature you pay for once. You pay for it on every turn, and the price depends entirely on whether those tokens are fresh input, a cache write or a cache read. The table of what a full window costs per turn in each of the three states, and why the difference is roughly twentyfold.
the short version
A context window is not something you buy once. It is something the model re-reads on every single turn, and what that re-read costs depends entirely on which of three states those tokens are in. On Claude Opus 5, the gap between the cheapest state and the dearest is twentyfold for the identical 200,000 tokens.
three prices for the same tokens
Prompt caching prices are published as multipliers of each model's base input rate, which is the part worth committing to memory because it survives price changes:
So the same window has three prices depending on how it arrives. Fresh input is what you pay when nothing matched: a new session, or a changed prefix. A cache write is what you pay the first time a span is stored. A cache read is what you pay every time after that, for as long as the entry lives.
The caching is a prefix match, which is why coding agents land almost entirely in the third state. Turn twenty sends nearly the same first 100,000 tokens as turn nineteen did. Across 3.9GB of real Claude Code transcripts, the cache pricing post found 97.7% of all tokens were cache reads, and that 99.8% of the cache writes were the one-hour kind rather than the five-minute kind most tools assume. That is one machine over several months and the post says so, but it is the only real reading available and it is worth knowing before you read the table below.
the table
Claude Opus 5, at $5 per million base input. Two window sizes: 200,000 tokens, the size a working session tends to settle at, and 1,000,000 tokens, the full window the model supports.
Each of those is one multiplication, and here are four of them written out:
200,000 x $5.00 / 1,000,000 = $1.00 fresh input
200,000 x $6.25 / 1,000,000 = $1.25 5-minute write
200,000 x $10.00 / 1,000,000 = $2.00 1-hour write
200,000 x $0.50 / 1,000,000 = $0.10 cache readThere is no long-context premium to complicate this. Claude 4.6 and later models include the full one million token window at standard per-token pricing, so a 900,000 token request bills at the same rate per token as a 9,000 token one. The table scales linearly in both directions and you can read off any window size you like by hand.
what a long session costs
The per-turn figures only matter once you multiply them by a session. Take fifty turns, all carrying a full 200,000 token window, on Claude Opus 5. Ignore output for a moment, since it prices separately and is the same in all three cases:
That is the entire economics of a coding agent in one row. The window is not the expensive thing; the window arriving uncached is. And the corollary catches people out: a long session is cheap to continue and expensive to restart. Killing an agent and starting it again throws the cache away, so the new session pays $2.00 to write back what the old one was reading for ten cents a turn.
The same effect explains why several agents at once cost close to several times as much rather than a discount. Two agents on two worktrees diverge on their first turn, so their prefixes differ and neither reads the other's cache. Whatever else running several in parallel buys you, it does not buy cache sharing.
the same table on cheaper models
Because the three cache prices are multipliers of base input, the whole table rescales when you change model and its shape does not change at all. A 200,000 token window, per turn:
The Sonnet 5 introductory rate of $2 per million input runs through 31 August 2026, after which the published standard rate of $3 applies. Both rows are above so the table does not silently expire. Claude Haiku 4.5's context window tops out at 200,000 tokens, so its row is the largest window it has rather than a slice of a bigger one.
The ratio between the rows is the useful part. Carrying a full window on Haiku costs a fifth of carrying it on Opus, in every one of the three states. That is what makes model choice a bigger lever on a long session than almost anything you can do to the prompt, and it is why handing a review pass to a cheaper model is such a good trade: review is mostly input.
why you pay the write anyway
Seeing $2.00 against $0.10 makes the write look like the thing to avoid. It is not, and the break-even is published rather than estimated:
- A five-minute write costs 1.25x input and each read costs 0.1x, so write plus one read is 1.35x against 2x for sending the same span twice uncached. It pays off after a single read.
- A one-hour write costs 2x, so write plus two reads is 2.2x against 3x for three uncached sends. It pays off after two reads.
A coding session does dozens of reads against each write, so the question is never whether to cache. The one-hour entry costs 60% more to write and buys twelve times the lifetime, which is why an agent that pauses while you read a diff still finds its cache warm afterwards.
The trap that follows from this
Because a cache read is so cheap, the way to blow up a bill is not to send too many tokens. It is to invalidate the prefix. Any byte that changes near the front of the request invalidates everything after it, so a timestamp in a system prompt, a reordered tool list or a per-request identifier can turn every turn of a session from a $0.10 read into a $1.00 fresh send. That is a tenfold difference produced by a single line, and nothing in a token counter shows it as anything other than normal usage. Watching the ratio of reads to fresh input is the way it surfaces, which is the argument for metering continuously rather than reconciling later.
what the table does not say
These are list API prices. On a Pro or Max subscription you are not billed per token at all, so treat every figure here as what the same usage would have cost on the API. It is still the most useful measure of how much work you are pushing through, and it is the number that decides whether a subscription is worth it, but it is not an invoice. That comparison is worked through in the monthly cost post.
Output is priced separately and is not in the table. Every current Claude model charges 5x its input rate for output, which is $25 per million on Opus 5. A turn that writes 800 output tokens adds two cents on top of whatever the window cost. Output is small in token count and never small in the bill.
The window sizes are illustrative. Nothing here says your sessions run at 200,000 tokens. Read your own figure off your own transcripts and multiply; the table exists so the multiplication is the only step left.
common questions
What does a 200k context window cost?
On Claude Opus 5 at the list rates read 7 August 2026, 200,000 tokens cost $1.00 as fresh input, $1.25 as a five-minute cache write, $2.00 as a one-hour cache write, and $0.10 as a cache read. It is the same 200,000 tokens in all four cases; only how the model got them differs. In a session that is mostly cache hits, the read figure is the one you pay on nearly every turn.
Is a bigger context window more expensive per turn?
Yes, and linearly. There is no long-context premium on Claude 4.6 and later models, so a 900,000 token request bills at the same per-token rate as a 9,000 token one. Doubling the window doubles the per-turn cost of carrying it, whichever of the three prices you are paying. A full one million token window on Opus 5 is $0.50 a turn as a cache read and $5.00 a turn as fresh input.
How much does prompt caching actually save?
A cache read costs 0.1x the base input rate, so carrying a window as a read rather than as fresh input costs a tenth. A five-minute cache write pays for itself after a single read and a one-hour write after two, because the writes cost 1.25x and 2x input respectively. Over a fifty-turn session on a 200,000 token window, that is $6.90 against $50.00, a saving of 86%.