Managing Claude Code's context window — how to stop running out of room and burning tokens

You start a Claude Code session and it’s sharp. Two hours later it’s sluggish, it’s re-reading files it already saw, it’s forgetting a constraint you set at the start, and your usage meter is climbing faster than the work justifies. The model didn’t get worse. The context window filled up with things it no longer needs — old file dumps, abandoned approaches, tool output you’ve long since acted on.

Keeping context lean is the difference between a session that stays fast and cheap and one that turns into expensive sludge. It’s mostly five habits. This page ranks them by how much they actually move the needle.

The 30-second version

1. Subagents are the biggest lever. Delegate searches and multi-file investigations so the dumps stay in their context and only the answer comes back. This alone changes the shape of a long session.
2. /clear between unrelated tasks. The most underused command. A fresh start costs nothing and resets the tax.
3. /compact when one task gets long. Summarizes what you’ve done, keeps the thread, frees the room. Auto-compaction does this for you near the limit — but doing it deliberately is better.
4. Scope what gets read. “Read the whole repo” is how windows fill. Name the files.
5. Pay down the standing taxes. A bloated CLAUDE.md and a wall of always-on MCP servers cost tokens on every turn, before you type anything.

Why context fills up (and why it matters before it’s “full”)

Current Claude models carry a large window — about 1M tokens on Opus 4.8. It’s tempting to think you’ll never hit it. Two things make that wrong in practice:

• Quality degrades well before the window is full. A context packed with stale, irrelevant material makes the model slower to respond, more likely to lose the thread, and more expensive per turn — every token in the window is re-processed on every turn. A 60%-full window of junk is worse than a 20%-full window of signal.
• It accumulates silently. Each file read, each test run, each grep dump, each abandoned approach stays in context unless you clear or compact it. A two-hour session can carry forty file reads you needed once and never again.

So “running out of context” is the visible failure, but the real cost shows up much earlier as a session that’s quietly gotten dull and pricey.

1. Subagents — the highest-leverage fix

This is the one that changes the math, so it goes first.

When you ask the main session to “find where we handle retries across the codebase,” it reads ten files, dumps them all into your context, and reasons over them — and all ten dumps stay there for the rest of the session. When you delegate the same question to a subagent (the Task/Agent tool, or a /-style agent in your setup), the subagent does the reading in its own context and returns only the conclusion: “retries are handled in client.ts:88 and queue.ts:140; here’s the pattern.” Forty file reads collapse into a paragraph.

The rule: if a step involves reading a lot to produce a little, delegate it. Search, audits, “where is X,” “summarize how this module works,” cross-file investigations — all of it belongs in a subagent. Your main thread stays a clean record of decisions, not a landfill of everything that was ever read. For multi-agent setups specifically, see running a fleet of long-lived agents.

2. /clear between unrelated tasks

The cheapest win, and the one people skip because momentum feels productive. If you’ve finished the bug and you’re moving to an unrelated feature, nothing from the bug needs to come along. /clear starts fresh; the model re-reads what it needs for the new task and nothing it doesn’t.

The anti-pattern is the all-day session: one continuous context that started with a typo fix at 9am and is now, at 4pm, carrying every unrelated thing you’ve touched since. That session is paying a tax on its entire history on every turn. Treat /clear as the punctuation between tasks.

3. /compact when a single task gets long

Sometimes you can’t clear — you’re deep in one task and you need the history. That’s what /compact is for: it replaces the running conversation with a summary, keeping the decisions and the current state while dropping the raw material that produced them. You keep going with continuity, in a fraction of the space.

Claude Code also auto-compacts as you approach the window limit — the conversation is summarized for you and work continues without a hard stop. That safety net is real, but compacting deliberately, at a natural break before you’re forced to, gives a cleaner summary than one triggered mid-thought. Don’t rely solely on the automatic trigger.

4. Scope what Claude reads

A lot of context bloat is self-inflicted at the prompt. “Read the codebase and then…” invites the model to pull far more than the task needs. Two habits help:

• Name the files or the directory. “Look at auth/ and tell me…” beats “look at the project.”
• Use ignore rules for noise. Build output, lockfiles, vendored dependencies, generated code — keep them out of the agent’s reach so a broad search doesn’t vacuum them in. The same hygiene that keeps your disk footprint sane keeps context clean.

5. Pay down the standing taxes: CLAUDE.md and MCP

These two cost you tokens on every turn, before you’ve said anything — which makes them the easy savings everyone overlooks.

• CLAUDE.md is prepended to every session. Every line you put there is paid for on each turn, all session long. A 400-line file of “best practices” that’s really just noise is a per-turn tax. Keep it tight and load-bearing — the specifics are in five habits in your CLAUDE.md that are quietly burning tokens.
• Every always-on MCP server loads its tool schemas into context. Connect a dozen MCP servers and their tool definitions sit in your window on every turn whether you use them or not. Newer Claude Code mitigates this with searchable/deferred tools (schemas load on demand), but the principle holds: disconnect MCP servers you’re not using. A lean tool surface is a lean context.

Quick decision rule

The through-line: a context window is working memory, not storage. Put in what the current step needs, get the rest out, and a long session stays as sharp as a fresh one — at a fraction of the token cost.

What would change this page

Larger context windows won’t retire these habits — quality-per-token degrades with junk regardless of window size, so lean context stays worth it. What would change the specifics: smarter automatic context pruning (keeping signal, dropping dumps, without a manual /compact), per-tool context isolation by default, or MCP schemas that never sit in context until called. The 2026 trend line points that way; until then, the five habits above are the job.

Companion reading

• Five habits in your CLAUDE.md that are quietly burning tokens — the per-turn tax you pay before typing
• Claude Code over-engineers by default — less code generated is less context consumed
• Running a fleet of long-lived AI agents — context isolation across multiple agents
• Claude Code usage limits, explained — how the token burn you’re managing maps to your plan’s caps
• What AI coding agents write to your disk — the ignore-rule hygiene that keeps reads clean

Sources

1. Claude Code documentation — managing context, /compact and /clear
2. Anthropic — Claude Code best practices
3. r/ClaudeWorkflows — tiered context management and token-reduction workflows (June 2026)
4. Hacker News — “How much $ you spend for AI to code?” (June 18, 2026)

FAQ

Why does Claude Code run out of context? Every file read, command output, and conversation turn accumulates in the window. The window is large (about 1M tokens on Opus 4.8), but quality and cost degrade well before it’s full — a session full of stale dumps is slow, expensive, and forgetful. It’s rarely the codebase being too big; it’s the session holding what it no longer needs.

What’s the difference between /clear and /compact? /clear wipes the conversation and starts fresh — use it between unrelated tasks. /compact summarizes the conversation and keeps the summary, freeing room while preserving continuity — use it mid-task when you’re getting long. New task, /clear; same task, getting long, /compact.

Do subagents reduce token usage? Yes — for exploration-heavy work they’re the biggest lever. Delegating a search or investigation keeps the file dumps in the subagent’s context; only the conclusion returns to your main thread. Forty file reads come back as a paragraph.

How do I lower my token bill on long sessions? In order of impact: delegate exploration to subagents; /clear between unrelated tasks; /compact when one task gets long; scope what gets read; and trim the standing taxes — a bloated CLAUDE.md and unused always-on MCP servers cost tokens on every turn.