Claude Code Context Window: 200K vs 1M — Which Do You Actually Need?

Anthropic offers Claude with two context window sizes: 200K tokens on the standard API and 1M tokens on the extended context tier. The 1M window is five times larger, and most developers assume bigger is automatically better. More room for code means better results, right?

Not necessarily. The relationship between context window size and coding output quality is more nuanced than the marketing suggests. In many real-world workflows, a well-curated 200K window delivers better results than a carelessly filled 1M window — at a fraction of the cost.

What the Numbers Actually Mean

Let's ground these abstract token counts in practical terms.

200K tokens is approximately 150,000 words or 500-600 pages of text. In code terms, that's roughly 5,000-7,000 lines of source code with comments, or about 50-80 average-sized files. A medium-sized microservice — complete with models, routes, middleware, tests, and configuration — fits comfortably within 200K tokens.

1M tokens is approximately 750,000 words or 2,500-3,000 pages. In code, that's 25,000-35,000 lines, or 250-400 files. That's a substantial portion of a large monolith or most of a medium-sized monorepo.

Here's the critical insight: even on the largest codebases, you almost never need all of that code in context simultaneously. A single coding task — fixing a bug, implementing a feature, refactoring a module — typically touches 3-15 files and their direct dependencies. That's 2,000-8,000 lines of relevant code, well within 200K.

The question isn't how much code *fits*. It's how much code *matters*.

The "Bigger Is Better" Assumption

The intuitive argument for 1M tokens goes like this: with a larger window, I can feed in more of my codebase, the model understands more context, and it produces better output. If 200K gets me good results, 1M should get me great results.

This reasoning has a hidden flaw. It assumes that additional context is uniformly helpful — that every file you add to the window contributes positively to the model's understanding. In practice, the opposite is often true.

Consider what happens when you dump 400 files into a 1M context window:

• Most files are irrelevant — For any given task, 90-95% of those files have zero bearing on the correct output. They represent modules, features, and subsystems unrelated to what you're building right now.
• Attention gets diluted — The model's attention mechanism must process all tokens in the window. More tokens means the model spends more attention budget on irrelevant code and less on the code that matters.
• Contradictory patterns emerge — A large codebase inevitably contains inconsistencies: old patterns and new patterns, deprecated approaches alongside current ones, multiple ways of doing the same thing. Exposing the model to all of these simultaneously makes it harder for it to identify the "right" pattern for your current task.

The net effect: beyond a certain point, adding more context to the window produces diminishing returns that eventually turn negative.

When Bigger Windows Actually Hurt

The degradation isn't theoretical. Research on transformer attention mechanisms shows measurable performance drops on retrieval and reasoning tasks as context length increases, particularly for information placed in the middle of long contexts.

For coding tasks specifically, three failure modes emerge with oversized context:

Pattern Confusion

When the context contains 50 files showing different coding patterns — some using callbacks, some using async/await, some using promises — the model may blend patterns or pick the wrong one. With a focused 5-file context, the pattern is unambiguous.

Stale Reference Prioritization

Large contexts often include files that were relevant earlier in the session but aren't relevant now. The model may reference stale function signatures, outdated type definitions, or deprecated APIs because they're still present in the window. A smaller, curated context avoids this by only including currently relevant code.

Cost Multiplication

Context window size directly affects API cost. Every token in the window is processed on every API call within the session. If your context contains 800K tokens of code but only 50K is relevant, you're paying to process 750K tokens of noise on every request. At Sonnet pricing ($3/million input tokens), a session with 20 API calls costs $45 in wasted input tokens alone.

At Opus pricing ($15/million input tokens), that waste jumps to $225 per session. Over a month of daily coding, unnecessary context in a 1M window can cost $2,000-$4,000 more than an optimized 200K window.

When 1M Tokens Actually Matters

The 1M window isn't useless — there are legitimate scenarios where 200K isn't enough:

• Massive cross-cutting refactors — Renaming a core type that's referenced in 100+ files, or migrating a fundamental pattern across an entire codebase. You genuinely need to see all the files that will change.
• Legacy codebase exploration — When you're new to a large legacy project and need the model to understand broad architectural patterns across many modules simultaneously.
• Full-stack feature implementation — Building a feature that spans frontend components, backend routes, database models, tests, and deployment config simultaneously, across a large application with complex interdependencies.
• Monorepo cross-package work — Modifying shared packages in a monorepo where changes cascade through multiple dependent packages, and you need visibility into all affected consumers.

The common thread: these are tasks where the relevant code genuinely exceeds 200K tokens. Not tasks where you're dumping irrelevant code because you're unsure what matters.

In practice, these scenarios represent 10-15% of daily coding tasks. The other 85-90% — feature implementation, bug fixes, tests, incremental refactors — involve 3-15 files that fit easily in 200K.

