Managing Claude's Context Window

Context management sounds complicated. It isn't, at least not in my own telling. My definition is simple: manage the tokens in a prompt as effectively as you can. I walk through the whole idea using one live Claude Code session and a single command, /context, rather than a pile of abstract rules, and this chapter follows that same path, one piece at a time.

What actually fills the context window

Open a fresh Claude Code session. Type /. A list of commands appears: /compact, /context, /cost, /debug, /init, /insights, plus controls for models and thinking. This chapter focuses on one of them, since /context prints a report of exactly what's using up your context window right now, and a context window, in my own words, is simply the total number of tokens a model can handle at any one time.

In my demo, the model was Claude Opus 4.6, with a window of roughly 200,000 tokens. Some models go much bigger. A bigger number doesn't mean a better model, so don't read window size as a quality signal on its own. My /context report showed 26.4k of that 200k already used, 13 percent, in a session that looked brand new even though I'd typed nothing yet beyond the command itself. Run /context yourself and look at the categories under the total, because that's where the missing tokens actually come from.

FIGURE 25 — Context window composition. Most of a fresh session's context is already spoken for before you type anything.

Even a short prompt carries a baseline cost. My own rough figures run from 5,000 to 15,000 tokens or more, depending on setup. The formula is simple: your prompt, plus everything Claude Code preloads, equals the total. The system prompt is the biggest preloaded piece, and it connects straight to CLAUDE.md: global rules, project rules, and now memory, all read before your message shows up. System tools cost more still. In my demo they ran about 16.8k tokens, the definitions Claude needs just to know what it's capable of doing, from running Bash to entering Plan Mode. A real request, then, looks less like a simple question and more like a stack: instructions, CLAUDE.md, tool definitions, MCP information, memory, skills, and only then your actual message.

Those tools sit there whether you use them or not, since Claude Code ships with the definitions built in. You don't need documentation to see the list, either. Ask Claude directly: "What tools do you have access to? List them all." It returns a table. Reading, writing, and editing each run through their own tool, Read, Edit, Write, alongside Task and TaskOutput for subagents, Bash for shell commands, and Glob/Grep for finding and searching files. NotebookEdit handles Jupyter notebooks specifically. WebFetch and WebSearch reach outside your machine entirely. TodoWrite builds the running task list you see while Claude works. AskUserQuestion powers its multiple-choice interface. EnterPlanMode and ExitPlanMode move you in and out of the read-only mode covered earlier, Skill orchestrates skill calls, and TaskStop halts something already running.

That 16.8K-token system-tool cost is close to fixed. You can't strip it out short of building your own version of Claude Code, though the team behind it keeps trimming what ships by default. MCP tools are different. They come from external servers you choose to connect, so that cost is yours to control. In my report, built-in tools ran about 8.4 percent of context. My own connected MCP tools ran 2.8 percent. My advice: stay selective. One MCP server can expose dozens of tool definitions, and each one adds weight. I showed this with a Chrome DevTools MCP, telling Claude to "go to leftclick.ai," a request Claude understood instantly, since the tool definitions for browser navigation and screenshots were already loaded before that sentence arrived. That same MCP exposes operation after operation under the hood: click, drag, fill a form, evaluate a script. Useful, and expensive at the same time.

Two categories barely register. Memory files used about 88 tokens in my session, Claude's own persistent scratchpad, holding what it's learned so you don't repeat yourself, and Skills came in near 61 tokens, since nothing much was actually loaded that particular session beyond the bare definition itself. Together, these four things, system tools, MCP tools, memory, skills, are what quietly fill a "fresh" session before you've said a word.

How context grows, and what compaction actually does

Context doesn't sit still. By simply continuing the conversation, my own usage climbed from the mid-20K range to about 30.6K of 200K, roughly 15 percent, without anything dramatic happening. Messages, the actual back-and-forth, ran about 2.6 percent of the total. That growth is somewhat unavoidable. But it's not unmanageable, either: communicate with high information density and you spend less of it. I single out raw voice transcription as a real offender here, since spoken prompts carry filler a typed one wouldn't, the ums, the pauses, the half-sentences repeated twice. When context is tight, my workaround is to send the raw transcript to a cheaper model first, have it compress the request down, then hand only the tight version to the main agent.

Claude's visible "Thinking" block works differently than it looks. It's a scratchpad for the current request, used once and then collapsed, and it isn't carried forward as a persistent message the way ordinary conversation history is, even though the computation behind it is still billed just the same. Just don't count it the same way you'd count a real message.

