My Claude Code Memory File Was Eating 20% of Every Session

I was three weeks into building a content dashboard with Claude Code. The project was going well. Claude remembered my preferred stack, my naming conventions, my deployment workflow. Every session picked up right where the last one left off.

Then something shifted. New sessions started feeling sluggish. Claude’s responses were slower to arrive and slightly less sharp. I assumed it was a bad day on the servers. Kept working. But the pattern held. Every new session felt heavier than it should.

So I ran /context.

What I Found in My Claude Code Memory

The context breakdown showed 20% of my window used before I had typed a single word. Not from my conversation. Not from files I had opened. From memory.

I knew Claude Code had a memory system. I had been happily telling it to remember things for weeks. ‘Remember we use Tailwind.’ ‘Remember the API endpoint changed.’ ‘Remember the database schema looks like this.’ Every time, Claude dutifully saved it. What I did not realise was where all of that was going.

The file lives at ~/.claude/projects/<project>/memory/MEMORY.md. I opened it and found 190 lines of accumulated notes. Every preference, every correction, every architectural decision from three weeks of work, all stuffed into a single file.

Here is the thing about MEMORY.md that most people miss: the first 200 lines are loaded into every session. All of them. Whether you need them or not. My file was approaching that ceiling, and every single line was being injected into Claude’s context window at startup.

That is your context window. The same space Claude needs for reading your code, understanding your questions, and generating responses. I was burning a fifth of it on memory before the conversation even began.

The Problem With ‘Remember Everything’

Most Claude Code advice tells you to build up your memory. Teach Claude your project. Save your preferences. The more it knows, the better it works.

That is true up to a point. The point is about 200 lines.

Beyond that, you are not making Claude smarter. You are making it slower. Research on large language models consistently shows that performance degrades as the context window fills up. It is not just about running out of space. The quality of responses drops when the model has to process more information upfront, even if that information is technically relevant.

I had been treating MEMORY.md like a notebook with infinite pages. It is not. It is more like a whiteboard in a small room. The more you write on it, the harder it is to find what matters.

How I Restructured My Claude Code Memory

The fix was simple once I understood the problem. Instead of keeping everything in MEMORY.md, I turned it into a pointer file.

Here is what my MEMORY.md looks like now:

## Project: Content Dashboard
- Stack: Next.js, Tailwind, Supabase
- Deploy: Vercel via GitHub Actions

## Guides (read only when needed)
If the conversation involves these topics, read the file before responding:
- Database schema and queries → ./memory/database.md
- API routes and authentication → ./memory/api-patterns.md
- Component conventions and styling → ./memory/frontend.md
- Deployment and environment config → ./memory/deploy.md

Do NOT load these files at session start.

That is about 15 lines. The detailed notes that used to bloat the main file now live in separate topic files inside the same memory directory. Claude reads them only when the conversation actually touches that topic.

The database schema? Only loaded when I am working on queries. The deployment configuration? Only loaded when I am pushing to production. The frontend conventions? Only loaded when I am building components.

What Changed After the Fix

The difference was immediate. New sessions started at around 9% context usage instead of 20%. That might sound like a small win, but it compounds across every interaction in the session. More free context means Claude has more room to think, more room to hold your code in working memory, and more room before it needs to compact the conversation.

The responses got noticeably better too. Not because Claude had less information available. It had exactly the same information. But it was only loading what it needed, when it needed it. Focused context produces better output than bloated context. Every time.

If you have been using Claude Code /insights to review your working patterns, you will recognise the principle. It is not about having more. It is about having the right things at the right time.

How to Check If You Have the Same Problem

Open your terminal and run:

cat ~/.claude/projects/*/memory/MEMORY.md | wc -l

If that number is approaching 150 or above, you are probably paying a context tax on every session. Open the file and look at what is in there. You will likely find detailed notes that are only relevant to specific parts of your project, sitting alongside the handful of rules that actually matter every time.

You can also run /context at the start of a fresh Claude Code session before doing anything else. If the memory files section shows more than a few hundred tokens, it is worth investigating.

The Pointer File Pattern

The approach I landed on is not something I invented. Anthropic’s own documentation describes MEMORY.md as a ‘concise index’ with optional topic files alongside it. There is even a detailed write-up of this pattern on GitHub that calls it the ‘Slavka Memory Pattern’ and frames it as giving Claude unlimited scalable memory within a fixed context window.

The mental model that helped me most: MEMORY.md is RAM. It is always loaded, so keep it small. The topic files are storage. Fast to access when needed, zero cost when not.

Three rules made the biggest difference:

First, keep MEMORY.md under 50 lines. Rules and pointers only. If a note needs more than one line of explanation, it belongs in a topic file.

Second, use clear trigger phrases. Telling Claude ‘read this file if the conversation involves database queries’ gives it a reliable signal for when to load additional context. It respects these instructions well.

Third, review the file regularly. Claude adds to its memory automatically during sessions. Left unchecked, it creeps back towards bloat. I now scan MEMORY.md every week or so and move anything detailed into the appropriate topic file.

The Bigger Lesson

The real takeaway is not about memory files. It is about a pattern that comes up constantly when working with AI tools: more is not always better.

More context is not better. More instructions are not better. More memory is not better. What is better is the right information, delivered at the right moment, in the right amount.

Stop treating your Claude Code memory like a diary. Start treating it like a table of contents. Your sessions will be leaner, your responses sharper, and your context window will finally be yours again.

If you want to go further and teach Claude reusable workflows (not just memory), try building a custom Claude Skill.