Claude Code Context Window: 200K vs 1M, and How to Check What Is Using It (2026)

The Claude Code context window is 1 million tokens on the current Claude 5 models, Opus 5, Sonnet 5 and Fable 5.1, and 200,000 tokens, roughly 500 pages of text, on Sonnet 4.5 and Haiku 4.5 (Anthropic Claude Code docs, 2026). That is the headline number every page on this topic quotes. Size is the least interesting part. A single MCP server can burn roughly 20% of a 200K window before you type a prompt, and a 1M context is only as good as the model's ability to read it: on Anthropic's own benchmark, that ranged from 76% down to 18.5% between two of its models (Anthropic, 2026). This post covers what the window is, what fills it, how the 1M window actually works and costs, and the four commands that manage the window day to day.

Updated September 10, 2026 for the Claude 5 lineup: Opus 5, Sonnet 5 and the Fable models now run a 1M window by default in Claude Code, the [1m] variant applies to Opus 4.6 and Sonnet 4.6, the long-context surcharge is gone, the auto-compact threshold is now documented, and the long-context research cited here now comes from NoLiMa, RULER, Hidden in the Haystack and Anthropic's engineering team.

One framing runs through all of it: curated retrieval over context-dumping. Surface the relevant slice instead of paying to stuff the window, because context degrades as the window fills.

How big is the Claude Code context window?#

Claude Code's context window is 1 million tokens on Opus 5, Sonnet 5, Fable 5.1 and Fable 5 when Claude Code connects to the Anthropic API directly; Sonnet 4.5, Haiku 4.5 and every other model stay at 200,000 tokens, about 500 pages of text (Anthropic Claude Code docs, 2026; Anthropic build-with-claude docs, 2026). Opus 4.6 and Sonnet 4.6 support 1M too, but only when you select a [1m] variant. The window is a finite attention budget, not free storage.

The number matters less than people expect. A 200K window you keep clean beats a 1M window you let fill with noise. Two edges worth knowing: on Claude 4.5 and later models, if your input plus max_tokens exceeds the window, the API returns a stop_reason of model_context_window_exceeded rather than silently truncating (Anthropic build-with-claude docs, 2026), and on Amazon Bedrock, Google Cloud's Agent Platform and Microsoft Foundry, Opus 5 runs with a 200K window (Anthropic Claude Code docs, 2026).

Per Anthropic's documentation, the Claude Code context window is 1M tokens by default on Opus 5, Sonnet 5 and the Fable models on the Anthropic API, 1M by [1m] opt-in on Opus 4.6 and Sonnet 4.6, and 200K on Sonnet 4.5, Haiku 4.5 and everything else (Anthropic, 2026).

Source: Anthropic Claude Code docs, 2026; Anthropic build-with-claude docs, 2026.

What fills the context window before you even start?#

A fresh session is already partly spent. Per Anthropic's docs, the system prompt runs around 4,200 tokens, a project CLAUDE.md around 1,800, a global CLAUDE.md around 320, and auto-memory loads the first 200 lines or 25KB of MEMORY.md (Anthropic Claude Code docs, 2026). None of that is your prompt. It's overhead the window pays before work begins.

MCP tools are cheaper than people assume by default: they load tool names only, around 120 tokens, with schemas deferred via tool search. Setting ENABLE_TOOL_SEARCH=auto loads schemas upfront only when they fit under 10% of the window. Then file reads take over. Each read runs 1,100 to 2,400 tokens, and the docs are blunt that file reads dominate ongoing context usage (Anthropic Claude Code docs, 2026).

The line items you can see, your prompts and your file reads, are not the ones eating your budget fastest. The fixed overhead and an enabled MCP server's schemas do that, before your first request, which is why curated context beats stuffing the window.

This is the problem a context engine exists to solve: a service that gathers the knowledge around your code and hands the agent only the relevant part. Unblocked is the context engine for agentic software development. Your agents already know the code; Unblocked gives them the rest, and it does so over a single MCP connection that replaces a separate server for GitHub, Jira, Confluence and Slack, along with each one's schema overhead. Context is scored, compressed and assembled server-side, so the agent spends tokens on the answer rather than on tool definitions.

A fresh Claude Code session spends thousands of tokens before any prompt: roughly 4,200 on the system prompt and 1,800 on a project CLAUDE.md, while file reads, at 1,100 to 2,400 tokens each, dominate ongoing usage (Anthropic Claude Code docs, 2026).