The single biggest category is free space. In my session, that was about 67.7 percent of the whole window, everything nobody had claimed yet. Below it sits the Autocompact buffer, a slice Claude Code holds in reserve for exactly this purpose. Once available room drops to around 33,000 tokens in my example, Claude compacts on its own rather than letting the window run all the way out, so you never actually hit a hard wall. You don't have to wait for that to happen automatically, either.

FIGURE 26 — Context growth and compaction lifecycle. Compaction doesn't erase history. It compresses it, then makes room for more.

Run /compact yourself. Claude takes the whole conversation, messages, tool calls, prior work, and compresses it into something much denser, rather than keeping every past exchange word for word. Ask what's left afterward and Claude typically reports the session continues from an earlier conversation already summarized: the first request, later questions, tool actions, problems hit and fixed, and whatever technical state still matters. By my own estimate, the compacted version can run three to four times leaner than what it replaced. Progressive compaction pushes that further, trimming filler while keeping the facts that matter. Automatic compaction runs the same idea continuously in the background, older messages condense while newer ones stay detailed, which I've found produces better output, simply because there's less clutter competing for attention. Claude's own documentation on reducing token usage names a few concrete strategies worth knowing: retrieval-augmented generation, periodically compressing CLAUDE.md itself, asking directly for concise output, and using extended thinking for reasoning while keeping the final response tight. It also names the problem these strategies fight: context rot, the slow buildup of low-value information as a session runs long. Treat all of it as current practice, not fixed law. This area shifts as the tooling does.

Managing context proactively

Waiting for it to trigger is one option. Watching it coming is another, and it's the one I recommend. /cost shows current usage on demand, which covers the basic case well enough for most sessions. A status line goes further than either of those, since it surfaces the same information continuously, right where you're already looking, so you never actually have to stop and ask.

FIGURE 27 — Managing context proactively. Small habits that keep you ahead of the limit instead of reacting to it.

Status-line configuration isn't available in the graphical app. It needs the terminal. There, /statusline asks what you want displayed, and you can just describe it in plain language instead of writing configuration by hand. I asked for a progress bar showing tokens used against total context, and Claude built it straight from that request, no manual scripting involved. The result sits quietly at the bottom of the terminal: a small bar, a running percentage, 13 percent, in my demo, plus the current model and repository branch. I don't call the feature essential. I like it anyway, as proof of how far the terminal can be customized past what the graphical app allows.

Try this with AI "Describe the status line you want in plain language, tokens used, current branch, whatever matters to you, and ask Claude Code to configure /statusline directly from that description."

One more habit worth adopting: give /compact explicit priorities. Don't just let it summarize generically. Tell it what to keep, test results, code changes, unresolved bugs, architectural decisions, and the summary that comes back protects exactly what the current task actually needs, instead of whatever a generic pass happens to preserve on its own. And when you're switching to something genuinely unrelated, reach for /clear instead. It drops the old context completely and starts clean.

The same session offers one more data point. Right after a /clear, a fresh conversation showed the Messages category down to about 152 tokens, concrete, if fleeting, evidence for a habit worth keeping in CLAUDE.md itself: tell Claude to reason as much as it needs internally, but keep the final response to essentials, adding detail only when you actually ask for it.

Model choice is a second lever. Route simple subagent work to a smaller model, Sonnet in my example, and the main conversation gets back only the useful result, not the working context the subagent burned through to get there.

MCP tools raise the same tradeoff a second time. A server exposing a very large tool count can eat a meaningful chunk of context before any real work starts, simply by existing. Claude doesn't have to load every one of those definitions up front, though. It can search for the tool it actually needs and load just that, and I show this against the Chrome DevTools MCP: search first, then pull in only the navigation tool the request calls for.

FIGURE 28 — Additional context-management levers. Six more habits, from right-sizing a subagent's model to front-loading research before a complex build.

That same instinct, move the detailed part out of the always-loaded prompt, applies to CLAUDE.md itself. A task-like set of instructions, as opposed to a permanent rule, belongs in a Skill that loads only when it's actually invoked, not in a file read at the start of every single session. That's the next chapter's whole subject.

/model, and the Thinking control that comes with it, is the more direct version of the same idea: turn reasoning effort down when a task doesn't need it, and up when it does. Agent Teams sit at the far, expensive end of that same spectrum. Separate context windows per teammate multiplied my own token cost roughly sevenfold in one example, especially once teammates start running Plan Mode of their own. That's not an argument against using them. It's a reason to reach for them on purpose, when the value is worth the cost, rather than by default.

Two smaller habits round out the list. Write specific prompts instead of vague ones. A narrower target costs you a little more thought up front, but it saves Claude from investigating a broad problem space it doesn't actually need to search. And for complex work, front-load the research, API calls, page retrieval, whatever the task needs, during planning, and settle on an approach before implementation starts, rather than researching again and again in the middle of a build.