Long-Running Sessions and Context Management

The workflow#

Keep the live context narrow. Push intent and state into durable artefacts — plan files, memory files, scratchpads — that survive a context reset. Touch the same files in the same order to keep caches warm. Compact aggressively when the conversation grows. Treat each “chapter” of work as a freshly resumable unit, not as a continuous narrative.

Long sessions fail in one of two ways: the model loses track of where you are (drift), or it stops being economical (cost and latency creep up as the window fills). The workflow below addresses both. It treats the live conversation as a cursor, not as a history. The history lives on disk.

When to reach for it#

Reach for the long-session workflow whenever you expect to:

• Work on the same task for more than ~30 minutes of continuous wall time. Below that, default conversation-driven development is fine.
• Resume a task across multiple sittings. Today’s session needs to hand off cleanly to tomorrow’s.
• Coordinate work across multiple files and several rounds of verification. Multi-step migrations, cross-cutting refactors, debugging an intermittent failure.
• Use the same project context day after day. A daily-driver project benefits from intentional memory-file management even when individual sessions are short.

Don’t reach for this workflow when:

• The task is a single small change. Open, edit, verify, commit, close. Don’t perform process for its own sake.
• You’re truly exploring with no destination. Then the live conversation is the artefact. Just be aware you’ll lose it when context resets.

Step-by-step#

1. Open with a plan file, not a free-form prompt#

Before the first conversation turn, write a plan file. Not in your head — on disk. A markdown file with the goal, the rough plan, and the verification criteria. Something like PLAN.md or WORK.md at the repo root, gitignored or committed depending on the project.

The plan file is the single source of truth for what this session is about. When the conversation drifts, you point Claude at the plan. When the session resets, the next session starts by reading the plan. It’s cheap to write and pays for itself within an hour.

2. Pin the project conventions in CLAUDE.md#

The CLAUDE.md file at the project root is auto-loaded on every session. Use it for the things you don’t want to re-explain: the commands to run, the architectural quirks, the gotchas, the brand-policy rules. See CLAUDE.md and Memory Files for the full mechanics.

In a long session, CLAUDE.md is what keeps the model’s behavior consistent across hours. The model rereads it implicitly as it works; you don’t have to remind it that you use pnpm not npm.

3. Start in plan mode for anything non-trivial#

For a long session that’s also non-trivial in scope, plan mode is the right first step. Have Claude survey the relevant code, identify dependencies, and propose a sequence. Read the plan. Edit. Approve. Then leave plan mode.

The plan written here typically goes straight into your plan file — it’s the spec for the session.

4. Touch files in a stable order#

Claude Code uses prompt caching aggressively. Repeating the same prefix — same files read, in the same order — is cheap and fast. Jumping around is expensive and slow. Two principles:

• Read before you edit, in a consistent order. If you always read src/lib/foo.ts before src/api/foo.ts, the cache stays warm.
• Avoid touching unrelated files mid-session. If you need to look at something unrelated, finish the current step first and check it after a verification cycle.

This isn’t superstition; it’s how caching works. A long session with chaotic file access patterns can cost 3-5x what the same work costs with disciplined access patterns.

5. Verify often, compact when the window grows#

The conversation buffer is finite. As it fills, the model spends more on each turn and may start losing earlier context. Two cadences matter:

• Verification cadence. Run the tests, the type-checker, the lint — after every meaningful change. This is the same cadence as conversation-driven development; in long sessions it’s even more important because untested drift compounds.
• Compaction cadence. When the conversation gets long (rule of thumb: when scrolling back to the start takes more than three flicks), compact it. Use /compact (or whatever the slash command is in your version). The model summarizes the conversation and prunes the buffer; you keep working from the summary forward.

Compact before you hit the limit, not after. Compacting a near-full buffer loses more than compacting a half-full one.

6. Write state to disk at every chapter boundary#

A “chapter” is a natural unit of work: implementing one feature, fixing one bug, refactoring one module. At each chapter boundary:

• Commit the code changes. Always. Small green commits are the backbone of any long session.
• Update the plan file. Mark the chapter done. Update the next-step block. Add notes about anything you learned that the next chapter will need.
• Optionally update CLAUDE.md if you learned something durable about the project (a new convention, a hidden gotcha, a command).

This is what makes the session resumable. Even if Claude’s live context vanishes, the disk state encodes enough that tomorrow’s session — or a colleague’s session — picks up where today’s ended.

7. Use memory files for cross-session state#

Some state belongs in user-scoped memory, not project-scoped: your personal preferences, lessons learned across many projects, recurring gotchas. The memory file (~/.claude/...) auto-loads across sessions and projects. See CLAUDE.md and Memory Files.

For long sessions, the memory file is where you encode things like “I always want commit messages to follow this style” or “don’t poll background tasks.” Those preferences persist past any context reset.

8. Resume cleanly, don’t try to continue#

When you come back to a session — next day, next week — do not try to resume the previous live context. It’s gone or it’s stale. Instead:

• Open a fresh session.
• Read the plan file aloud (or have Claude read it).
• Read the last few commits.
• State the next intent.

The “fresh start, durable artefacts” pattern is faster than any attempt to re-prime an old session. You’re not losing context; you’re loading the right context fast.

Anti-patterns#

The shapes that don’t work:

• Treating the live conversation as the source of truth. When the context resets, you lose everything. Always have a disk artefact — plan file, CLAUDE.md, commits — that encodes the state.
• Skipping commits to “save them for the end.” Long sessions accumulate huge unverified diffs. One bad redirect 90 minutes in means losing everything since the last commit. Commit per chapter, minimum.
• Letting the conversation grow indefinitely without compacting. Past a certain point, every turn costs more and the model starts losing early context. Compact proactively.
• Compacting too aggressively. If you compact every three turns, the model loses fresh signal it would have used. There’s a middle band — compact when scrolling back to the start is annoying, not when the buffer is full.
• Chaotic file access. Reading a different five files on every turn defeats the cache. Stable access patterns matter much more than they look like they should.
• Writing the plan file once and not updating it. A stale plan is worse than no plan. Update at every chapter boundary.
• Trying to “resume” the old session days later. The live context is gone or stale. Start fresh, point at the plan, go. Faster.
• Stuffing CLAUDE.md with every detail. CLAUDE.md is auto-loaded on every turn. Every line costs you on every turn. Keep it tight; encode rare details in regular docs.
• Mixing chapters mid-session. Starting feature B before finishing feature A leaves both half-done with intertwined state. Finish chapter A — commit, update plan — then start chapter B.
• Ignoring the status line. The status line shows model, branch, and (often) token usage. In long sessions it’s the early-warning system for “compact soon.” Don’t ignore it.

Evaluation#

How do you know long-session management is working?

• You can resume next-day in under five minutes. Open the plan file, read the last commit, state the next intent, you’re working. If resumption takes longer, the disk artefacts aren’t carrying enough.
• The session doesn’t end because the context filled up. Sessions end because you finished the work or it’s time to stop. Hitting the buffer limit is a workflow failure.
• The same five files are in context most of the time. Sign of a stable, cached working set. Random file churn is a sign you’re letting the model wander.
• Commits are evenly spaced. Roughly one per chapter, every 15-45 minutes. Long gaps between commits mean chapters are too big or you’re under-committing.
• The plan file looks like a journal. Goal at the top, checkmarks down the side, notes from each chapter. If your plan file is one paragraph from hour zero and unchanged six hours later, you’re not using it.
• You don’t repeat yourself across sessions. If you keep re-explaining the same project quirk in every new session, that quirk belongs in CLAUDE.md.
• Cost per chapter is roughly flat. A four-hour session shouldn’t cost ten times what a one-hour session of the same work would. If it does, your cache is missing too often.

Related workflows#

• Conversation-Driven Development
• Plan Mode
• CLAUDE.md and Memory Files
• Context Window and Token Budget
• Headless / Non-Interactive Mode