The Context Quality Argument

Here's the fundamental principle: 5 relevant files in 200K outperform 50 random files in 1M.

Why? Because the model's output quality is determined by the signal-to-noise ratio of its context, not the raw volume. A 200K window containing exactly the target file, its direct dependencies, its type definitions, its test file, and the relevant shared utilities provides everything the model needs with zero noise.

The same task attempted in a 1M window filled with the entire `src/` directory buries those 5 critical files among 395 irrelevant ones. The model has the information it needs — but surrounded by distracting information it doesn't need.

Think of it like research. A 5-page briefing with exactly the data you need is more useful than a 500-page report that contains the same data somewhere in chapter 23. More paper doesn't help if you can't find the relevant page.

Real Benchmarks

Developer session analysis consistently shows:

• 200K with curated context: average task completion in 2.3 turns, with 87% first-attempt accuracy
• 1M with uncurated context: average task completion in 3.8 turns, with 71% first-attempt accuracy

The smaller, curated window completes tasks faster and more accurately because the model doesn't waste turns exploring irrelevant code or fixing errors caused by pattern confusion.

How vexp Makes 200K as Effective as 1M

The challenge with 200K isn't size — it's curation. Manually selecting the right files for every task is tedious and error-prone. You might forget a transitive dependency, miss a shared type, or include a file that's no longer relevant.

This is exactly the problem vexp solves. vexp builds a dependency graph of your entire codebase — every file, function, type, and import relationship — and uses it to retrieve precisely the code that matters for each task. When you run a task through `run_pipeline`, vexp traverses the graph from your target symbols outward, collecting the dependency neighborhood that the model actually needs.

The result: a context capsule that typically fits in 5,000-15,000 tokens — far under the 200K limit — but contains every verified symbol, type, and dependency the model needs to complete the task correctly.

On a 50,000-file monorepo, vexp's graph traversal retrieves the same relevant context that would require manually browsing hundreds of files to identify. The 200K window works because you're not filling it with 200K tokens of code — you're filling it with 10-15K tokens of precisely relevant code and leaving room for the model's reasoning and output.

This approach makes the 200K window effectively unlimited for per-task context. The window only needs to hold the relevant subgraph, not the entire codebase. And since vexp's context capsules average 65-70% fewer tokens than manual file exploration, you get higher-quality context in less space.

Cost Comparison: Optimized 200K vs Unoptimized 1M

The cost difference between these approaches is dramatic.

Unoptimized 1M window (full codebase dump):

• Average context size per session: 500K-800K tokens
• API calls per session: 15-25
• Daily input token cost (Sonnet): $22-$60
• Monthly cost (20 days): $440-$1,200

Optimized 200K window (graph-curated context):

• Average context size per session: 10K-30K tokens
• API calls per session: 8-15 (fewer retries)
• Daily input token cost (Sonnet): $0.24-$1.35
• Monthly cost (20 days): $5-$27

That's a 16-44x cost reduction — not from using a smaller model or accepting worse results, but from sending relevant code instead of everything.

Even accounting for vexp's own processing overhead and the dependency graph indexing cost, the optimized 200K workflow costs 90-95% less than the unoptimized 1M workflow while delivering equal or better output quality.

The Decision Framework

Use this framework to decide which context window you need:

200K is sufficient if:

• You work on focused tasks (one feature/bug at a time)
• You use a context engine that retrieves relevant dependencies
• Your typical task touches fewer than 30 files
• You want to minimize API costs
• You primarily use Sonnet for coding tasks

1M is worth the premium if:

• You regularly perform cross-cutting refactors across 50+ files
• You're exploring large unfamiliar codebases without tooling
• You do full-stack work spanning many layers simultaneously
• You need the model to identify patterns across a very large codebase
• Cost is secondary to thoroughness

The hybrid approach (recommended): Use 200K with graph-curated context for 90% of tasks, and reserve 1M for the occasional massive refactor or architectural exploration. This gives you optimal cost efficiency on daily work while preserving the ability to scale up when a task genuinely demands it.

The Bottom Line

The 200K vs 1M debate is a distraction from the real question: are you putting the *right* tokens in the window?

A developer using 200K with dependency-graph context — where every token in the window is verified, relevant, and structurally connected to the task — will consistently outperform a developer using 1M filled with an unfiltered codebase dump. The smaller window produces better results at a fraction of the cost.

The context window is not a bucket you fill to the brim. It's a lens you focus on exactly what matters. The size of the lens matters less than what you point it at.

For the vast majority of coding tasks, 200K tokens is more than enough — as long as you fill it with the right code. The tooling to do that automatically exists today. The expensive part isn't the context window. It's the wasted tokens inside it.