What Is the Claude Code Context Window?

What Is the Claude Code Context Window?

The context window is everything Claude Code can see at once: your instructions, the files it has read, its own replies, and a quantity of material that loads before you type a single character and never appears in your terminal.

It is also the constraint that quietly shapes every long session. When a session starts forgetting a decision you made twenty minutes ago, the window is usually the reason.

What makes it worth a careful read is an asymmetry in Anthropic's own documentation. The window's size is published in tokens. The point at which Claude Code decides the window is full enough to summarize is not published as a number you can reason about at all — it is published as a list of exceptions. That gap is the most practically useful thing to understand here, so this guide covers the documented facts first and the documented silences second.

What Is the Claude Code Context Window? The Short Answer

It is a token budget for one conversation, and its default size is 200,000 tokens.

That figure appears in a slightly unexpected place. The clearest statement of it in the documentation is in the status line reference, describing the context_window.context_window_size field: "Maximum context window size in tokens. 200000 by default, or 1000000 for models with extended context."

A much larger window is available on many current models. Anthropic's context window page states that "Fable models, Sonnet 5 and later, Haiku 5.5, Opus 4.6 and later, and Sonnet 4.6 support a 1 million token context window." Some of those run at the larger size without you asking: the model configuration page says "Fable 5.1, Fable 5, Sonnet 5 and later, Haiku 5.5, and Opus 4.7 and later run with the 1M window by default, with no [1m] suffix needed."

The rest you select deliberately, by appending a suffix to the model name — opus[1m], for instance — and availability there depends on your plan rather than on the model alone.

Running out is not fatal. The documentation is explicit: "Claude Code compacts automatically as you approach the limit, so a full context window doesn't end your session." Compaction replaces the conversation with a summary and carries on.

Running a long project and losing track of what is actually working? Get a free audit and start from a clear picture.

What Is Already in the Window Before You Type?

The Startup Load

This is the part most people underestimate. Anthropic's own breakdown of a session timeline begins: "Before you type anything: CLAUDE.md, auto memory, MCP tool names, and skill descriptions all load into context."

Four separate mechanisms, all consuming budget before your first prompt. Your project instructions, any automatically captured memories, the names of every tool exposed by every connected MCP server, and a one-line description of every skill available to the session.

The documentation adds that your own setup may contribute more — an output style, or text passed through the --append-system-prompt flag. On the cost side, the guidance is blunt about the first of those: "Your CLAUDE.md file is loaded into context at session start," paired with the recommendation to "aim to keep CLAUDE.md under 200 lines."

What Loads Lazily, and Why It Matters

Two mechanisms are deliberately designed not to load up front, and knowing which they are changes how you organize a project.

MCP tool definitions are the first. The cost documentation states that "MCP tool definitions are deferred by default, so only tool names and server instructions enter context until Claude uses a specific tool." The names are cheap; the full schemas are not, and you only pay for the ones actually used.

Skills are the second: "Skills load on-demand only when invoked, so moving specialized instructions into skills keeps your base context smaller." The skills page puts the same point more memorably — "a skill's body loads only when it's used, so long reference material costs almost nothing until you need it."

The practical consequence is a rule of thumb. Instructions that must apply to every message belong in CLAUDE.md. Instructions that apply to one kind of task belong in a skill, where they cost nothing until that task comes up.

What Fills It as You Work

Each file read adds to the window, and so do a few things that fire without being asked. Path-scoped rules "load automatically alongside matching files," and hooks can inject context after each edit.

Tool results are the heavyweight. Claude Code "sends your full conversation with every request," and "each time Claude uses tools it sends another request carrying that batch of tool results." A single command producing a few thousand lines of output lands in the window and stays there.

Subagents are the designed escape hatch. When research is delegated, "a subagent handles the research in its own separate context window, so the large file reads stay out of yours. Only the summary and a small metadata trailer come back."

How Do You See and Control It?

The commands that matter are a short list, and each does something genuinely different:

