// blog/claude-1m-context-window-pricing-and-limits-explained
Claude 1M Context Window Pricing and Limits Explained


Anthropic made the 1M-token context window generally available for Claude Opus 4.6 and Sonnet 4.6 on March 13, 2026. Standard per-token rates now apply across the entire window. A 900K-token request is billed at the same per-token rate as a 9K one. Long context on Claude previously carried extra cost, and in Claude Code it required extra usage; both penalties are gone. That changes the math behind agent-harness decisions made under the old regime, including recall quality and where a bigger window helps.
What changed with general availability
The GA release bundles several changes, including pricing:
| Change | Before | Now |
|---|---|---|
| Pricing over 200K tokens | Long-context premium | Standard rate, no multiplier |
| Opus 4.6 | - | $5 / $25 per million tokens (input/output) |
| Sonnet 4.6 | - | $3 / $15 per million tokens |
| Rate limits at long context | Reduced | Full standard throughput at every context length |
| Media per request | 100 images or PDF pages | 600 |
| API opt-in | Beta header | None; requests over 200K just work |
| Claude Code | 1M required extra usage | Default for Max, Team, and Enterprise on Opus 4.6 |
Existing integrations can keep sending the beta header because it is ignored, so no code changes are required. Availability is broad from day one, on the Claude Platform natively plus Amazon Bedrock, Google Cloud's Vertex AI, and Microsoft Foundry.
Under the beta, long-context requests were a separate capacity question; teams running many concurrent million-token requests had to plan around it. With standard account throughput across the whole window, long context becomes another request type.
Does recall actually hold up at 1M tokens?
A million tokens of context is only useful if the model can find and reason over the right details inside it. Earlier long-context models often lost the middle of the window: the model recalled the beginning and end of the prompt and dropped what sat between.
Anthropic says Opus 4.6 scores 78.3% on MRCR v2, the highest among frontier models at that context length, and that both Opus 4.6 and Sonnet 4.6 maintain accuracy across the full window. MRCR-style benchmarks measure retrieval, or the ability to pull specific planted details out of a long haystack. They do not fully capture whether a model reasons as well when 800K tokens of partially relevant material compete for attention. Retrieval accuracy is necessary for long context to be useful, but it does not establish reasoning quality on its own.
The customer evidence in the announcement describes workloads where chunking was the previous workaround and removing it produced a measurable difference. Adhyyan Sekhsaria, a founding engineer on Devin, describes their Review agent: large diffs did not fit in 200K, so the agent chunked context, which meant more passes and lost cross-file dependencies. With 1M they feed the full diff and get higher-quality reviews from a simpler, more token-efficient harness. The chunking machinery added both a quality cost and a token cost because every extra pass re-read material the previous pass already saw.
Mauricio Wulfovich, an ML engineer at Eve, a legal AI company, describes cross-referencing a 400-page deposition transcript or surfacing connections across an entire case file. The relevant details are scattered, and chunked processing loses those connections because no single pass holds both ends of the reference.
The economics of compaction
Izzy Miller, an AI research lead, reports that raising their Opus context window from 200K to 500K made the agent use fewer tokens overall. Compaction adds costs in an agentic loop.
When an agent hits its context ceiling, summarization burns tokens and drops details the agent needs later. The agent then pays to rediscover them by re-running searches, re-reading files, and re-deriving conclusions it already reached. Anton Biryukov, a software engineer quoted in the post, describes Claude Code burning 100K+ tokens searching Datadog, Braintrust, databases, and source code before compaction removed details and sent the work in circles. Each lap repeats work already paid for.
Jon Bell, a CPO quoted in the announcement, reports a 15% decrease in compaction events after the change, with agents holding large PDFs and datasets intact and running for hours without losing what they read early on. The most damaging compactions happened when users loaded the large documents they needed because those loads exceeded the ceiling.
Carrying more context makes each request bigger, and in a multi-turn session the conversation gets re-sent on every turn. Prompt caching softens that cost but does not erase it. Compacting keeps requests small but repeatedly pays for rediscovery. For long-running agents doing investigation-style work, the reports above suggest rediscovery costs more than many teams assumed. Removing the long-context price premium makes carrying more context more attractive.
For scale: a single request with 900K input tokens costs about $4.50 on Opus 4.6 and $2.70 on Sonnet 4.6 at the new rates, before output tokens and caching discounts. The cost is linear and predictable, with no step function at 200K.
When a bigger window needs curation
The announcement says the engineering work, lossy summarization, and context clearing previously required for long-context work are no longer needed. They are no longer forced at 200K, but context still needs curation.
Every token carried is paid for on every subsequent request in the session; loading a corpus that is 95% irrelevant to the task creates recurring cost with no return. Relevance also competes with volume. A model that retrieves well from 1M tokens will reason better over 80K tokens of the right material than over 1M tokens where the right material is buried. Retrieval pipelines, subagents that read and return summaries, and deliberate context curation still matter for corpus-scale problems. The ceiling now represents a cost decision.
The full window works best for internally cross-referenced artifacts that lose meaning when split: large diffs with cross-file dependencies, deposition transcripts, multiple turns on the same 100-page agreement, and production incident investigations. Bardia Pourvakil, a co-founder and CTO quoted in the post, describes lawyers seeing the full arc of a negotiation in one session. Mayank Agarwal, a founder and CTO, describes keeping the relevant entities and working theory in view from first alert to remediation. These workloads depend on connections between distant parts of the material, and chunking severs those connections.
What this means for harness design
Existing agent scaffolding often treats the 200K limit as an architectural assumption: chunk-and-merge review pipelines, aggressive compaction schedules, and multi-pass document processing. For Opus 4.6 and Sonnet 4.6 users, that boundary no longer has its old price or location. Devin's Review agent replaced a chunked harness with a simpler single-pass harness that produced higher-quality reviews with fewer tokens.
Treat the compaction threshold as a tunable parameter and measure it. Miller's team moved from 200K to 500K, not the full million, and found their efficiency point there. Long agentic sessions will have workload-specific crossover points, and with no pricing multiplier or beta header, testing them requires a config change and a token report.