Bonus Essay — “Inside Claude’s Cognition” Series
After reading Part 3: The Cockpit, a natural question comes up: Claude Code already saves sessions, can compact them, and lets you resume them. Isn’t that enough? Do you really need memory files, phase specs, and all the discipline from Part 4?
Short answer: the built-in features are genuinely good. They solve a real problem. But they solve a different problem than the memory system does. This essay explains both — what the built-ins actually do, where they run out, and what the memory system handles that they can’t.
The Built-in Features — What They Actually Do
Session Save and Resume
Every Claude Code session is automatically saved. You can list saved sessions and continue any of them:
/rename my-darjs-phase6-session # name the session before closing
/resume # search and continue a previous session
When you resume, the full conversation history is loaded back into context — every turn, every tool call, every code block you showed me, every response I gave.
This is more powerful than it sounds. You genuinely pick up where you left off. I remember what we were debugging, what decision we just made, what file we were looking at. For a session you closed an hour ago and want to continue, resume is exactly right.
Auto-Compact
When the context window fills up (approaching 100%), Claude Code automatically compresses the oldest conversation turns into a condensed summary block. Recent turns are kept in full. Your CLAUDE.md and memory files are re-injected. The percentage drops, new space opens up.
You don’t trigger this — it happens automatically when needed.
What’s preserved:
- Recent conversation turns (kept verbatim)
- CLAUDE.md files (always re-injected)
- Auto-memory files (re-injected)
What’s compressed:
- Older turns, replaced by a summary
- Fine-grained reasoning from early in the session
Manual /compact [instruction]
You can trigger compaction yourself before it auto-triggers, and give me guidance on what to preserve:
/compact Focus on the architectural decisions about the layer boundaries
/compact Preserve the Phase 6 test results and what broke in the adapter
This is strictly better than waiting for auto-compact, because you control what survives the compression. Run it when you sense the context is getting heavy but you haven’t hit the wall yet.
Checkpoint and Rewind
/checkpoint # save the current conversation state
/rewind # restore to the last checkpoint
Think of this as git stash for conversations. If I go down the wrong path — start a refactor that makes things worse, misunderstand the requirement and implement the wrong thing — you can rewind to before it happened. No lost work, no “undo everything I just did.”
Where Each Feature Runs Out
These are all genuinely useful. But each one has a specific failure mode when projects get larger.
Session Resume: The Multi-Thread Problem
Resume works on one session at a time. A project that runs across ten sessions — Phase 1 session, Phase 2 session, Phase 3 session, and so on — is ten separate threads.
Resuming session 4 gives you session 4. It doesn’t give you the work done in sessions 5–10.
Session 1 → Phase 1 decisions
Session 2 → Phase 2 decisions
Session 3 → Phase 3 decisions
Session 4 → Phase 4 decisions ← resume this
Session 5 → Phase 5 decisions ← lost
Session 6 → Phase 6 decisions ← lost
And even if you could load all sessions, loading ten full conversation histories would cost enormous tokens — far more than a lean memory file.
There’s also the cost problem. Each session resume loads the entire turn history into context before anything else. A long session with file reads, code blocks, and tool outputs can easily consume 30–50% of your context budget just by resuming. You haven’t done anything yet and you’re already in the yellow zone.
Auto-Compact and Manual Compact: Still In-Session
Compaction solves an in-session problem. The oldest turns get compressed into a summary, the percentage drops, the session continues.
But the summary lives inside the session. When you close that session and open a new one, the compacted summary is gone. A new session starts blank.
The other issue is loss. A good compaction preserves the spirit of what happened. It doesn’t preserve the specifics. “We decided to use MemoryAdapter for testing” survives compaction. “Here’s the exact interface MemoryAdapter must implement, line by line” probably doesn’t. Decisions that live only in conversation turns eventually become summaries, then are lost.
And manual /compact [instruction] is better than auto, but you’re still making a bet — trusting that your instruction captured everything worth keeping. Anything you didn’t mention is at the mercy of the compression algorithm.
Checkpoint and Rewind: Point in Time, Not Project History
Checkpoints are snapshots of a single conversation moment. They’re excellent for “undo” within a session. They don’t help with “I started this project three weeks ago, what was the state at the end of Phase 3?”
Checkpoints also don’t travel. They live inside one session, on one account, tied to one tool. Switch to a different AI tool, have a colleague pick up the project, or return after your session history was cleared — and the checkpoints are gone.
What the Built-in Features Cannot Do
Let me be concrete. Here’s what none of the built-in features solve:
1. Cross-session synthesis. Ten sessions of work on DarJS contain decisions from all ten sessions. There’s no built-in way to synthesise them into a current-state view. A memory.md file is that synthesis — you write it as decisions are made, and it accumulates the truth across all sessions.
2. Cheap cold starts. A memory.md for a mature project is 150–300 words. Loading it costs me ~50–100 tokens. Resuming a session costs me the entire session history — potentially tens of thousands of tokens — before I’ve answered a single question.
3. Portability. Session history belongs to your account on one tool. If you move from Claude Code to Cursor, from Anthropic’s API to a local Llama, or hand the project to another person — the session history doesn’t travel. Markdown files in your repo travel everywhere.
4. Objective project state. “Phase 3 is done” is a prose claim. “Phase 3: 48 tests passing” is an objective fact I can verify in two seconds by running the test suite. The memory system records objective states. Session summaries record prose approximations.
5. Architecture enforcement. No built-in feature stops me from letting Layer 3 code import directly from Layer 1. The layer boundary rules in a phase spec do. Built-ins manage conversation state; they don’t manage architectural discipline.
6. Version control. Session history isn’t in git. A memory.md file is — every decision is a commit, every architectural choice has a timestamp and an author. You can see exactly when a decision was made, revert it, branch from it, review it in a PR.
They Solve Different Problems
Here’s the clearest way to see the distinction:
| Problem | Built-in Features | Memory System |
|---|---|---|
| Continue a session I closed an hour ago | ✅ Session resume | — |
| Recover when I go down the wrong path | ✅ Checkpoint + rewind | — |
| Manage context filling up mid-session | ✅ Auto/manual compact | — |
| Synthesise 10 sessions into current state | ❌ | ✅ memory.md |
| Start a new session cheaply with full context | ❌ | ✅ lean index files |
| Share project state with another person or tool | ❌ | ✅ markdown in repo |
| Enforce layer boundaries and architecture rules | ❌ | ✅ phase specs + layer rules |
| Objective exit criteria for a phase | ❌ | ✅ test counts |
| Version-controlled decision history | ❌ | ✅ git commits |
The built-ins handle within-session continuity. The memory system handles cross-session coherence and architecture.
How They Work Together
These aren’t competing approaches. They’re complementary layers — the same relationship as auto-compact (in-session) and memory.md (cross-session) described in Part 1.
A well-set-up project uses both:
Built-in resume → continue a session from today or yesterday
Built-in compact → manage context pressure during long sessions
Built-in rewind → undo mistakes within a session
memory.md → current project state, always ~150 words
phase specs → what this session needs to implement, self-contained
CLAUDE.md → standing instructions, auto-loaded every session
ANALYSIS.md → full issue inventory (loaded on demand, not always)
The practical result: a new session on a mature project loads memory.md (100 tokens), loads the current phase spec (500 tokens), runs the tests (2 seconds), and is at full capacity. No resuming a stale session, no paying for 40k tokens of conversation history I mostly don’t need.
When Are the Built-ins Enough?
Honest answer: for short projects, the built-ins are often enough.
- A single-session project (a script, a quick feature): just work in one session, maybe use checkpoint before a risky change. Done.
- A 2–3 session project: session resume keeps you oriented, one memory.md captures the key decisions. Light touch.
- A multi-week project with multiple layers: you need the memory system. The built-ins become tools within a well-structured project, not a substitute for structure.
The built-in features reduce how much ceremony you need for small work. They don’t eliminate the need for structure in large work.
The One-Line Summary
Built-in features manage the conversation. The memory system manages the project.
A conversation is what happened between us in one thread. A project is the accumulated state of decisions, architecture, and working code across every session, every tool, and every person who touched it.
You need both. They do different things.
Filed under: Session resume, compaction, memory system, Claude Code, context management.
Date: 2026-04-24 · Reading time: ~10 min