Claude Code Session Management: Why I Stopped Restarting

I Injected a Test Marker Into My Auto-Memory File

Mid-session. On purpose. I wanted to know if Claude Code re-reads MEMORY.md every turn or loads it once at session start.

Added a unique string. Checked the next turn. The marker was invisible. Claude Code had no idea I changed the file.

That one test changed how I think about session management. The auto-memory file is read when a session starts, so a restart is where it reloads, and a new session only reuses the old session's cache in some cases. Every cache rebuild costs real money.

The free 3-pattern guide covers memory, delegation, and context management fundamentals. This post goes deeper into the session lifecycle most developers get wrong.

The Restart Reflex

Here is what most developers do when Claude Code hits 80% context: they start a new session. Fresh context, clean slate, feels productive.

Here is what can happen: the new session starts from a cold cache. Sequential sessions share the prefix only when the git status snapshot taken at startup matches, and an old entry that has outlived its TTL is gone anyway. In the worst case the new session reads nothing from the old one, and every token in the prefix - system prompt, tool definitions, CLAUDE.md, project rules - is billed as a cache write. That prefix is typically 50,000+ tokens. A cache read costs 90% less than base input on most models (95% less on Opus 5.5, 97.5% less on Fable 5.1 and Mythos 5.1). A cache write costs more than base input: 1.25x on the five-minute tier, 2x on the one-hour tier.

One cold restart. 50K tokens written to the cache instead of read from it. On Opus 5.5 that is $0.25 at the five-minute cache-write price ($5 per million tokens) or $0.40 at the one-hour cache-write price ($8 per million), against $0.01 to read the same 50K tokens from cache ($0.20 per million). Do that 10 times per day and you are paying $2.50 to $4.00 in cache writes against $0.10 to read those tokens from cache. Not because you did something wrong - because you did not know the cache existed.

But the money is not even the real problem. The real problem is lost momentum. Every restart means re-reading files, re-establishing context, re-explaining what you were working on. The first 3-5 turns of a new session are always the worst.

What Is Actually in the Cached Prefix

I mapped my own Claude Code session to understand what stays cached and what changes every turn. The results surprised me.

The prefix contains everything loaded at session start: the core system prompt, all tool definitions (including MCP tool stubs), your CLAUDE.md files, your .claude/rules/ files, and your auto-memory file. This is the cached part. It stays byte-for-byte identical across every turn within a session.

Everything else - conversation messages, tool results, hook outputs, skill metadata - gets injected via system-reminder tags into the conversation layer. This is the dynamic part. It changes every turn and is always recomputed. But critically, it does not touch the prefix. The cache stays intact.

That is why system-reminder tags exist. They are not a quirky implementation detail. They are the design pattern I call prompt infusion - Claude Code's mechanism for injecting dynamic information without touching the cached prefix. Your 60+ skills? Infused as conversation messages, not prefix entries. Hook outputs from your automation? Conversation messages. Git status snapshot? Conversation message. Even task tracking reminders get injected this way.

The principle is simple: the prefix is immutable after session start. Everything dynamic flows through the conversation layer via infusion. That is what makes the cache so stable under normal usage.

What Breaks the Cache (And What Does Not)

I tested and cataloged which actions are cache-safe and which cost a rebuild.

The safe list is longer than I expected. Sub-agent delegation, file reads, even editing your auto-memory file mid-session. All cache-safe. The prefix never changes.

Effort level is not on that list. On most models, changing the effort level mid-session means the next request reads the entire conversation history with no cache hits. On Opus 5.5, Sonnet 5.5 and Fable 5.1 with an API key or a Claude subscription, changing effort keeps the cache. That does not apply on Amazon Bedrock, Google Cloud's Agent Platform or a Claude apps gateway, when CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS is set, or under a HIPAA configuration. Turning on fast mode adds a request header that is part of the cache key, so the first request with fast mode on also misses the cache.

The dangerous list is short but severe. Switching models mid-session forces a complete cache rebuild because each model has its own cache keyed to its model ID. When you switch from Opus to Haiku, the Haiku model has no cached prefix - it rebuilds from scratch at full token prices. And /clear throws away the whole conversation, so the cache rebuilds from that point - by design.

The practical takeaway: pick your model at session start and stick with it. If you need a different model for a specific task, delegate it to a sub-agent. The sub-agent runs in its own session with its own cache. Your main session stays warm.

Context Drift: The Hidden Cost of Long Sessions

There is a subtlety the prefix cache does not solve. The conversation layer grows every turn. And because conversation tokens are always recomputed, your effective cache ratio drops over time.

The conversation is cached too: on a normal turn the cached prefix is the entire previous request, and only the latest exchange is new. What grows is the amount you read back every turn. Across 63,880 of my own requests the median session served 86% of its input from cache and the overall rate was 96.6% (what a long CLAUDE.md actually costs), so a long session is cheap per token but reads more tokens every turn.

This is context drift. The session gets progressively more expensive per turn - not because anything broke, but because the conversation keeps growing. Compaction is the answer. It compresses the conversation into a short summary; the system prompt layer stays cached, and the much shorter conversation is written to the cache fresh.

The Loop Strategy

Once I understood that session restarts are expensive and compaction resets context drift, the strategy became obvious. Stop restarting. Instead, save and compress.

When context gets high, I create a handoff document - a structured summary of current state, progress, and next steps - saved to disk. Then I let compaction handle the context pressure. The conversation gets compressed into a summary, the system prompt layer stays cached, and I keep working.

When context rises again, I repeat. Another handoff, another compaction. The handoffs stack on disk as a trail of checkpoints. If I ever need context from three cycles ago, I can read the handoff file.

The only reasons to actually start a new session: noticeable context drift, or a complete topic change where fresh context beats a warm cache.

What This Changes

The biggest shift is psychological. Hitting 80% context used to feel like a countdown. Now it is just a checkpoint. Save, compress, continue.

The irony: I built a tiered context loading system to minimize token usage. Turns out it was already cache-optimal by accident. On-demand rules loaded via file reads go to the conversation layer, not the prefix. Token efficiency and cache efficiency aligned without planning it.

Once you understand the one rule behind prompt caching - prefix matching requires static content first, dynamic content last - every optimization you build tends to reinforce it. Session management is no exception.

Updated 2 October 2026: the restart cost is recalculated at current Opus 5.5 prices, and the cache statements now match the current Claude Code docs on session scope, compaction, effort changes, fast mode and /clear. The section on cache drift no longer uses cache ratios I had computed rather than measured; it now cites the docs and my own cache measurement.