Claude Code memory management: how to survive long sessions without losing context

If you've used Claude Code for anything serious, you've hit this wall: you're deep into a refactor, you've explained the architecture three times, and then Claude starts giving answers that feel… disconnected.

It hasn't crashed. The context window just got too full, and something got dropped.

Here's how I manage this.

The problem: what actually happens

Claude Code has a context window limit. When you hit it, the model starts silently dropping older messages. It doesn't tell you. It doesn't warn you. It just quietly forgets.

The failure mode looks like this:

• Claude stops following your CLAUDE.md rules
• It "forgets" decisions you made 30 minutes ago
• It suggests code that contradicts what you've already built
• It starts asking questions you've already answered

Fix 1: Checkpoint summaries

Every 20-30 messages, ask Claude to write a checkpoint:

Write a 200-word summary of: what we've built, what decisions we've made, what's left to do. Save it to CHECKPOINT.md.

Then at the start of the next session:

Read CHECKPOINT.md before we continue.

This is the simplest approach and it works.

Fix 2: CLAUDE.md as persistent memory

Your CLAUDE.md is loaded at the start of every session. Use it to store things Claude needs to always know:

# Architecture decisions
- Database: PostgreSQL via Prisma (NOT raw SQL)
- Auth: JWT with 7-day expiry (NOT sessions)
- Error handling: always throw, never return null
- API style: REST, no GraphQL

# Current state
- Last working on: payment flow in /src/billing
- Next task: webhook handler for Stripe
- Blocker: Stripe test keys needed

This survives context resets because it's read fresh every session.

Fix 3: The /compact command

Claude Code has a built-in /compact command that summarizes the conversation and resets context while preserving key information.

Use it proactively — don't wait until you're seeing weird behavior.

I run /compact after:

• Finishing a major feature
• After any big debugging session
• Before switching to a different part of the codebase

Fix 4: Project state files

For long-running projects, I maintain a STATE.md that Claude updates at the end of each session:

# Project state as of 2026-04-01

## Completed
- User auth (JWT, refresh tokens, email verification)
- Payment flow (Stripe checkout, webhooks)
- Admin dashboard (basic CRUD)

## In progress
- Email notifications (50% done, template system needed)

## Decisions made
- Using Resend for email (not SendGrid)
- Rate limiting at nginx level, not app level
- No background jobs yet (will add BullMQ when needed)

## Known issues
- Webhook signature verification has intermittent failures
- Need to add retry logic

Start each session with:

Read STATE.md. We're continuing from where we left off.

Fix 5: Use ANTHROPIC_BASE_URL for cost control

Long sessions get expensive fast on Claude Pro ($20/month). I use SimplyLouie as my ANTHROPIC_BASE_URL — it's a flat $2/month regardless of how many tokens I burn.

export ANTHROPIC_BASE_URL=https://api.simplylouie.com
export ANTHROPIC_API_KEY=your_key_here
claude

Setup: simplylouie.com/developers

With flat-rate pricing, I stopped worrying about session length and started writing more thorough CLAUDE.md files — which ironically made the context management problem less severe.

The real lesson

Context management isn't about fighting Claude's limitations. It's about building habits that work WITH the architecture:

1. CLAUDE.md = what Claude always knows
2. CHECKPOINT.md = what happened in this session
3. STATE.md = project-level continuity
4. /compact = when things get messy mid-session

These four things together mean I've never lost a session to context overflow in the last month.

---

What's your Claude Code session management setup? Share in the comments.