Memory and Continuity Across Sessions

Series: Claude Learning Journey · Core Workflows

Every time you start a new conversation with Claude, it has no memory of previous sessions. You could spend an hour explaining your codebase, your preferences, your project’s quirks, and the next day it would be gone. This sounds like a fundamental limitation, but it is actually solvable — you just have to build the memory yourself.

Why Claude does not remember

Each conversation is an isolated context window. Claude reads everything in the current thread and nothing outside it. This is a technical constraint, not a design choice by Anthropic. The model is not being forgetful — it literally does not have access to what happened before the current session started.

The solution is to give Claude a memory that it can read at the start of each session.

The file-based memory pattern

The simplest durable memory is a set of files that Claude reads at the start of each session. These files contain anything you want Claude to remember:

• Your name and how to address you
• Key details about your projects
• Your preferences and working style
• Anything you have learned that you want to be able to act on later

Session start:
1. Read memory/2026-04-12.md
2. Read MEMORY.md
3. Read PROJECT_CONTEXT.md (if it exists)

This is exactly how the setup described in this series works — startup files that load context before the first exchange is complete.

What to put in memory files

Identity: Who you are, what you prefer, how to address you. This means Claude does not have to ask basic questions every session.

Project context: What you are working on, the current state, active problems, recent decisions. A session that starts with “I am working on the payments module and I fixed the webhook routing yesterday” is much more productive than a session that starts with nothing.

Patterns and conventions: Your code style preferences, your team’s conventions, things you have learned that you do not want to repeat. “We always use feature flags for database migrations” is useful to have written down.

Lessons learned: Bugs you have fixed, mistakes you have made, context that would have prevented a wrong turn. Writing “do not use SQLite for concurrent writes in production” costs you 5 minutes now and saves you an hour later.

The daily log pattern

A daily log captures what happened today. It is raw and unorganised — notes, decisions, things to follow up on. The value is in having somewhere to put things without worrying about organisation.

memory/
  2026-04-12.md   ← what happened today
  2026-04-11.md   ← yesterday's session

At the end of each session, or whenever something worth remembering happens, write it to today’s file. Future sessions can read the last few days to get recent context.

Memory decay and maintenance

Memory files rot if they are not maintained. Stale information is often worse than no information — it leads Claude astray with false confidence.

A weekly review habit works well: read through the last week’s daily logs, identify anything worth promoting to long-term memory, update the persistent files, archive or delete the daily logs older than a month.

The daily files are raw notes. MEMORY.md is curated wisdom.

Context windows and memory efficiency

A 200,000 token context window sounds large until you are working on a large codebase. Every token spent on memory is a token that is not available for your current task.

Keep memory files concise. A MEMORY.md that is 10,000 tokens long will consume a significant portion of your working context and may be summarised by the model (and summarisation loses detail).

Practical memory file sizes:

• Long-term memory: under 2,000 tokens
• Daily log: typically 500-1,500 tokens
• Project context per project: 500-1,000 tokens

What memory cannot solve

Some continuity problems are not solved by files:

Cross-project context: If you switch between projects, memory about project A may confuse work on project B. One pattern is separate memory files per project, loaded only when that project is active.

Real-time state: Memory files cannot know what changed in your repo this morning. For that you need tools — git log, file reads, CI status checks. Memory tells Claude what it needs to know about the project. Tools tell it what is actually happening right now.

Private information: Memory files on disk are readable by anyone with file access. Do not put passwords, API keys, or sensitive personal information in them.

Try it yourself

Create a memory/ directory in your workspace. Add a MEMORY.md file with your name, what you are working on right now, and one thing you want to remember from today. At the start of your next session, ask Claude to read those files before doing anything else. Notice how much faster you can get to productive work.

What’s Next

The next post covers getting structured output from Claude — JSON, markdown tables, and other formats that make it easy to parse Claude’s responses programmatically.

Part of the Claude Learning Journey series · Next: Getting Structured Output: JSON, Markdown, and More