Where a fresh 200K window goes#

Figures per Anthropic Claude Code docs, 2026; the MCP figure is Unblocked's own measurement, 2026.

Why does a single MCP server cost you 42,000 tokens?#

Enabling a full MCP server's schemas is the single largest controllable line item in your window. In our own measurement, GitHub's MCP server injects roughly 42,000 tokens of tool definitions before your first prompt, about 21% of a 200K window (Unblocked, 2026).

Default loading avoids this. Claude Code loads tool names only and defers schemas through tool search, so the tax appears when you enable a whole server's schemas rather than when you connect it. The fix is mundane: enable only the tools a given task needs, and rely on deferred tool search for the rest. Most teams never measure it, so we walk through the full MCP token-tax breakdown server by server.

Trimming is one answer. Consolidating is the other. Unblocked connects the pull requests, tickets, docs and chat around your code through one MCP server instead of four or five, and because the retrieval, ranking and compression run on Unblocked's side, the agent gets a short, reconciled answer rather than raw pages to sift. Permissions are enforced per user on every query, so a single shared connection never widens what any one engineer can see. One engineering manager measured the difference directly:

Unblocked used about a third of the tokens. Five thousand versus fifteen thousand. And the thing I thought was amazing is that Unblocked had the answer already. The rest was just my AI dressing it up. After that I opened up about twenty PRs, and now the first thing all of our skills do is ask Unblocked.

Charles Thompson — Engineering Manager, Reservation and Guest, Cloudbeds

A single MCP server can be the largest controllable cost in a Claude Code window. GitHub's MCP server injects roughly 42,000 tokens of tool definitions, about 21% of a 200K window, before the first prompt (Unblocked, 2026), and trimming that tax is one of the fastest ways to reduce AI token costs overall.

Is a 1-million-token context window actually usable?#

Size and usable size are different numbers. On Anthropic's 8-needle MRCR v2 benchmark at 1M tokens, Opus 4.6 scores 76% while Sonnet 4.5 scores 18.5%, the same window read four times less reliably (Anthropic, 2026). Anthropic has not published MRCR figures for Opus 5, Sonnet 5 or Fable 5.1 as of this update, so that pair remains the clearest public illustration. Turning on 1M does not give you 1M usable tokens. It gives you a bigger budget the model reads with model-dependent reliability.

This isn't an Anthropic-only quirk. The NoLiMa benchmark tested 13 models that claim at least 128K of context and found that at 32K tokens, 11 of them had dropped below 50% of their short-context baseline; even GPT-4o, one of the strongest, fell from 99.3% to 69.7% (NoLiMa, arXiv, 2025). RULER found that only about half of 17 long-context models held satisfactory performance at 32K, despite every one claiming 32K or more (RULER, arXiv, 2024). Anthropic's own engineering team calls the effect context rot: as the number of tokens in the window increases, the model's ability to accurately recall information from it decreases, which is why they treat context as a finite resource with diminishing returns (Anthropic Engineering, 2025). Coverage of Opus 4.6 noted the same gap between window size and retrieval, alongside the model's context-compaction work (InfoQ, 2026). The headline "a million tokens" weakens the moment you measure whether the model can retrieve from it. This post focuses on the window itself, while our companion piece covers why accuracy drops as input grows and how retrieval recovers it.

The practical response is to shrink what goes in rather than grow the window. Hidden in the Haystack showed, across 11 models and more than 150,000 controlled runs, that the relevant passage gets harder to use when it is small and surrounded by distractors (Hidden in the Haystack, arXiv, 2025), which is exactly what a window stuffed with whole files produces. Unblocked scores, compresses and assembles context server-side and resolves conflicts between sources by recency, authority and proximity, so the agent reads a few thousand high-signal tokens with the contradictions already settled instead of scanning a million and guessing.

A 1M context window is not 1M usable tokens. On Anthropic's 8-needle MRCR v2 benchmark at 1M, Opus 4.6 retrieves 76% while Sonnet 4.5 manages 18.5%, and NoLiMa found 11 of 13 long-context models lose more than half their short-context accuracy by 32K tokens (Anthropic, 2026; NoLiMa, arXiv, 2025).

How do you turn on the 1M window, and what does it cost?#

