Claude Code's 1M context window: does it save tokens, or just delay the bill?
10 min read

On this page
Claude Code's 1M-token context window is worth using when a task genuinely needs one continuous thread that long - a large-codebase refactor, a big log traced start to finish - and on the current default models it costs nothing extra: Sonnet 5 runs at 1M on every plan with no toggle, no usage credits, no configuration. What it isn't is a cheaper way to run Claude Code. Every token already sitting in that window gets re-billed as a cache read on the very next turn, so a longer ceiling mostly changes how far you can let context grow unmanaged before you're forced to pay for compacting it - not whether you pay for carrying it.
[1m] flag to set; Opus 4.6 and later gets the same free upgrade automatically on Max, Team, and Enterprise, but needs purchased usage credits on Pro; Sonnet 4.6's 1M needs usage credits on every plan, Max included. None of that changes the actual cost driver: resending an already-large context bills as a cache read every single turn. A modeled 40-turn session that grows from 20K to 900K tokens racks up $3.68 in cache-read billing alone, just to keep re-sending what's already there - see the math below, or run the cost calculator on your own numbers.Does the 1M context window cost more, per token?
Not per token. Anthropic's pricing documentation is explicit on this: "Claude 4.6 and later models... include the full 1M token context window at standard pricing. A 900k-token request is billed at the same per-token rate as a 9k-token request." There's no long-context multiplier the way there used to be for some earlier previews - the input, cache-write, and cache-read rates at token 900,000 are identical to the rates at token 9,000.
That's the part the Reddit thread sitting at position one for this search gets half right and half wrong. It's right that the window "just being bigger" doesn't mean Anthropic is quietly charging more per token for the privilege. It's wrong to call the whole thing marketing, though, because there's a real gate - it just isn't a pricing multiplier. It's usage credits: a separate purchased allowance, charged on top of a flat subscription, that some model-and-plan combinations require before the 1M window turns on at all. Whether you hit that gate depends entirely on which model you're running, which the next section breaks down plan by plan.
Which models get it for free, and on which plan
| | Pro | Max, Team, and Enterprise | | --- | --- | --- | | Opus (4.6 and later) | Requires usage credits | Included with subscription | | Sonnet 4.6 | Requires usage credits | Requires usage credits | | Sonnet 5 | Included - always 1M, no toggle, no credits | Included - always 1M, no toggle, no credits |
Claude Code's own defaults mean most people asking whether this is "worth it" never hit the usage-credits case at all. Max, Team Premium, and Enterprise pay-as-you-go seats default to Opus 5, which gets the free 1M upgrade automatically on those plans - no configuration. Pro, Team Standard, and Enterprise subscription seats default to Sonnet 5, which is always 1M on every plan, Pro included, with no [1m] variant to select and no credits to spend. Usage credits only enter the picture if you manually pin an older Sonnet 4.6 on any plan, or manually select Opus while on Pro instead of staying on the Sonnet 5 default. Run /context in a session to see which window is live - it reports Xk/1000k when the 1M window is active, Xk/200k when it isn't.
Bigger window, same compounding cost
A ceiling number can't tell you this part: nothing about a bigger window changes what a single turn costs to run. Claude Code has no memory between API calls - every turn resends the full conversation so far, and everything already in that history gets billed again as a cache read (at 10% of the base input rate, per Anthropic's caching pricing - how caching and compaction actually work goes deeper on the mechanics). A window that goes from 200K to 1M doesn't shrink that resend. It just lets the resend get eight times larger before anything forces a reset.
Sonnet 5 rates ($0.20/MTok cache-read) - the window ceiling never enters this math
Modeled over a full session - 40 turns climbing in a straight line from 20K to 900K tokens - the cache-read bill for just re-sending what's already there sums to 18,400K cache-read tokens, or $3.68. Computed from the rates above and a modeled linear climb, not a measured session.
The curve above uses Sonnet 5's current published rates ($2/MTok base input through August 31, 2026, so $0.20/MTok for a cache-read hit). Resending 50K tokens of context costs about a cent. Resending 900K - comfortably inside the 1M window, and close to Sonnet 5's own default auto-compaction point around 967K tokens - costs about 18 cents, on that one turn alone, before a single new word gets typed.
Model a full session instead of one turn: 40 turns where context climbs in a straight line from 20K to 900K tokens, a plausible shape for one long, unmanaged conversation that never compacts. Summing the cache-read bill for every turn along that climb comes to 18.4 million cache-read tokens - $3.68 just to keep re-sending context that was already there, before fresh input, cache-write, or a single output token is counted. That's a computed worked example from Sonnet 5's published rates and a modeled linear growth curve, not a measured session - but the rates and the arithmetic are real.
The same 40 turns of work capped at the old 200K ceiling can't climb anywhere near that far before hitting the wall - at this growth rate, compaction kicks in around turn nine. So the smaller window isn't cheaper by avoiding the climb; it pays a compaction instead, roughly every eight or nine turns, and each one bills its own cache-write to re-store the summarized history plus the output tokens the summary costs to generate. The 1M window doesn't remove that bill. It lets you defer it into one longer climb instead of four or five shorter ones - which is a real, useful trade for some tasks, and not a savings for any of them.
Context rot: the cost you pay before you hit the ceiling
There's a cost that shows up before the dollar one, and it isn't billed in tokens. Anthropic's own context-window documentation names it directly: "as token count grows, accuracy and recall degrade, a phenomenon known as context rot... this makes curating what's in context just as important as how much space is available." A bigger ceiling doesn't touch that curve - if anything it gives a session more room to drift before anything forces a reset that would otherwise clean the slate.
This is the trade a "just use the 1M window" instinct usually skips: the alternative to filling 900K tokens with a session's entire meandering history isn't only "hit a wall sooner." It's also "compact more often, which keeps working context smaller and more relevant, on top of costing less to resend." A wider window makes it easier to postpone that trade. It doesn't make postponing it free.
When the 1M window is actually the right call
One continuous task
A long trace, a wide refactor, a big diff reviewed in one pass
1M genuinely helps - free on Sonnet 5
Many small, unrelated turns
Exploration, trial-and-error, back-and-forth across unrelated files
Bigger ceiling just compounds cache-read cost and context rot
None of this makes the window useless - it makes it situational. A single continuous task that genuinely needs one unbroken thread that long (tracing a bug end to end through a large log, reviewing a big diff in one pass, refactoring across a wide codebase without losing earlier findings to compaction) is exactly what a bigger ceiling is for, and on Sonnet 5 it costs nothing extra to have available. A session built from many small, independent turns - exploration, trial-and-error, back-and-forth on unrelated files - gets worse, not better, from a bigger ceiling: it just means more unrelated history sitting in context, compounding the cache-read bill and the context-rot curve on every later turn, for no benefit to the task at hand.
What this math doesn't cover
The 18-cents-per-turn and $3.68-per-session numbers above are a modeled worked example at Sonnet 5's current published rates, not a measurement from real transcripts - a real session's cost also includes fresh input, cache-write, and output tokens this example deliberately isolated to make the cache-read compounding visible on its own. Usage-credit pricing and per-plan access can change; check /context and your plan's current terms before assuming which side of the table you're on.
Skip reaching for the 1M window at all if a session is short by nature - most day-to-day work never gets near 200K tokens in the first place, and turning on a bigger ceiling for a session that was never going to hit the old one changes nothing. And if a session keeps growing past where it should, the 1M window is the wrong fix for that on its own: it postpones the wall instead of asking why the same task keeps accumulating unrelated history turn after turn - the fuller list of context-reduction levers covers the fix for that shape of problem. A task that needs 900K tokens of continuous context needs it regardless of what it costs to carry - the window just shouldn't be the first thing reached for.
FAQ
- Does Claude Code's 1M context window cost extra per token? No - Anthropic's pricing docs confirm the 1M window uses standard per-token rates with no long-context premium. What can cost extra is access itself: some model-and-plan combinations (Sonnet 4.6 on any plan, Opus on Pro) require purchased usage credits before the window turns on.
- Does Sonnet 5 need a
[1m]flag or usage credits for 1M context? No. Sonnet 5 always runs at 1M context, on every plan including Pro, with no variant to select and no credits required - it's simply the model's context window. - How do I check which context window my session is actually using? Run
/contextinside a session. It reportsXk/1000kwhen the 1M window is active, orXk/200kwhen it isn't. - Does a bigger context window make Claude Code cheaper? No - it changes when compaction forces a reset, not what resending context costs per turn. Every token already in context still bills as a cache read on the next turn, at 10% of the base input rate, whether the ceiling is 200K or 1M.
- What is context rot? Anthropic's own documentation for it: as token count in a session grows, the model's accuracy and recall degrade. A bigger context window doesn't fix this - it just makes it easier to keep going past the point where it started.
- When does the 1M window actually help? For one continuous task that genuinely can't be split - a long trace, a big diff, a wide refactor - where losing earlier findings to compaction would cost more than the extra context does. It's the wrong fit for sessions built from many small, unrelated turns, where a bigger ceiling just lets unrelated history keep compounding the cache-read cost.
The free scan reads the same kind of session history this math is built from, and turns it into your own numbers instead of a modeled example - nothing about it leaves your machine. If a plan upgrade is the real question underneath this one, what the Max plan actually buys you is worth reading next.
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.