Claude Code 1M Context: When It Helps and When It Hurts

The first long session I ran on a million-token window went further than any session before it and then produced its worst answer at the end. Nothing had failed. The conversation was simply enormous, the relevant decision had been made three hundred thousand tokens earlier, and I had stopped doing the one thing that used to keep a session sharp: throwing away what no longer mattered.

A bigger window is genuinely useful, and it is not a substitute for context discipline. This post covers who gets the 1M window on which plan, how the auto-compact threshold is actually decided, the three places you can set it and which one wins, why you might cap the window on purpose, and what breaks when a gateway sits in the middle.

Who gets it, and on what plan

Extended context is supported on Fable 5, Sonnet 5, Opus 4.6 and later, and Sonnet 4.6. Availability then depends on your plan, and the split is not the one people assume — Opus and Sonnet 4.6 are treated differently on the same subscription.

Extended context by plan:

Claude Code only checks those plan requirements when it connects to the Anthropic API directly. Point the base URL at a gateway while your saved login stays the active credential and it stops checking usage credits — the 1M options remain in the picker and the gateway decides whether the request succeeds. That is a genuine behaviour difference, not a loophole worth relying on.

Sonnet 5 has no 200K version to fall back to

On the Anthropic API, Sonnet 5 always runs with the million-token window. There is no 200K variant, no suffix to select, and no usage credits required on any plan. Sessions auto-compact before the window fills, at roughly 967 thousand tokens by default.

Two configurations budget it at 200K instead, and both are worth recognising because the symptom is identical — a session that compacts far earlier than you expected. Behind a gateway Claude Code cannot verify 1M support, so it budgets conservatively until you pick the 1M entry in the model picker. And the disable variable holds every model with a native 1M window to 200K by design.

Three places to set the window, and the one that wins

The auto-compact window is how full the context can get before Claude Code compacts. It is set in three places with a strict precedence, and the middle one has a property worth knowing: the launch flag is not preempted by a higher-priority settings scope, while the command is.

# Three places to set the auto-compact window, in order of
# precedence. Accepts 100K to 1M tokens.

# 1. Environment variable — beats everything, and /autocompact
#    reports the override instead of changing anything.
CLAUDE_CODE_AUTO_COMPACT_WINDOW=500000

# 2. The launch flag — overrides your saved setting for one
#    launch without changing it. NOT preempted by managed settings.
claude --autocompact 500k
claude --autocompact auto      # the window tuned for your model

# 3. The command, which saves to your user settings.
/autocompact 500k
/autocompact auto

# Accepted forms: 200000, 500k, 1M, or a bare 100-1000 meaning
# thousands. The env var takes ONLY the plain token count.
# Claude Code caps the window at the model's real context window.

Capping the window on purpose

Turning the big window off sounds perverse until you have a reason. Deployments that need a predictable ceiling, cost controls that assume a bounded conversation, and comparisons where you want two sessions to behave the same are all legitimate. The behaviour when you do is specific, and the interaction with the auto-compact window catches people out.

# Cap every model at 200K, including ones with a native 1M
# window such as Sonnet 5 and Fable 5.
CLAUDE_CODE_DISABLE_1M_CONTEXT=1

#   - 1M variants disappear from the /model picker
#   - with auto-compaction ON, sessions compact at 200K.
#     Setting the auto-compact window above 200K does NOT lift
#     the hold, because the window is capped at the model's
#     context window and the model is now treated as 200K.
#   - with auto-compaction OFF, sessions stop at 200K with the
#     context-limit error instead of compacting.

# Behind a gateway, Claude Code cannot verify 1M support, so a
# Sonnet 5 session budgets 200K. Pick the 1M entry in the model
# picker to get the full window back.

Gateways and custom model IDs: three cases, not one

On a gateway or custom deployment, Claude Code can assume a context window for a model ID that differs from the real one. There is a variable to declare the correct window, and how it applies depends entirely on the shape of the ID:

1. An ID that does not start with the Claude prefix, does not contain the 1M marker, and cannot be resolved to a Claude model: the variable applies directly and proactive compaction continues at the declared window.
2. An ID that contains the 1M marker but is otherwise unrecognised: Claude Code assumes a 1M window and the variable does not apply on its own. Set the disable variable too, and expect a startup warning that the 200K limit is not enforced — the warning is expected in this configuration.
3. An ID that starts with the Claude prefix or resolves to a Claude model: the variable takes effect only when compaction is disabled entirely. Claude Code resolves an ID containing a Claude model name to that model, even one carrying the 1M marker.

The pricing is simpler than the configuration

The 1M window uses standard model pricing with no premium for tokens beyond 200 thousand. On plans where extended context is included with the subscription, usage stays covered by the subscription; on plans that reach it through usage credits, those tokens are billed to credits. There is no separate long-context rate to reason about.

The real cost is elsewhere and it is not on the invoice. A larger window means a larger prefix to cache, a longer conversation to reprocess whenever something invalidates that cache, and a much more expensive compaction when it eventually fires after a break longer than the cache lifetime. Resuming a very long session after an upgrade is the worst case of all three at once.

Why a bigger window is not automatically a better session

Anthropic's own study of Claude Code sessions found that expert sessions are longer, not shorter — twelve actions and around 3,200 words against five actions and 600 for novices. Length is not the problem. Unmanaged length is. Three things get worse as a conversation grows regardless of whether it fits:

• The cost of any cache invalidation scales with the conversation, so a mid-task model switch is far more expensive at 800K than at 80K.
• Compaction after a long idle gap reprocesses the full history as uncached input, and that bill scales with the window you allowed it to fill.
• A decision made early is still in the window but is competing with everything since — fitting is not the same as being found.

Treat the million-token window as insurance rather than as capacity. It means a session that legitimately needs to read half a repository does not die halfway through, and that is worth a great deal. It does not mean the session that has been running since this morning should still be running, and the discipline that made 200K workable — compact at task boundaries, rewind instead of compacting when abandoning a path, start fresh when the topic changes — is exactly the discipline that makes 1M worth having.