Cost used to be the catch. Until March 2026, requests above 200K tokens billed at a premium long-context tier: Opus input rose from about $5 to around $10 per million tokens and Sonnet from about $3 to roughly $6, with output priced up as well. Anthropic removed that surcharge in March 2026, so the full 1M window bills at standard per-token rates, which today means $5 and $25 per million input and output tokens on Opus 5, $2 and $10 on Sonnet 5, and $10 and $50 on Fable 5.1 (The New Stack, 2026; Anthropic pricing docs, 2026). That settles the price question. The usability question stays open: a model that reads a 1M window at 18.5% is the reason to treat the big window as a tool for specific jobs rather than a default.

Turning it on mostly happens for you now. In Claude Code on the Anthropic API, Opus 5, Sonnet 5 and the Fable models run with the 1M window by default; on Max, Team and Enterprise plans, Opus is upgraded to 1M automatically, while Pro accounts and Sonnet 4.6 on any plan need usage credits. For Opus 4.6 and Sonnet 4.6, select a [1m] variant with /model opus[1m] or /model sonnet[1m], or append [1m] to a full model name. To hold every model at 200K, set CLAUDE_CODE_DISABLE_1M_CONTEXT=1 (Anthropic Claude Code docs, 2026). On the API itself, 1M is the default on every model that supports it and no beta header is required (Anthropic build-with-claude docs, 2026). Reach for the full window on genuinely large single-shot tasks. For everyday work, a managed 200K beats an unmanaged 1M, and the cost math still favors it: Claude Code resends the whole conversation on every request, so a one-line question late in a long session carries the entire history with it, at cached rates but never free (Anthropic Claude Code docs, 2026).

What do /context, /compact, /clear, and /usage actually do?#

Four commands control the window, and most users only know two. Per Anthropic's docs, /context visualizes current usage as a colored grid with a per-category breakdown, optimization suggestions for context-heavy tools and memory bloat, and capacity warnings; /compact replaces the conversation with a structured summary, and you can focus it with /compact focus on X; /clear starts a new conversation with empty context (aliases /reset and /new); and /usage (alias /cost) reports session token usage and cost, plus plan limits and a per-MCP-server attribution breakdown on subscription plans (Anthropic Claude Code docs, 2026; Anthropic Claude Code docs, 2026).

Some models also self-report. Sonnet 5, Sonnet 4.6, Sonnet 4.5 and Haiku 4.5 receive a live token-budget <system_warning> after each tool call, so the model itself knows how full the window is; Opus 4.7 and later and the Fable models do not (Anthropic build-with-claude docs, 2026). The table below is the quick reference worth bookmarking.

Four slash commands manage the window: /context shows a live breakdown with capacity warnings, /compact summarizes the conversation, /clear wipes it to 0, and /usage reports tokens, cost and plan limits (Anthropic Claude Code docs, 2026).

What survives a /compact, and what gets lost?#

Compaction is not lossless, and knowing the boundary saves you from re-explaining your project. Per Anthropic's docs, a /compact preserves the system prompt, the project-root CLAUDE.md, unscoped rules, and auto-memory. It drops paths:-scoped rules and nested CLAUDE.md files until they are re-read, re-reads up to five of the files Claude touched most recently, and re-injects invoked skills capped at 5,000 tokens per skill and 25,000 total (Anthropic Claude Code docs, 2026). Everything else becomes a summary: full tool outputs and intermediate reasoning are gone.

The practical rule follows directly. Anything that must persist across a compaction belongs in your project-root CLAUDE.md or in unscoped rules. A nested or path-scoped file comes back only when Claude reads a matching file again. This is one of the more common ways Claude Code seems to forget your codebase mid-session.

Compaction also loses everything the agent learned from outside the repo: the Slack thread that explained the constraint, the ticket that set the scope, the review comment that rejected the last approach. When that knowledge lives in Unblocked rather than in the conversation, the agent asks again after compaction and gets the current answer, assembled from every source with permissions enforced per user, instead of waiting for you to paste it back in. That is what it means to stop babysitting your agents.

/compact vs /clear: which should you use?#

This is the claude code clear context question most people get wrong. Use /compact for continuity: you're on the same task, you still need the thread's reasoning, but the window is filling. Use /clear for separation: a new, unrelated task where you want a clean slate and a full window. Compact to keep going, clear to start over (Anthropic Claude Code docs, 2026).