1. /context is the diagnostic. The command reference describes it as "Visualize current context usage as a colored grid. Shows optimization suggestions for context-heavy tools, memory bloat, and capacity warnings." This is the one to run first, because it tells you which mechanism is eating the budget rather than just how much is gone.
2. /compact is the manual summarize. It will "free up context by summarizing the conversation so far," and it accepts focus instructions — /compact focus on the auth bug fix — so the summary keeps what you choose "instead of what the automatic pass guesses is important."
3. /clear is the reset: "Start a new conversation with empty context." The docs draw the distinction for you: "To free up context while continuing the same conversation, use /compact instead."
4. /rewind compacts part of the conversation. Select a message and choose Summarize from here or Summarize up to here.
5. /autocompact moves the trigger: "Set the auto-compact window: how full the context window gets before Claude Code compacts automatically." Pass a size such as 500k, or auto to return to the default for your model.
6. /memory opens the files responsible for part of the startup load, so you can see and trim what is being injected.

For a permanent setting rather than a per-session command, autoCompactWindow goes in a settings file — "autoCompactWindow": 200000 in ~/.claude/settings.json — and autoCompactEnabled turns automatic compaction off entirely. In scripts and cloud environments there is an environment variable, CLAUDE_CODE_AUTO_COMPACT_WINDOW, which "takes precedence over the command, the flag, and the autoCompactWindow setting."

There is a genuine trap in that variable, documented and easy to hit: "A number with no suffix is read as that many tokens, so CLAUDE_CODE_AUTO_COMPACT_WINDOW=200 means 200 tokens even though /autocompact 200 means 200,000." The two interfaces interpret a bare number differently. The accepted range either way is "from 100K to 1M tokens," and "whichever way you set the window, Claude Code caps it at the model's context window," so asking for more than the model has achieves nothing.

Want the same kind of visibility into which of your pages are earning their keep? Request a free audit.

What Survives Compaction?

Compaction is not a wipe, and the documentation is unusually specific about what comes back. The headline is that "most startup content reloads automatically," but the detail is where the useful information sits.

The system prompt and output style "both still apply." Project-root CLAUDE.md, unscoped rules, auto memory and any plan written in plan mode are all "re-injected from disk" — read fresh rather than summarized. Skill descriptions are "rebuilt from your current skills and re-injected." Background commands and background subagents "keep running," and Claude Code reminds Claude which ones are still going "so it doesn't start a duplicate."

Three behaviors are worth planning around.

Files are re-read, but only some of them: "Claude Code re-reads up to five, most recently modified first." And there is a size cutoff — "a file over 5,000 tokens comes back as a path reference without its content."

Invoked skill bodies come back under a budget: "capped at 5,000 tokens per skill and 25,000 tokens total; oldest dropped first." Truncation "keeps the start of the file," which produces a concrete authoring rule — put the instructions that matter near the top of a SKILL.md, because the bottom is what gets cut.

Path-scoped rules do not persist. Because they load into message history when their trigger file is touched, "compaction summarizes them away with everything else." The documented fix is direct: "If a rule must persist across compaction, drop the paths: frontmatter or move it to the project-root CLAUDE.md."

When Is It Worth Intervening?

Most of the time, it is not. Compaction is automatic and competent, and the published advice elsewhere in the documentation is that running out is rare on current models.

Four moments justify acting manually.

Before a long new task, run /compact with a focus instruction. A guided summary keeps the thread you are about to need; an automatic one keeps what it guesses matters.

When switching to unrelated work, use /clear rather than /compact. The reasoning given is practical rather than theoretical: "Old conversation crowds out the files you need next and costs tokens on every message."

Before a large research task, delegate it. Sending it to a subagent keeps file contents "in its context window, not yours," which is strictly better than reading everything yourself and compacting afterward.

And when a session feels degraded without an obvious cause, run /context before anything else. Memory bloat and a context-heavy MCP server look identical from the outside, and the grid tells them apart.

The same principle applies to a website: you cannot fix what you have not measured. Request a free audit and see the breakdown.

What Are the Limitations Worth Knowing?

