Your Context Window Is a Budget
Most of the advice about "managing context" treats it as housekeeping — tidy up when things get messy. That framing misses what's actually happening. The context window is a budget you spend on every single turn, and a chunk of it is gone before you type a word. Once you see the budget, the commands that manage it stop being magic and start being obvious.
The part that surprises people
Here's the fact that reframes everything, and it catches a lot of people off guard: the model is stateless. It doesn't "remember" your conversation the way a person in a meeting does. Between one message and the next, it retains nothing.
So how does it follow a long thread? Because the entire conversation is re-sent every time. When you send your tenth message, what actually goes to the model is messages one through nine, every tool call and its output, every file it read, the system prompt, all the tool definitions — and then your tenth message tacked on the end. The model reads the whole pile from scratch, answers, and forgets it again. Your eleventh turn re-sends all of that plus the tenth exchange.
The mental model
Every turn is a fresh exam where the model re-reads the entire packet before answering. The "conversation" is an illusion maintained by re-sending the transcript. That's why a long session feels slower and costs more as it grows — the packet it re-reads keeps getting thicker.
The context window is the hard size limit on that packet. Everything has to fit: the fixed scaffolding, the whole history, and enough headroom left over for the model to actually think and reply. When people say a session "ran out of context," they mean the packet hit the ceiling. And critically — every token of fixed overhead isn't paid once. It's re-sent on every turn, for the life of the session.
Read the meter: /context
You don't have to guess what's in the packet. /context itemizes it. Here's a real reading from a fresh session of mine — before I'd asked for anything:
## Context Usage
Model: claude-opus-4-8
Tokens: 13.1k / 1m (1%)
| Category | Tokens | Percentage |
|------------------------|--------|------------|
| System prompt | 2.4k | 0.2% |
| System tools | 5.7k | 0.6% |
| System tools (deferred)| 11.5k | 1.1% |
| MCP tools (deferred) | 1.5k | 0.1% |
| Custom agents | 348 | 0.0% |
| Skills | 2.4k | 0.2% |
| Messages | 2.2k | 0.2% |
| Free space | 986.9k | 98.7% |Read past the comfortable percentages — this window happens to be a large one, so the fractions look tiny. The line items are the point. Before a single instruction, I'm carrying a system prompt, a toolbox, custom agents, and a stack of skills. On a 200K-token model that same overhead is a much bigger slice, and remember the multiplier from above: it rides along on every turn. This is a recurring tax, not a one-time setup cost.
Two things in that readout are worth calling out, because they're levers most people never touch.
Cut the fixed costs first
Notice the (deferred) labels. Claude Code doesn't load every tool's full definition into the window up front; many are kept out and pulled in on demand. That's the system quietly protecting your budget — and it's a hint about where the budget goes when you're not careful.
The usual culprit is MCP servers. Every MCP tool you connect adds its schema to the toolbox, and as Claude Code itself puts it, those "all count toward your limit." Connect three chatty MCP servers and you can spend thousands of tokens per turn describing tools you aren't using in this session. The fix is unglamorous and effective: disable the servers you don't need for the task in front of you. Same logic for an overstuffed CLAUDE.md or a pile of always-on skills — every line is re-sent forever. Trim the fixed costs and you've widened the budget for every turn at once, which is a far bigger win than tidying up one long answer.
/compact vs. letting it auto-compact
When the history itself gets heavy, /compact replaces the older turns with a summary — lossy, but it keeps the thread's state while reclaiming space. The summary stays; the verbose logs that produced it go.
If you don't do this yourself, Claude Code will eventually do it for you: auto-compact kicks in as you approach the limit. Useful as a safety net, but the tool is blunt about the tradeoff — it "discards older messages," and its own hint is telling: "Use /compact now to control what gets kept." That's the difference. Auto-compact decides what to drop; manual /compact lets you steer it:
/compact keep the API schema decisions and the failing test; drop the file dumps
Reach for it at a natural seam — a sub-task just finished, a bug is fixed — so the summary captures a clean state rather than the middle of a thought. You can tune or disable the automatic behavior in /config if you'd rather always pull the trigger by hand.
/clear vs. /rewind
/compact compresses. The other two reset, and they're not the same reset.
/clearwipes the conversation and starts fresh. When you finish one task and move to something unrelated, clear — there's no reason to keep re-sending the old thread, and a clean window is faster, cheaper, and free of stale assumptions bleeding into the new work./rewind(or tapping Esc twice) is the surgical option: roll back to an earlier checkpoint — the conversation, the files it changed, or both. When a session takes a wrong turn and three messages of flailing have polluted the context, you don't have to nuke everything and re-explain. Rewind to just before it went sideways and continue from a clean point.
Quick rule
Done with this task → /clear. This task went wrong → /rewind. This task is long but healthy → /compact. Three different problems, three different tools.
Spend the budget somewhere else entirely
The best context management is often not spending the budget in your main session at all. When a task needs a lot of reading — hunting through a sprawling codebase, scanning logs, comparing a dozen files — that exploration can dump tens of thousands of tokens into your window, and you only wanted the conclusion.
Hand it to a subagent instead. Claude Code spins up focused subagents for exactly this: the subagent burns its own context window doing the messy search, then reports back a short answer. The noise stays in the subagent; only the finding lands in your main thread. It's the cleanest way to investigate something big without paying for the whole investigation in the window you're trying to keep lean.
And to actually watch the meter over a session, /cost and /usage show what you're spending — the feedback loop that turns "context management" from a vague virtue into something you can see.
The discipline
None of this is fiddly optimization. It falls straight out of one fact: the model re-reads the entire packet on every turn, and that packet has a ceiling.
- Run
/contextearly to see your fixed costs — the tax you pay every turn. - Cut overhead first: disable unused MCP servers, keep
CLAUDE.mdlean. It widens every turn at once. - Offload heavy reading to subagents so exploration doesn't bloat your main window.
/compactat clean seams on long tasks; steer what survives instead of letting auto-compact guess./clearbetween tasks,/rewindwhen one derails.
Treat the window as a budget you re-spend every turn, not a drawer you tidy when it overflows, and the model stays fast, sharp, and cheap for far longer.