Claude Context Window: The Number, the Conversion, and the Failure Mode

A practical reading of Claude context-window sizes, token-to-page conversion, and the failure modes that show up when a coding session gets too large.

Claude's context window depends on where you use it. In Claude chat on paid plans, Anthropic's Help Center says Claude Opus 5 and Sonnet 5 support 1M tokens; Claude Opus 4.8, Opus 4.7, Opus 4.6, and Sonnet 4.6 support 500K; outside those models, the window is 200K, which the same page describes as about 500 pages of text or more. In the Claude API docs, the model-level answer is different: Fable 5.1, Mythos 5.1, Fable 5, Mythos 5, Opus 5, Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5, Sonnet 4.6, and Mythos Preview have a 1M token context window; other Claude models, including Sonnet 4.5, have 200K. In Claude Code, Anthropic's model-configuration page says Fable 5.1, Fable 5, Sonnet 5, Opus 4.6 and later, and Sonnet 4.6 support 1M for long sessions, but availability varies by model and plan: Sonnet 4.6 requires usage credits on subscription plans, Pro users need usage credits for Opus 1M, and Max, Team, and Enterprise include Opus 1M with the subscription. Sources: Claude Help Center, Claude Platform context windows, and Claude Code model configuration.

That size is the ceiling, not the amount you should try to stuff into one working session. In Claude Code, the context window is spent by your chat history, file reads, command output, tool schemas, MCP output, project instructions, and Claude's next answer. The Claude Academy page says every file read, command, and message takes space in the context window. Source: Claude Code context management.

The first failure mode is a hard token error:

Prompt is too long: 137500 tokens > 135000 maximum

When you see that, the next prompt is usually not the real problem. The real problem is the accumulated session: repeated file dumps, long logs, broad MCP outputs, or a project instruction file that keeps getting carried into every turn. Use /context before trying to compact anything. If /context shows old command output, unused tools, or noisy project instructions taking the space, remove that pressure first.

The second failure mode is worse because it hits the rescue tool itself:

Error during compaction: Conversation too long. Press esc twice to go up a few messages and try again.

That means /compact also needs room to read and summarize the current conversation. If the session has already grown past the recoverable range, compaction can fail before it produces the summary. The recovery order is: save the current task state, press Esc twice to move before the oversized turn, retry /compact, and if it still fails, start clean with /clear or a new session. Do not paste the full old transcript back in; that rebuilds the same failure.

A third version looks like an automatic reset:

Context limit exceeded during compaction. I've reset our conversation to start fresh - please try again.

or:

auto-compaction could not recover this turn

Treat that as a lost working buffer. Rebuild with a short handoff note: goal, files touched, commands already run, exact errors, current decision, and next action.

Token to Words and Pages Conversion

Use this as a feeling for size, not as a tokenizer guarantee.

200K tokens ≈ 500 pages
500K tokens ≈ 1,250 pages
1M tokens ≈ 2,500 pages

The page math uses Anthropic's Help Center statement that 200K tokens is about 500 pages, so one page is roughly 400 tokens. The word math below is an estimate, not an official Anthropic ratio: if you use 1 token ≈ 0.75 English words as the working conversion, then 200K ≈ 150,000 words, 500K ≈ 375,000 words, and 1M ≈ 750,000 words. Code, tables, logs, JSON, and non-English text can use tokens very differently.

That is why a 1M window can still feel small in a coding session. Ten pasted stack traces, a few full-file reads, one verbose MCP server, and a long CLAUDE.md can burn space faster than normal prose. A clean 200K session can outperform a polluted 1M session.

Another trap is blaming Claude when the client is the bottleneck. If a Claude-compatible coding client suddenly acts like the context window shrank after an upgrade, check environment and client settings before blaming the model. A setting like this can change the effective context behavior:

CLAUDE_CODE_DISABLE_1M_CONTEXT=1

After changing it, restart the terminal or app session, then run /context again. Without the restart, the old environment can still be active.

Wrapper clients can also impose smaller limits than the backend model. A backend may support:

128000

while the client config still says:

contextWindow: 16000

Then the tool behaves like it has a short memory even when the model endpoint can accept more. Reserved-output settings can create the same false shortage. A value like:

reserveTokensFloor: 50000

can leave too little room for input. Changing it to a verified project value such as:

reserveTokensFloor: 40000

or using:

reserveTokens: 32768

only makes sense inside the client where those exact fields exist. These are not universal Claude limits. They are local budgeting knobs.

The stable workflow is simple: keep the main session narrow, check /context early, compact before the session is already broken, move bulky logs into short summaries, disable unused MCP tools, and restart cleanly when compaction itself fails. Claude context window is not only a model-size number. It is a working budget shared by the model, the coding client, the tools, the project instructions, and the recovery mechanism.