Claude Code context window (2026): don't turn auto-compact off, set it

Quick answer

The Claude Code context window is 200,000 tokens by default, and in 2026 that number is a default rather than a ceiling. The point where your session compacts is configurable from 100K to 1M in three separate places, and on Sonnet 5 the default is not 200K at all: it is about 967,000 tokens (model configuration, 2026). The popular advice is to turn auto-compact off so you get control back. You do not have to. You can just set the number.

I spent months treating compaction as weather. It is a setting with a documented precedence order, and finding that out changed how I run long sessions more than any prompt trick has.

The number everyone quotes is a default

Every explainer I read says 200,000 tokens. That is true for some models and stale for others.

Here is what the docs actually specify, checked August 21, 2026:

Fable 5, Sonnet 5, Opus 4.6 and later, and Sonnet 4.6 support a 1 million token window (context window docs, 2026).

Sonnet 5 is the interesting row. On the Anthropic API it always runs at 1M. There is no 200K variant, no [1m] suffix to select, and no usage credits required on any plan. If you are on it, the 200K figure in the blog post you are reading is off by a factor of five.

What is in there before you type

The docs ship an interactive timeline of a session, which is the most useful thing on the page. The startup block is what surprised me.

Before your first prompt: the system prompt, your project CLAUDE.md, auto memory, environment info, MCP tool names, and one-line skill descriptions. In the docs' representative session the system prompt alone is about 4,200 tokens and auto memory is 680, capped at the first 200 lines or 25KB of MEMORY.md.

MCP tools are the part worth knowing. By default only the tool names load, and full schemas stay deferred until a task needs one. Set ENABLE_TOOL_SEARCH=false and you load every schema upfront instead.

I had four MCP servers connected and no idea whether I was paying for them at startup. Run /context and you get a live breakdown by category, including which CLAUDE.md and memory files actually loaded. That command answered a question I had been guessing at for a long time.

Where the window actually gets set

Three places, and they do not have equal authority.

For this session and future ones:

/autocompact 500k

That saves to the autoCompactWindow user setting and applies immediately. /autocompact auto puts you back on the window tuned for your model. If a higher-priority settings scope such as managed settings already sets the key, the command saves your value, keeps that scope's window for the session, and tells you so.

For one launch:

claude --autocompact 500k

The flag overrides your saved setting without changing it. It is also the one that is not preempted by managed settings, which matters if you are on a machine somebody else configured.

For scripts and cloud environments:

export CLAUDE_CODE_AUTO_COMPACT_WINDOW=500000

While that is set it wins over the command, the flag and the setting, and /autocompact will report the override rather than changing anything.

The command and flag take a window from 100K to 1M in three forms: a plain count like 200000, a suffix like 500k or 1M, or a bare number from 100 to 1000 meaning thousands, so 200 means 200,000. The environment variable takes only the plain count. All of them get capped at the model's real window, so you cannot set 1M on a 200K model and expect it to hold.

The advice I followed for months

Search this topic and the strongest community recommendation is to switch auto-compact off entirely. The top Reddit thread on it puts the case well: turning it off means you "can use more of the context window and, it gives you the space to trigger it intentionally" (r/ClaudeAI, 2026).

I did that. It works. It also means that when you misjudge, the session stops with a context-limit error instead of compacting, and you handle it manually at the worst possible moment.

What I did not know is that the thing I wanted from disabling it, control over when the summary happens, is the thing /autocompact gives you while keeping the safety net. Setting the window to 500K on a 1M model gets me an early, predictable compaction with a floor underneath it. Disabling gets me control and no floor.

I am not going to claim I measured this into a benchmark. I did not run a controlled bake-off and I would not trust one from a single laptop. This is a preference change based on reading the documentation properly, and the honest version of the claim is: the setting does what disabling was my clumsy way of approximating.

What compaction actually drops

This is the part I wish I had known a year ago, because it explains a bug I blamed on the model.

The complaint is familiar: you compact, and Claude stops following a rule it was following five minutes earlier. That is documented behaviour, not drift.

Path-scoped rules load into message history when their trigger file is read. So compaction summarizes them away with everything else, and they come back only the next time a matching file gets read.

The fix is in the docs and it is one line of frontmatter: if a rule has to survive compaction, drop the paths: key or move the rule into the project-root CLAUDE.md. I had put my most important convention in a path-scoped rule because it felt tidy. Tidy was the wrong goal. It was the least durable place I could have put it.

The skills row has a similar trap. Bodies are re-injected after compaction, but large skills get truncated to fit the 5,000-token per-skill cap, and truncation keeps the start of the file. So the top of SKILL.md is load-bearing and the bottom is optional. That reordered two of the skills I keep installed within about ten minutes of reading it.

What I changed

Four things, all small.

I set the window explicitly instead of inheriting it. On a 1M model I run /autocompact 500k, which compacts about halfway rather than at 967K, because a summary of a 500K conversation is a better summary than one of a 950K conversation.

I moved my two non-negotiable rules out of paths: frontmatter and into the project-root CLAUDE.md. That is the only change here that fixed an actual recurring problem.

I front-loaded my longest SKILL.md files, on the grounds that the cap keeps the beginning.

And I started running /context before long tasks rather than after things went wrong. It reports what loaded, which turned out to be a different question from what I thought I had configured. That is roughly the same lesson as the one from auditing what I keep in memory and what I turned off: the config you wrote and the context you got are two separate things, and only one of them is observable.

Two things I still do not know

Whether 500K is a good number, or just a round one. Half of 1M is a coincidence of arithmetic, not a finding. Somebody with the patience to run the same task at 200K, 500K and 967K would produce something more useful than my preference, and as far as I can tell nobody has published it.

And whether a smaller window is genuinely better for output quality or only for cost and latency. The question is live right now: r/ClaudeCode has a thread from this week asking whether people have experimented with smaller windows, 300K against 1M, with a few dozen replies and no consensus. That is the honest state of it. The mechanism is documented, the tuning is folklore.

Where this leaves the explainers

Most of what ranks for this query is accurate about 200,000 tokens and quiet about everything above. One page-one result describes the ceiling as "typically around 200,000 tokens for flagship models," which was reasonable when it was written and is not what the docs say now.

The useful version of this topic is not "how big is the context window." It is: which number governs your model, where does the threshold get set, and what does the summary throw away. Three questions, all answered in first-party docs, mostly missing from the results.

Postscript: I disabled auto-compact for four months to get a feature that had a flag the whole time. Reading the docs remains undefeated.