Context Window and Dynamic Memory
The context window is finite and expensive. How Claude Code manages it, what dynamic memory does, and how to prevent session degradation.
You already know the context window is like RAM. You know it fills up. You know /cost and /compact exist. But the question that actually matters is different: what happens inside the machine when compaction fires? What survives? What gets destroyed? And can you control it?
This is where most people get burned. They understand the concept but not the mechanics. They lose critical context at the worst moment and blame Claude Code for "forgetting." It didn't forget. It did exactly what it was designed to do. You just weren't steering the process.
How Auto-Compaction Actually Works
When your conversation approaches the context window limit, Claude Code doesn't just chop off the oldest messages. That would be disastrous.
The actual sequence:
- Claude Code detects that token usage is approaching the ceiling.
- It takes the entire conversation history and generates a summary.
- The summary prioritizes recent context, key decisions, file states, and code patterns.
- The original messages get replaced with this compressed summary.
- Your CLAUDE.md files get re-read from disk in full. They always survive compaction completely intact.
- The session continues with a much smaller context window footprint.
The critical thing: compaction is lossy compression. The summary is Claude's best guess at what mattered. It keeps broad strokes. "We're refactoring the auth module" survives. "We decided to use a guard clause on line 47 instead of a nested if because the error handling path was cleaner" probably doesn't.
This is why you sometimes see Claude Code suddenly change direction after a long session. It compacted, lost a specific decision, and reverted to its default instincts. Not stubbornness. It genuinely doesn't have that information anymore.
What Survives and What Does Not
Not everything gets treated equally during compaction.
Always survives (re-loaded from disk):
- All your CLAUDE.md files. Every layer: global, project, local. Re-read fresh after compaction. This is the single most reliable way to ensure instructions persist.
- MEMORY.md auto-memory content. The first 200 lines survive because they're loaded at session start.
Usually survives (prioritized in summary):
- The most recent messages and tool outputs
- High-level decisions and architectural patterns
- File paths and names that were actively being worked on
- Error patterns that are still being debugged
Usually lost:
- Early messages from the beginning of the session
- Verbose command outputs (full build logs, large diffs)
- Intermediate reasoning steps
- Specific line numbers, exact variable names from early discussions
- Your stylistic preferences mentioned casually in conversation
This circles back to why CLAUDE.md matters so much. Anything you want Claude Code to respect across compaction boundaries has to live in a CLAUDE.md file. Telling Claude "always use early returns" in chat works until compaction fires. Put that same rule in your project CLAUDE.md and it's permanent.
Recognizing Degradation
Context degradation creeps in. It doesn't happen all at once.
Early signs (context getting full): responses take slightly longer, Claude Code re-reads files it already read earlier, asks you to confirm things you already told it.
Mid-stage (compaction has fired): contradicts earlier decisions, suggests approaches you already tried and rejected, code style drifts from what you established. Stops following conventions you mentioned only in chat.
Late-stage (this is bad): generates code that conflicts with recent changes, loses track of which files have been modified, responses become generic. You're repeating instructions more than twice.
When you see mid-stage signs, stop. Don't push through hoping it'll be fine. It won't. It only gets worse from there.
Strategies for Managing Dynamic Memory
There's more to it than watching /cost and running /compact when things get tight.
Focused compaction with /compact:
You can tell Claude Code what to prioritize when compacting:
/compact Focus on the API route changes and the validation schema we definedNot a magic command that guarantees preservation. But it biases the summary toward the topics you specify. Use it before you hit auto-compaction so you're in control of what gets kept.
Partial compaction with Esc+Esc:
If you want to summarize just a portion of the conversation (say, the first half where you were exploring, keeping the second half where you made real decisions), you can use Esc pressed twice to trigger a "summarize from here" operation. Finer control than /compact which processes everything.
Preemptive session splitting:
Check /context periodically. When you see usage climbing past 60-70%, ask yourself: am I about to start a new phase of work? If yes, that's your cue to start a new session. Capture key decisions in CLAUDE.md or in a quick note, run /clear, and start fresh with a focused prompt.
/contextThe colored grid makes this easy. Green squares mean room to work. Yellow means start thinking about wrapping up. Red means you should have split the session five minutes ago.
Use CLAUDE.md as persistent memory:
Anything critical goes in CLAUDE.md. Period. If you find yourself repeating an instruction after compaction, that instruction belongs in a file, not in your chat history. CLAUDE.md is the hard drive. The context window is RAM. You wouldn't store important data only in RAM.
Try It
Start a Claude Code session and work on something real for 15-20 minutes. Read a few files, make some changes, go back and forth. Then run:
/contextNote how much of the grid is filled. Now run focused compaction:
/compact Focus on the most recent file changes and any architectural decisionsRun /context again. See how much space you freed up. Now try asking Claude Code about something you discussed in the first few minutes of the session. Can it still recall the specifics? Or only the general idea?
This exercise teaches you viscerally what compaction keeps and what it throws away. That intuition is worth more than any documentation.
TL;DR
- Auto-compaction is lossy compression. Broad decisions survive. Specifics usually don't.
- CLAUDE.md always survives because it's re-read from disk. Instructions that must persist belong there, not in chat.
- Degradation signs (re-reading files, contradicting decisions, drifting code style) mean compaction has fired and context was lost. Don't push through.
- Run
/compactwith focus instructions before auto-compaction hits. You control what gets prioritized, or auto-compact controls it for you. - Split sessions at 60-70% usage. By the time you see red squares, you're already too late.
Mastering Claude Code
Lesson 16 of 70