There's also auto-compaction, and the trigger point now depends on the model. Models with a native 1M window compact at about 967K tokens by default; Opus 4.6 and Sonnet 4.6 without extended context compact at the 200K boundary. You can move that point yourself with /autocompact, which accepts any window from 100K to 1M (/autocompact 500k), or with CLAUDE_CODE_AUTO_COMPACT_WINDOW in scripts (Anthropic Claude Code docs, 2026). Compacting early on a 1M model is usually the right call: /compact reads the whole conversation it summarizes, so a compaction at 900K is itself a very large request (Anthropic Claude Code docs, 2026).

Use /compact to summarize and continue the same task and /clear to wipe context and start a new one; auto-compaction fires at about 967K tokens on native 1M models and at the 200K boundary on Opus 4.6 and Sonnet 4.6 without [1m], and /autocompact lets you set the point yourself (Anthropic Claude Code docs, 2026).

How should you manage the context window day to day?#

Managing the Claude Code context window beats buying a bigger one. Here is the decision tree, drawn from the command behavior above (Anthropic Claude Code docs, 2026). Window filling on the same task? Run /compact, or /compact focus on X. Switching to unrelated work? Run /clear. An MCP server eating the window? Disable unused servers with /mcp and lean on deferred tool search. A genuinely large single-shot task? On Opus 5, Sonnet 5 or Fable you already have the 1M window; on Opus 4.6 or Sonnet 4.6, switch to the [1m] variant. Long session on a 1M model? Set /autocompact below the 967K default so summaries stay small. Not sure where it all went? Run /context first, always.

The durable fix sits underneath all of it: curated retrieval over context-dumping. Surface the relevant slice on demand instead of paying to stuff the window with everything you might need. Teams who treat the window as a budget to defend, not a vault to fill, spend less time on redo loops. This is where a context engine earns its place in the stack: the agent knows the code, Unblocked supplies the decisions, discussions and tickets around it in a few thousand scored and compressed tokens, and the window stays free for the work. One customer put the before-state plainly:

Before Unblocked, I was manually compiling documentation into a local folder just so Claude Code could reference it. Now it pulls everything directly. I'm getting 90% accuracy on complex data structure questions.

Austin Rojan — Onboarding Specialist, Subsplash

That persistence across sessions is what turns a clean window into durable institutional memory.

Frequently asked questions#

How do I clear context in Claude Code?#

Run /clear to wipe the conversation entirely, which returns context to 0, when you're switching to unrelated work. If you're staying on the same task but the window is filling, use /compact instead to summarize the thread and continue with the reasoning preserved (Anthropic Claude Code docs, 2026).

Does Claude Code have a 1M context window?#

Yes. On the Anthropic API, Opus 5, Sonnet 5 and the Fable models run with the 1M window by default in Claude Code; Opus 4.6 and Sonnet 4.6 get it when you select a [1m] variant. Sonnet 4.5, Haiku 4.5 and every other model remain at 200,000 tokens. Anthropic removed the earlier above-200K premium in March 2026, so the 1M window bills at standard per-token rates (Anthropic Claude Code docs, 2026; The New Stack, 2026).

Why does the context window fill so fast?#

Overhead and reads, far more than your prompts. The Claude Code context window is spent partly before you type. A fresh session already runs roughly 4,200 tokens on the system prompt and 1,800 on a project CLAUDE.md, and file reads run 1,100 to 2,400 tokens each. A full MCP server with schemas loaded can add around 42,000 more (Anthropic Claude Code docs, 2026; Unblocked, 2026).

What is Claude Code's context window size?#

It depends on the model. Opus 5, Sonnet 5, Fable 5.1 and Fable 5 run a 1,000,000-token window by default on the Anthropic API. Opus 4.6 and Sonnet 4.6 run 200,000 tokens unless you pick a [1m] variant. Sonnet 4.5, Haiku 4.5 and everything else run 200,000 tokens, roughly 500 pages of text (Anthropic Claude Code docs, 2026).

Managing the Window in Practice#

The team that wins isn't the one with the biggest window. It's the one that keeps the window clean. Size is the least important lever you have. Management is the real one: see the window with /context, shape it with /compact and /clear, prune the MCP servers you don't need, and stop paying for context you never read. Treat the Claude Code context window as a budget to defend, and a 1M budget the model reads at 18.5% stops looking like an upgrade over a tidy 200K.

What makes the difference over a quarter of daily work is the habit underneath the commands: feed the agent the WHY behind the code instead of dumping every file and hoping the model finds the signal. That is the job of a context engine, and it is what Unblocked does for a coding agent that already knows the code. Run /context on your next session to see where your tokens go, then read how context degrades and how retrieval recovers it.