Claude's context window size is 1 million tokens on Opus 4.8, Sonnet 5, and Fable 5, and 200,000 tokens on Haiku 4.5. The 1M window is generally available at standard pricing, not a gated beta. Those are the specs. The more useful question: how much of that context does the model actually use well? Research from NVIDIA (RULER), Adobe (NoLiMa), and Chroma tells a more nuanced story about advertised context vs. effective context.
Every Claude Model's Context Window
Current Claude models split into two context tiers. Opus 4.8, Sonnet 5, and Fable 5 carry a 1M-token window; Haiku 4.5 carries 200K. The 1M window is generally available at standard per-token pricing, so the differences that remain are max output, price, and the 200K vs 1M split.
| Model | Context Window | Max Output | Input $/MTok | Output $/MTok |
|---|---|---|---|---|
| Claude Fable 5 | 1M | 128K | $10 | $50 |
| Claude Opus 4.8 | 1M | 128K | $5 | $25 |
| Claude Sonnet 5 | 1M | 128K | $3 ($2 intro) | $15 ($10 intro) |
| Claude Haiku 4.5 | 200K | 64K | $1 | $5 |
| Claude Opus 4.6 (legacy) | 1M | 128K | $5 | $25 |
| Claude Sonnet 4.6 (legacy) | 1M | 128K | $3 | $15 |
| Claude Sonnet 4.5 (legacy) | 200K | 64K | $3 | $15 |
Sonnet 5 introductory pricing of $2/MTok input and $10/MTok output runs through August 31, 2026, after which it lists at $3/$15. The 1M window no longer requires a beta header or a usage tier. On the Message Batches API, Opus 4.8, Opus 4.7/4.6, Sonnet 5, and Sonnet 4.6 support up to 300K output tokens via the output-300k-2026-03-24 beta header. Figures are from Anthropic's model docs (platform.claude.com), July 2026.
1M tokens is roughly 555,000 words or 2.5M Unicode characters; 200K is roughly 150,000 words, 500 pages, or 680,000 Unicode characters. For code, 200K holds about 50,000-70,000 lines and 1M holds about 250,000-350,000 lines depending on language density. Opus 4.8 and Sonnet 5 ship a 128K max output, double the older 64K limit, giving longer responses and larger thinking budgets.
Context Window vs Effective Context
A context window is how many tokens you can send. Effective context is how many of those tokens the model uses reliably. They are not the same number.
Chroma published one of the most comprehensive studies of this gap in July 2025, testing 18 models across controlled experiments. The headline finding: performance degrades at every context length increment, not just near the limit. A model with a 1M token window still exhibits measurable degradation at 50K tokens.
Adobe Research's NoLiMa benchmark (arXiv 2502.05167, ICML 2025) sharpens the point. It extends needle-in-a-haystack with needles that share almost no words with the question, forcing the model to infer the link rather than string-match. Under that harder test, 11 of 13 models that advertise at least 128K context dropped below 50 percent of their short-context baseline by 32K tokens, and GPT-4o fell from 99.3 percent to 69.7 percent. NoLiMa defines effective length as the longest context where a model keeps at least 85 percent of its base score, which lands far below the advertised window for every model tested.
The Lost-in-the-Middle Problem
Research from Stanford and others established the U-shaped attention curve. LLMs attend most strongly to tokens at the beginning and end of the context. Information in the middle gets deprioritized. This pattern holds across all transformer-based architectures.
Chroma's study added a counterintuitive finding: models performed better on shuffled, incoherent contexts than logically structured ones across all 18 models tested. The attention mechanism behaves differently with structural patterns, suggesting that coherent documents may actually make retrieval harder, not easier.
NVIDIA's RULER benchmark puts effective context at 50-65% of advertised capacity for most models. A model advertising 200K tokens typically becomes unreliable around 130K. Claude Opus 4.6 is a notable exception: its 76% score on MRCR v2 (finding 8 needles across 1M tokens) represents what Anthropic calls "a qualitative shift" in usable context, up from 18.5% for its predecessor.
Quadratic attention scaling means more tokens exponentially increase the pairwise relationships the model must track. Semantically similar distractors interfere with retrieval. And positional encoding degrades at distances not seen during training. No architecture change eliminates these effects. The question is which models degrade slowest.
How Claude Compares to GPT-4.1, Gemini, and Others
Claude no longer trails on raw window size. Opus 4.8 and Sonnet 5 ship 1M tokens, matching GPT-4.1's 1M and sitting under Gemini 2.5 Pro (1M, 2M coming) and Llama 4 Scout's claimed 10M. Haiku 4.5 stays at 200K as the fast tier.
On effective utilization, the picture separates from the spec sheet. Chroma's research found that Claude models "decay the slowest overall," while GPT models were "more erratic with random mistakes and outright refusals," and Gemini "starts to mess up earlier with wild variations."
| Model | Context Window | Max Output | Effective Context Notes |
|---|---|---|---|
| Claude Opus 4.8 | 1M | 128K | 1M GA at standard pricing; slowest decay lineage in Chroma study |
| Claude Sonnet 5 | 1M | 128K | 1M GA; $2/$10 intro pricing through Aug 31, 2026 |
| Claude Haiku 4.5 | 200K | 64K | Fast tier; 200K window, near-frontier quality |
| GPT-4.1 | 1M | 32K | 100% needle accuracy at 900K; erratic on complex tasks |
| Gemini 2.5 Pro | 1M (2M soon) | 64K | 99.7% recall at 1M; early degradation on reasoning |
| Gemini 3 Pro | 1M | 64K | 26.3% at 1M on own eval card |
| DeepSeek V4 Flash | 1M | varies | 1M context; NoLiMa-class decay untested at length |
| Llama 4 Scout | 10M | varies | Largest window; limited independent benchmarks |
| Mistral Large 3 | 256K | varies | Mid-range window, competitive pricing |
GPT-4.1 claims 100% needle accuracy at 900K tokens, but needle-in-a-haystack tests measure retrieval of a single planted fact, not reasoning over distributed information. Chroma's study found GPT models had the highest hallucination rates when distractors were present and a 2.55% task refusal rate. Gemini 2.5 Pro reports 99.7% recall at 1M tokens on Google's own benchmark, but Gemini 3 Pro dropped to 26.3% at 1M on its own model evaluation card.
The numbers reveal a pattern: models perform well on the benchmarks their makers design. Independent evaluations like Chroma's paint a less optimistic picture for every model.
Prompt Caching: 90% Cost Reduction
Prompt caching is Anthropic's mechanism for reusing processed context across API calls. Instead of reprocessing the same system prompt, documents, or conversation history on every request, the API reads from cache at a fraction of the cost.
The economics are straightforward. A cache write costs 1.25x base input price for a 5-minute TTL, or 2x for a 1-hour TTL. Cache reads cost 0.1x base input price. For Sonnet 5 at $3/MTok list input, that means a cache read costs $0.30/MTok, 10x cheaper than reprocessing. The break-even is two API calls for 5-minute caching.
| Operation | Multiplier | Sonnet 5 Cost | Opus 4.8 Cost |
|---|---|---|---|
| Standard input | 1x | $3/MTok | $5/MTok |
| 5-min cache write | 1.25x | $3.75/MTok | $6.25/MTok |
| 1-hour cache write | 2x | $6/MTok | $10/MTok |
| Cache read (hit) | 0.1x | $0.30/MTok | $0.50/MTok |
For a concrete example: a 100K token system prompt with documents drops from 11.5 seconds to 2.4 seconds with caching. An application making 100 API calls per hour with a shared 50K token system prompt saves roughly $14.25/hour on Sonnet 5 list pricing versus reprocessing.
Caching does not just reduce cost. It changes how you architect context. When repeated context is nearly free, you can include more reference material, longer system prompts, and richer examples without the cost penalty. The effective context budget shifts from "what can I afford to send" to "what should the model see."
Extended Thinking and Context
Extended thinking lets Claude reason through problems before responding. The thinking tokens are billed as output but count toward the context window during the current turn. The critical detail: previous thinking blocks are automatically stripped from context in subsequent turns.
This means a multi-turn conversation where Claude thinks for 20K tokens per turn does not accumulate 100K tokens of thinking across 5 turns. Each turn's thinking is discarded before the next, so reasoning does not eat your context window over time.
Thinking Tokens Are Ephemeral
Previous thinking blocks are stripped automatically. A 10-turn conversation with 20K thinking tokens per turn uses the same context as one without thinking, plus the current turn's allocation.
Context Awareness
Recent Claude models receive live token budget updates after each tool call. The model knows exactly how much context remains and paces itself accordingly.
Opus 4.8 and Sonnet 5 support 128K max output tokens, double the older 64K limit, and up to 300K on the batch API via the output-300k-2026-03-24 beta header. This gives extended thinking more room to reason through complex problems without hitting output limits. The thinking budget is set via the budget_tokens parameter, and with adaptive thinking, Claude dynamically decides how much thinking each request needs.
How Much Code Fits in 200K Tokens
Token-to-code ratios vary by language. Python and JavaScript average about 2.5-3.5 tokens per line of code. Verbose languages like Java run higher. Comments and docstrings add overhead. Here are practical estimates:
| Context Size | Lines of Code (est.) | Equivalent Project |
|---|---|---|
| 32K tokens | ~10,000-13,000 lines | Single large module or small library |
| 128K tokens | ~40,000-50,000 lines | Medium application or framework component |
| 200K tokens | ~50,000-70,000 lines | Full medium-sized codebase |
| 1M tokens | ~250,000-350,000 lines | Large monorepo or enterprise application |
A typical React project with 200 files averaging 150 lines (30,000 total lines) fits comfortably in 200K tokens. A 100,000+ line enterprise codebase does not. But fitting everything into context is usually the wrong approach.
Cognition (makers of Devin) measured that their AI coding agent spent 60% of its time searching for code before making changes. The bottleneck was not context window size. It was finding the right code to put in context.
Putting 200K tokens of code into context when you only need 5K tokens of relevant code produces worse results than sending just the 5K. Context rot means more input tokens degrade output quality. The goal is not to fill the window. It is to fill it with the right content.
Context Engineering > Context Size
The context window arms race, from 4K to 200K to 1M to 10M, misses the point. Chroma's research demonstrated that performance degrades at every length increment across all 18 models tested. Bigger windows give you capacity, not quality.
Context engineering is the practice of curating what goes into the window: selecting relevant information, removing noise, structuring content for attention patterns, and managing token budgets across multi-turn interactions. Anthropic's own documentation states that Claude "achieves state-of-the-art results on long-context retrieval benchmarks, but these gains depend on what's in context, not just how much fits."
Practical strategies
Semantic Search Before Context Loading
Find the relevant code first, then load it into context. Tools like WarpGrep use RL-trained search to find relevant code in 3.8 steps (0.73 F1) vs. 12.4 steps for baseline approaches, reducing both latency and unnecessary context consumption.
Prompt Caching for Stable Context
Cache system prompts, documentation, and reference code. Pay the write cost once, then read at 10% of input price. Keeps your effective context budget high without the cost of reprocessing.
Efficient Code Edits
Code editing is one of the highest-token operations in agent workflows. Fast Apply generates edits at 10,500 tok/s with 98% accuracy, reducing the output token cost of applying changes to files.
Subagent Isolation
Delegate search, testing, and analysis to subagents with isolated context windows. The main agent receives only the summary, keeping its context clean. Up to 10 concurrent subagents give you an effective 2M tokens across isolations.
Context Compression
When a conversation grows past the effective-context ceiling, compress it instead of truncating. Morph Compact shrinks context 50-70% at 33,000 tok/s while keeping surviving sentences verbatim, so a 1.5-minute compaction pass finishes in about 2.5 seconds.
The models with the biggest context windows are not always the best choice. A 200K window filled with precisely relevant code outperforms a 1M window filled with an entire repository. The tooling that selects and shrinks what goes into context determines outcomes more than the window itself. Morph Compact handles the shrinking; if you want a raw 1M-token window on an open-weight model, Morph also serves GLM-5.2 and DeepSeek V4 Flash at 1M context through one OpenAI-compatible API.
Frequently Asked Questions
What is Claude's context window size?
Claude Opus 4.8, Sonnet 5, and Fable 5 have a 1 million token context window; Haiku 4.5 has 200,000 tokens. The 1M window is generally available at standard per-token pricing as of March 2026, not a gated beta. 1M tokens holds roughly 555,000 words; 200K holds roughly 150,000 words or 500 pages. Source: Anthropic model docs (platform.claude.com), July 2026.
How does Claude's context window compare to GPT-4.1 and Gemini?
Opus 4.8 and Sonnet 5 have a 1M window, matching GPT-4.1. Gemini 2.5 Pro has 1M with 2M coming. Raw size no longer separates them, so effective context is the deciding metric: NVIDIA's RULER puts usable context at 50-65 percent of advertised, and Adobe's NoLiMa found most models drop below half their short-context score by 32K tokens. Chroma's research found Claude models decay the slowest.
What is prompt caching and how much does it save?
Prompt caching lets you mark context for reuse across API calls. Cache reads cost 10% of standard input price, saving up to 90% on costs and 85% on latency. A 100K token prompt drops from 11.5s to 2.4s with caching. The break-even is two API calls for 5-minute caching, one call for any frequently used context.
Does Claude's performance degrade with longer contexts?
Yes. All LLMs exhibit context rot. The lost-in-the-middle effect means information in the center of context gets deprioritized. Claude Opus 4.6 made significant progress, scoring 76% on MRCR v2 vs. 18.5% for its predecessor, but degradation still occurs at every length increment. The practical response is context engineering: sending relevant content rather than maximizing volume.
How much code fits in Claude's 200K token context window?
Approximately 50,000-70,000 lines of code. A medium-sized project (200 files, 150 lines each) fits comfortably. A large enterprise codebase (100K+ lines) does not. For large codebases, semantic search tools that find relevant code before context loading produce better results than trying to fit everything in.
What is the pricing for Claude's 1M token context window?
As of March 2026, Anthropic removed the long-context surcharge. The 1M window bills at standard per-token rates across its full length: Opus 4.8 at $5/$25 per MTok, Sonnet 5 at $3/$15 ($2/$10 introductory through August 31, 2026). A 900K-token request costs the same per-token rate as a 9K one. The old 2x-input, 1.5x-output premium above 200K no longer applies. Prompt caching multipliers still apply on top.
Related Reading
- Context Rot: Why LLMs Get Worse with More Input
- LLM Context Window Comparison (2026)
- LLM Context Windows Explained
- Context Engineering for AI Agents
- Morph Compact: Context Compression at 33,000 tok/s
- GLM-5.2: 1M-Token Open-Weight Model on Morph
- DeepSeek V4 Flash: 1M Context on Morph
- WarpGrep: Semantic Codebase Search
Better Context, Not More Context
WarpGrep finds relevant code in 3.8 steps (0.73 F1) so your agent fills its context window with signal, not noise. Fast Apply generates code edits at 10,500 tok/s. Both work with Claude, GPT, Gemini, or any LLM.