The first and largest is that the auto-compact trigger is not published as a percentage anywhere. The context window page says only that "the point where automatic compaction runs depends on your model and configuration." What is published instead is a default plus a list of exceptions: Claude Code "compacts when the conversation reaches the model's context limit, except in these sessions" — cloud sessions, which "compact as the conversation approaches the model's limit"; "Sonnet 4.6 and Opus 4.6 without extended context," which "compact at the 200K boundary"; and models with a native 1M window, which "compact before the window fills, at about 967K tokens by default."

So there is a number, and it is roughly 967,000 tokens on a 1M model. There is no documented percentage, no formula, and no statement of exactly what counts toward the threshold. If you want a predictable trigger, the documented route is to set one yourself rather than to infer the default.

The second limitation is the sharpest, and it concerns the readout rather than the behavior. The status line's used_percentage is "pre-calculated percentage of context window used," and the documentation adds that it is "calculated from input tokens only" and "does not include output_tokens." More importantly, when the environment variable is in play, "the status line's used_percentage measures against the model's full context window, so while the variable is set, that percentage doesn't indicate when compaction will run." The percentage you are watching and the threshold you will hit can be measuring two different things.

There is a related oddity in the same reference. The exceeds_200k_tokens field reports "whether the total token count ... exceeds 200k," and then states: "This is a fixed threshold regardless of actual context window size." On a 1M-window session, the one boolean the status line hands you is about a boundary your session does not have.

Third, /compact is not free. "/compact reads the conversation it summarizes, so compacting a large context is itself a large request." Compacting late costs more than compacting early.

Fourth, some things are simply not documented. The default value of the top-level autoCompactWindow setting is not stated. Neither is the token cost of the system prompt, the tool definitions or CLAUDE.md — the session walkthrough uses what it calls "representative token counts," and the settings documentation says plainly that "Claude Code's system prompt isn't published." You can measure your own numbers with /context; you cannot look up anyone else's.

How Does It Compare to Usage Limits?

These are the two constraints most often confused, and they are unrelated.

A usage limit is about how much you can do over a period of time. The context window is about how much fits in one conversation. Hitting a usage limit means waiting; filling a context window means compacting, which happens in seconds and lets the session continue.

Against a larger window, the trade is cost and latency for headroom. Moving to a 1M-token model does not change how compaction works — "compaction works the same way at the larger limit" — it just moves the boundary. For a genuinely large codebase that is the right answer. For a session that feels cluttered, a /clear is faster and free.

Against subagents, the comparison is the most useful one in this whole area. A bigger window lets you hold more at once; a subagent means you never hold it at all. For any task whose output is a conclusion rather than the raw material — reading twelve files to answer one question — delegation beats capacity. The main conversation receives the summary and a small metadata trailer, and nothing else.

Against turning compaction off, be careful. With auto-compaction disabled on a model held to 200K, sessions "stop at the 200K boundary with the context-limit error instead of compacting." You trade an automatic summary you did not control for a hard stop you did not want.

Curious what a clear-eyed read of your own site would turn up? Start with a free audit and work from evidence instead of guesses.

Final Thoughts

The context window is 200,000 tokens by default and 1 million on a growing list of models, and the practical skill is not memorizing those figures but knowing what is already spending them before you type.

Four mechanisms load at startup — CLAUDE.md, auto memory, MCP tool names and skill descriptions — and two of them have cheaper alternatives if you move specialized material into skills rather than standing instructions. That single reorganization buys back more room than any command.

Learn the three-command reflex. Run /context to find out what is filling the window, /compact with a focus instruction before a big new task, and /clear when the next task has nothing to do with the last one. Delegate large reads to a subagent instead of absorbing them. If you need the compaction point to be predictable, set it with /autocompact or autoCompactWindow, and remember that a bare number in the environment variable means literal tokens.

Finally, keep the two limits straight in your head. If a session stops because of time rather than length, the context window is not the problem; our guide to Claude Code usage limits covers that side of it, including why so much reported "hitting the limit" turns out to be one of these mistaken for the other.

Version requirements move quickly in this area — several of the behaviors above name a minimum Claude Code version — so check your own build before concluding a setting does not exist. Verified against Anthropic's published Claude Code documentation as of November 13, 2026.