DEV Community: Alfredo Izquierdo

Claude Code Compaction: Why Your Session Forgets Mid-Task (and the Fix)

Alfredo Izquierdo — Thu, 24 Sep 2026 17:00:43 +0000

Last week I published a piece about handing off a Claude Code session without re-explaining everything. A reader left a comment that stuck with me: "Compaction is the limit that actually bites." He was right, and I'd glossed over it. So this post is the one I should have written first.

If you searched for "claude code compaction" because your session suddenly stopped knowing things it knew an hour ago, here's what's going on, what actually survives, and the small hook I shipped to fix the part that hurt me most.

TL;DR: When a Claude Code session gets long, Claude summarizes the conversation to free space. The summary keeps the gist and drops the details, and the details are usually your decisions. You can't see what got cut. The fix is to keep decisions outside the conversation and put them back after every compaction. ContextForge 0.12.0 does that with a Claude Code hook that runs automatically.

What compaction actually does

Every model has a context window, and a working session fills it fast: file reads, tool output, your back-and-forth. When Claude Code gets close to the limit, it compacts. It writes a summary of everything so far, throws away the original messages, and keeps going with the summary plus whatever hadn't been summarized yet. You can trigger it yourself with /compact, and it also happens on its own when the window fills up.

From the outside it looks harmless. The status line says "Compacted," the conversation continues, and Claude still sounds like it knows what you're doing. That's the trap.

Why you can't tell what you lost

Here's the part my reader nailed. After a compaction you get the summary plus the tail of messages that hadn't been folded in yet. Where that cut lands depends on the exact moment compaction fired. So no two resumes give you the same context, and from inside the session there's no seam to look for. The summary reads as complete.

What actually falls out is predictable, though. Summaries are good at "we're refactoring the retry logic." They're bad at "retry logic goes in the client, not the handler, and we dropped the Redis layer because it added 40ms for nothing." The gist survives. The decisions evaporate. You find out when Claude cheerfully re-adds the caching layer you removed two hours ago.

What survives a compaction

The gist of the task: kept, as a summary.
Recent messages (the tail): kept verbatim, but which ones depends on timing.
Specific decisions and their reasons: usually gone.
Tool output and file contents you discussed: gone.
Anything saved outside the conversation: untouched.

That last line is the whole strategy. --resume won't help you here, because it brings back the same compacted transcript. CLAUDE.md helps for the stable stuff, but it goes stale the moment your decisions move faster than you edit the file (I wrote about that in Why Your CLAUDE.md Goes Stale). What you want is the handful of decisions, stored somewhere compaction can't reach, and reloaded the instant the cut happens.

The fix: a hook that runs after every /compact

Claude Code has a hooks system, and one of the events is SessionStart with a compact matcher. Anything a command prints there gets added straight into Claude's context right after the summary. That is exactly the moment we need.

So in ContextForge MCP 0.12.0, init installs this into your project's .claude/settings.json:

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "compact",
        "hooks": [
          { "type": "command", "command": "npx -y contextforge-mcp recall" }
        ]
      }
    ]
  }
}

What the hook does after every /compact

recall is a new subcommand. It reads which project this folder is linked to, fetches the 10 most recent memories saved for that project and up to 5 pending tasks, and prints them as plain text. Claude Code appends that text to the context. From Claude's point of view, the decisions were never gone.

Here's what it looks like in the terminal, right after a compaction:

A few things I cared about while building it:

It can never break your session. No API key, no linked project, no network, or more than eight seconds: it prints nothing and exits cleanly. You'd never know it ran.
It's a tool call, not magic. The hook is a shell command. You can run npx contextforge-mcp recall yourself from the project folder and see exactly what Claude will see.
It's fast. About four seconds, most of it waiting on the network.

Setting it up

New to ContextForge? Install the MCP server the usual way, then run this once in your project:

npx contextforge-mcp init

That writes the memory rules to your CLAUDE.md and, on Claude Code, adds the hook. Nothing else to configure. Full steps are in the docs.

Already using it? Update to 0.12.0 and re-run init in each project. It's idempotent: it only adds what's missing and leaves your existing settings.json and hooks alone.

npx contextforge-mcp --version   # should say 0.12.0 or newer
npx contextforge-mcp init        # adds the hook, prints "already present" next time

Then test it: run /compact in a session and ask "what context did you just receive?" If Claude quotes a block that starts with "ContextForge: context restored after compaction," you're set.

Where it falls short

I'd rather you know this now than find out later.

It only brings back what was saved. If nobody saved the decision, there's nothing to restore. The habit that does the real work is asking the agent to save decisions as you go, and "save where we are and what's next" before you close the terminal.
It still can't tell you what the summary dropped. Nobody can. What it does is make that question matter less.
Claude Code only. Cursor and Copilot don't have this hook system. The same saved memories are there when you open the project in those tools, but the automatic re-injection is a Claude Code feature.
Your project has to be linked. The hook needs a .contextforge file in the repo root to know which project's memories to fetch. Ask the agent to "link project" once and you're done.

FAQ

Does compaction happen without me asking?
Yes. Claude Code compacts automatically when the context window fills up, and you can trigger it manually with /compact. Both fire the hook.

Does this replace --resume?
No. --resume reopens a session on the same machine; use it. The hook covers what --resume can't: the decisions that a compaction summarized away. They complement each other.

Can I see what the hook sends?
Run npx contextforge-mcp recall from the project folder. It prints exactly the block Claude receives, or nothing if the project isn't linked or the API key can't be found.

Why did the hook print nothing for me?
The usual causes: an old CONTEXTFORGE_API_KEY exported in your shell that overrides the one in ~/.claude.json, an older global install of contextforge-mcp shadowing npx, or the project isn't linked yet. The docs have a short troubleshooting list.

Compaction isn't a bug. It's the price of long sessions, and the alternative is a session that stops working. The mistake I made for months was treating the transcript as the thing worth keeping. It isn't. The decisions are. Keep those outside the conversation, hand them back at the right moment, and compaction becomes something you stop noticing.

If you want to try it, ContextForge has a free tier and the setup is three commands. And if you're the reader who left that comment: thank you. You were right.

Claude Code Session Handoff: How to Resume Work Without Re-Explaining Everything

Alfredo Izquierdo — Wed, 23 Sep 2026 14:56:19 +0000

Claude Code Session Handoff: How to Resume Work Without Re-Explaining Everything

Tuesday, 4:50 pm. I'm forty minutes into moving our payment retry logic out of the request handler and into the client, Claude Code has the whole shape of it in its head, and a calendar reminder pops up. I close the terminal. Wednesday morning I open it again, type "continue the retry refactor," and get a polite question back: which retry refactor? Everything we'd worked out the day before was gone.

If you searched for "claude code session handoff how to resume work," you've had that morning too. The good news is that Claude Code has a real answer for the simple case. The bad news is that the simple case is smaller than it looks.

What Claude Code Gives You Out of the Box

Claude Code keeps your sessions on disk. Two flags bring one back:

claude --continue      # reopen the most recent session in this directory
claude --resume        # pick from a list of past sessions

That restores the conversation: what you asked, what it answered, which files it touched. For the Tuesday-to-Wednesday case on the same laptop, in the same repo, this is usually all you need. Start here before you build anything.

Where `--resume` Stops Working

I leaned on --resume for months and kept hitting the same four walls.

A different machine. Sessions live in your local home directory. Your desktop doesn't know what your laptop did.
A different tool. Open the same repo in Cursor or Claude Desktop and there is nothing to resume. Each tool has its own history.
A compacted or full context. Long sessions get summarized to make room. The summary keeps the gist and drops the details, and the details are usually the decisions.
Weeks later. Resuming a three-week-old session drags in a lot of stale conversation to find the one decision that still matters.

In every case the thing you actually want back is not the transcript. It's the handful of decisions and facts the transcript contained.

The Manual Handoff, and Why It Rots

The workaround most of us reach for is a handoff note: a HANDOFF.md, a section in CLAUDE.md, or a paragraph you paste at the start of every session. It works, and I still recommend a short one for anything you'd tell a new teammate on day one.

It stops working the moment it stops being short. Decisions pile up, half of them go stale as the code moves, and the agent starts trusting a note that is no longer true. I wrote about that failure mode in Why Your CLAUDE.md Goes Stale. A hand-maintained file is a snapshot. A real project makes decisions faster than anyone updates a snapshot.

Persistent Memory: Saving the Decisions, Not the Transcript

The approach that finally stuck for me was to stop trying to preserve the conversation and start preserving what came out of it. During the session, the agent saves the things that matter: "retry logic goes in the client, not the handler," "we dropped the caching layer," "the vendor API rejects batches over 50." In the next session, in any tool, on any machine, it searches that memory before it starts and picks up from the decisions instead of from zero.

This is what I built ContextForge for. It runs as an MCP server, so the same memory is reachable from Claude Code, Claude Desktop, Cursor, Windsurf and ChatGPT. One line per tool:

claude mcp add contextforge -e CONTEXTFORGE_API_KEY=<your-key> -- npx -y contextforge-mcp

Two things worth being clear about, because the marketing version of this idea tends to skip them. First, nothing is injected magically. The agent has memory tools the same way it has a tool to read a file, and it saves and recalls because your CLAUDE.md tells it to. Second, memory belongs to the Project linked to your repo, so a decision saved from Claude Code on the desktop is there when Cursor opens the repo on the laptop. That is the whole point.

A Handoff That Actually Survives

Here is the loop I use now for the retry refactor, or anything longer than one sitting.

Before you close the terminal, ask the agent to save where things stand: what's done, what's next, and any decision you'd hate to re-derive. Thirty seconds.
Next session, same machine, run claude --continue. You get the transcript back, and the saved decisions are in memory as a safety net for anything compaction dropped.
Next session, different machine or tool, just start. The agent queries memory for the project, finds "retry refactor: client-side, handler untouched, next step is the timeout config," and continues from there.
When the code changes under a memory, ContextForge flags it as possibly stale. You or the agent confirm it, correct it, or forget it. Skip this and old decisions quietly steer new work.

If you split your day across several tools, How to Share Context Between Claude Code and Cursor walks through step three in more detail. For the three-command setup with a video, see Give Your AI Coding Agent a Memory That Survives Every Session.

Where It Falls Short

Setup is real. An API key and an MCP entry per tool. Ten minutes, once, but not zero.
Memory only holds what gets saved. If nobody saves the decision, it isn't there. The pre-close habit in step one is doing most of the work.
It doesn't replace reading the code. Memory says what you decided. The file says what the code does today. The agent needs both.
It's early. Small team, active development, rough edges. Core first, polish second.

A Practical Next Step

Tonight, before you close Claude Code, type one line: "save where we are on this task and what's next." Tomorrow, open the same repo in a different tool or on a different machine and ask it what you were doing. If it answers correctly, you have a session handoff that doesn't depend on a transcript. If you want the setup walkthrough first, start with MCP Memory Server: How to Give Claude & Cursor Persistent Memory.

Cursor Rules vs Persistent Memory

Alfredo Izquierdo — Thu, 17 Sep 2026 16:48:18 +0000

Last month I spent most of an afternoon in Cursor untangling a generic type constraint in a shared utilities package. I got it right, wrote a short note about why it had to be that way, and closed the laptop. Two days later I opened the same repo, asked Cursor to extend that utility, and it cheerfully proposed the exact constraint I had ruled out. My .cursor/rules file was right there. It just doesn't hold that kind of information.

That afternoon is the whole "cursor rules vs persistent memory" question in one scene. Rules and memory get lumped together because both are "context you give the agent," but they answer different questions, and mixing them up is why so many rules files end up as 400-line dumping grounds.

What Cursor Rules Actually Are

Cursor rules are plain instruction files you write by hand: a project-level .cursorrules file, or the newer .cursor/rules/*.mdc files that can be scoped to paths. Cursor reads them into the prompt so the agent behaves the way you want. Typical contents:

Which language and framework conventions to follow
How to name things, format code, structure tests
What to avoid ("never edit the generated client," "don't add dependencies without asking")
A short description of the project so the agent isn't guessing

Rules are static and deliberate. You write them once, they apply to every conversation, and they change only when you edit the file. That's their strength. It's also the reason they can't remember your Tuesday afternoon: a rules file describes how the project should be worked on, not what happened while working on it.

Why Rules Can't Remember Decisions

Everything Cursor knows in a session lives in the model's context window: the rules, the files you've opened, the chat so far. When the session ends, that context is gone. The rules survive because they're a file on disk that gets loaded again. The decision about the type constraint doesn't survive, because it was only ever in the conversation.

You can try to promote decisions into the rules file. Plenty of people do. It works for a few weeks, then two things happen. The file grows past what anyone will maintain, and half of it goes stale as the code moves on. I wrote about that failure mode for CLAUDE.md in Why Your CLAUDE.md Goes Stale, and Cursor rules rot the same way, for the same reason: a hand-maintained file can't keep up with the rate at which a real project makes decisions.

Think of rules as the house style guide of a newsroom. Every writer reads it. It says nothing about the story you were reporting yesterday.

What Persistent Memory Adds

Persistent memory stores decisions, preferences and project facts outside the context window, in a place the agent can search later. Instead of you copying "we dropped the caching layer" into a file, the agent saves it as a memory during the session and recalls it the next time the topic comes up, in Cursor or in whatever tool you switch to.

The kinds of things that belong in memory rather than in rules:

Design decisions and the reason behind them
Bugs you've already chased and how they were fixed
Constraints that surfaced mid-task ("the vendor API rejects batches over 50")
Things you said once in a chat and don't want to say again

Rules stay short and stable. Memory grows with the project. That division is the point: each one does the job it's good at.

How ContextForge Fits In

ContextForge is the memory layer I built after too many afternoons like the one above. It runs as an MCP server, so the same memory is reachable from Cursor, Claude Code, Claude Desktop, Windsurf and ChatGPT. You add it once per tool:

claude mcp add contextforge -e CONTEXTFORGE_API_KEY=<your-key> -- npx -y contextforge-mcp

In practice it looks like this. You finish the type-constraint work in Cursor and the agent saves the decision to the Project linked to your repo, with the reasoning attached. Two days later you ask Cursor to extend the utility. Before it proposes anything, it searches memory, finds the note, and doesn't repeat the mistake. If you open the same repo in Claude Code on Friday, it finds the same note, because the memory belongs to the project, not to the tool.

Inside a Project, memories are grouped into Spaces (folders by topic), Tasks track open issues, and the Git integration pulls commit messages and pull requests in as well. The piece that keeps it honest is freshness checks: when the code a memory describes has changed since it was saved, ContextForge flags it, and you or the agent can confirm it, correct it, or forget it. That is the difference between memory and a rules file that quietly lies to you six weeks later.

If you're setting up MCP memory for the first time, the walkthrough in MCP Memory Server: How to Give Claude & Cursor Persistent Memory covers the basics. And if you bounce between Cursor and Claude Code all day, How to Share Context Between Claude Code and Cursor goes deeper on that specific workflow.

Where It Falls Short

I'd rather you hear this from me than find out on day three.

There's a setup step. An API key and an MCP entry in each tool. One-time, but not zero.
Memory only holds what gets saved. ContextForge doesn't know what matters. If the agent never saves the decision, it isn't there. Your rules file is the right place to tell the agent when to save, which is the one job rules and memory share.
It doesn't replace reading the code. Memory says what you decided. The file says what the code does today. The agent still needs both.
It's early. Small team, active development, rough edges. We ship the core first and polish second.

Routines (scheduled cloud agents) and Skills (reusable prompt templates) sit on top of this, but they're a topic for another day. Get the basic loop working first.

A Practical Next Step

Open your rules file and read it with one question in mind: which lines are how to work and which are what we decided? Keep the first kind. Move the second kind into memory, or delete them if they're already stale. Then do one real task in Cursor with a memory server connected and check what got saved. If the next session already knows what you decided in the last one, you'll feel the difference immediately.

How ContextForge Saves Tokens in Claude Code and Cursor

Alfredo Izquierdo — Mon, 14 Sep 2026 18:31:13 +0000

Last month I opened the usage page of my Claude account and did the math I had been avoiding. Most of the tokens I pay for are not the code the model writes. They are the same things I feed it again and again: what the project is, how it is laid out, which decisions we already made, which tool does what. I was paying to re-introduce my own project to the model several times a day.

So let me be upfront: ContextForge saves tokens, but there is no trick in it. It replaces the big blob of context you paste every time with a small lookup when the model actually needs something. Below is where the tokens go, what changes with a memory server, and where it doesn't help you at all.

Where the tokens actually go in a coding session

Before talking about saving anything, look at what a normal Claude Code or Cursor session spends on. In my projects it is always the same four things, in different proportions.

The static preamble. Your CLAUDE.md or rules file, loaded on every single session whether today's task needs it or not. In our own repo the two CLAUDE.md files add up to about 14 KB, roughly 3,500 tokens, before you type a word.
Tool definitions. Every MCP server you connect sends its tool schemas to the model at the start of the session. This one is invisible in the UI and it adds up fast. More on it below, with real numbers.
Re-explanation. "We use Postgres for sessions, not Redis." "Errors return problem+json." "Don't touch the legacy auth module." You type these, or the model re-reads the files that contain them, once per session. Sometimes once per tool.
Rework. The expensive one. The model confidently does the thing you decided against three weeks ago, you notice, you explain, it redoes it. Every token in that loop was wasted.

Bigger context windows don't fix any of this. I wrote about why in Context Rot: Bigger Windows Won't Save You. A larger bucket just lets you waste more per session.

Pull the two facts you need, not the forty you don't

The CLAUDE.md approach loads everything, always. A memory server flips that. When the agent needs context, it calls memory_query with what it is working on, and gets back the handful of items that match.

Two design details in ContextForge matter here:

Results come back as previews. A query returns short summaries (about 150 characters each) with an ID. The agent only pulls the full text of an item, with memory_get, when it actually needs it. A query about "auth session storage" costs a few hundred tokens, not the whole knowledge base.
Spaces narrow the search. Memory is organized into spaces inside a project (auth, billing, infra). Searching the auth space for an auth question returns auth answers, with no billing noise to skim past and pay for.

So the trade is: a small retrieval when it is needed, instead of a large preamble whether it is needed or not. On a project with any history, that is the biggest single saving, and it grows as the project grows. I wrote about the stale-file side of this in Why Your CLAUDE.md Goes Stale; the token side is the same story from the other end.

69 tools, but the model only sees 11

This is the one I actually measured, because the number surprised me when I first saw it.

ContextForge exposes 69 tools over MCP: memory, tasks, git sync, snapshots, team, and so on. Until version 0.11.0 the client sent all 69 schemas to the model on every session. I spawned the server and measured the raw tools/list payload:

Mode	Tools visible	Payload size	Approx. tokens
Full (pre 0.11.0)	69	45 KB	7,000 to 11,000
Lean (default now)	11	11 KB	2,000 to 2,800

The exact token count depends on the tokenizer and on how your client formats the schemas, which is why I give a range. The proportion is stable: roughly 75% fewer tokens spent on tool definitions, on every session, before any work happens.

How it works: the lean set is the ten tools people actually call all day (query, ingest, correct, forget, tasks, sessions, help) plus one gateway tool called cf_tools. If the agent needs one of the other 59, it asks the gateway in plain language ("sync my git commits", "restore a snapshot") and the gateway finds and runs the right tool. Nothing was removed. The schemas just stopped riding along in every prompt.

There is a second effect that isn't about tokens. Cursor caps MCP tools at 40, and several clients get noticeably worse at picking the right tool past roughly 50. Eleven tools keeps ContextForge well under both lines. If you want the old behavior, set CONTEXTFORGE_TOOLS=full and you get all 69 back.

The tokens you don't spend twice

This one is harder to put a number on, so I'll describe it instead of measuring it.

When Claude Code saves a decision on Monday and Cursor reads it on Tuesday, the Tuesday session skips the whole "let me explain the architecture" opening. That is a few hundred to a couple of thousand tokens per session, depending on how much you usually paste. It doesn't sound like much until you count how many sessions you open in a week.

The bigger saving is the rework bucket. A model that knows "sessions live in Postgres, decided 2026-04-11, here is why" does not propose Redis, does not get corrected, and does not redo the work. One avoided wrong turn can cost more than a whole day of memory queries. I don't have a clean way to measure avoided mistakes, so I'm not going to give you a percentage. I can tell you it's the reason I built this, more than the schema math above. The setup for two tools sharing one memory is in How to Share Context Between Claude Code and Cursor.

Where ContextForge does not save tokens

I would rather you hear this from me than find out after signing up.

Every memory call costs tokens. A query and its results are a few hundred tokens. Saving a memory is a few hundred more. If the agent queries on every turn because your rules file tells it to, you can spend more than you save. Tell it to query at the start of a task and when it hits something unfamiliar, not constantly.
It does not shrink the code the model has to read. Memory tells the agent what you decided, not what the file says today. It still has to open the file. Retrieval replaces the explanation, not the reading.
Memory only pays off if it exists. An empty memory saves nothing. The first week is an investment: the agent saves decisions as you make them (because it has the tools and the instruction to use them), and the returns start when the second session, or the second tool, reads them.
Stale memory costs tokens too. A six-week-old decision that no longer matches the code sends the agent down the wrong path just as surely as no memory at all. ContextForge runs freshness checks that flag items when the code they describe has changed, and you confirm, correct or forget them. Skip that and the savings turn into rework.

A rough picture of one week

Take a developer who runs three or four sessions a day across Claude Code and Cursor, on a project with a 14 KB rules file and a couple of MCP servers connected. Their fixed cost per session, before any work, is somewhere around 3,500 tokens of preamble plus 7,000 to 11,000 tokens of ContextForge tool schemas in the old full mode. Call it 12,000 tokens a session that produce no code.

Move the project facts into memory, keep the rules file to the short "how to behave" part, and run the lean tool set. The same session starts at roughly 2,500 tokens (a trimmed rules file plus the lean schemas), and adds a few hundred per query when the agent actually needs something. Most sessions land under 5,000 tokens of overhead. Over twenty sessions a week that is well over 100,000 tokens not spent on introductions, and that is before counting a single avoided wrong turn.

Your numbers will be different from mine. I would be surprised if the picture were.

Where to start

If you want to see the effect on your own project rather than trust my table: connect ContextForge to one tool, run memory_query on a real question, and look at the size of the response next to the size of the rules file you would have pasted instead. Then check what your client reports for tool definitions with CONTEXTFORGE_TOOLS=full versus the default. Those two comparisons take about ten minutes, and honestly they make the case better than this post does. The install is one line:

claude mcp add contextforge -e CONTEXTFORGE_API_KEY=<your-key> -- npx -y contextforge-mcp

The free tier covers one project and 500 queries a month, which is enough to find out whether the math works for you.

How to Share Context Between Claude Code and Cursor

Alfredo Izquierdo — Wed, 09 Sep 2026 14:41:32 +0000

You're an hour deep into a debugging session with Claude Code. Good progress. Then you open Cursor to refactor the same function, and it has no idea what you were just doing. So you re-explain. Switch back, re-explain again. This is the question behind "how to share context between Claude Code and Cursor," and the short answer is: neither tool will do it for you, but there is a clean way to make them share one memory.

The Core Problem: Context Dies With the Session

This isn't a bug in either tool. Claude Code works inside its context window (200,000 tokens on most tiers, more on some), and when the session ends, that context is gone. Cursor lives in its own world and knows nothing about what happened elsewhere. Two silos.

Imagine writing a novel with a co-author who forgets everything you wrote the moment you switch computers. That's your coding workflow right now.

The Usual Workarounds (and Why They Don't Hold Up)

Most of us tried these first. They work for about a week.

Copy-pasting. Manually moving snippets and notes between tools. Tedious, error-prone, and it collapses on anything bigger than a toy project.
CLAUDE.md files. Writing context into a Markdown file both tools can read. This is fine for a small project, but the file is only as good as the last time you remembered to update it. I wrote about exactly why in Why Your CLAUDE.md Goes Stale.
Shared docs. Notion, Google Docs, a notes app. Still manual, and the content never reaches the tool where you're actually coding.

All three patch the symptom. The root cause is that Claude Code and Cursor have no memory layer they both can read and write.

What MCP Changes

The Model Context Protocol (MCP) is a standard that lets an AI tool talk to an external memory server: save a decision, recall a preference, look up a project fact. Because it's a standard, the same memory server can serve Claude Code, Cursor, Claude Desktop, Windsurf and ChatGPT at once. That is the whole trick: you don't share context between the tools, you give them one shared place to keep it.

If you haven't set up an MCP memory server yet, start with MCP Memory Server: How to Give Claude & Cursor Persistent Memory (2026). It covers the basic setup.

A Concrete Example with ContextForge

ContextForge is the memory layer I built for exactly this. It runs as an MCP server, and you add it to each tool once:

claude mcp add contextforge -e CONTEXTFORGE_API_KEY=<your-key> -- npx -y contextforge-mcp

Here's what a normal week looks like with both tools pointed at it:

Claude Code, Monday. You're debugging a Python function. As you decide things ("the retry logic goes in the client, not the handler," "we're dropping the caching layer"), Claude Code saves those decisions to ContextForge. Not magically: it saves them because it has the memory tools and the instructions to use them, the same way it has a tool to read a file. They land in the Project linked to your repo.
Cursor, Tuesday. You open the same repo in Cursor to refactor that function. Cursor is connected to the same ContextForge project, so before it touches anything it can pull up Monday's decisions. It doesn't propose the caching layer you already killed.
Claude Code, Friday. You come back after three days on something else. It recalls the whole thread instead of asking you to summarize it.

It isn't only decisions. Preferences, conventions, the commands you always run, the one weird constraint in your deploy: anything the agent saves is there for the other tool. You can browse all of it in the dashboard at contextforge.dev.

Spaces, Projects, and Keeping Memory Honest

Inside a Project, memories are organized into Spaces, which are just folders by topic (auth, billing, infra). Tasks track the issues you're working on, and the Git integration pulls commit messages and pull request descriptions in as well, so "why did we do this" usually has an answer.

The part people skip is governance. Code moves fast and memories go stale. ContextForge runs freshness checks that flag a memory when the code it describes has changed since it was saved. You, or the agent, can then confirm it, correct it, or forget it. Skip this and a six-week-old decision will quietly steer today's work, which is worse than having no memory at all.

Limitations, Honestly

There's a setup. One-time, but real: an API key and an MCP entry in each tool. It's not plug-and-play yet, and we're still smoothing it.
Memory is only what gets saved. ContextForge doesn't know what matters. If the agent doesn't save a decision, it isn't there. Your CLAUDE.md or rules file should tell the agent when to save, and you'll still nudge it sometimes.
It complements reading the code. Memory tells the agent what you decided, not what the code does today. It still has to read the file.
It's early. Small team, active development, occasional rough edges. We ship core functionality first and polish second.

Where to Start

If you use both tools daily, the order that worked for me: get one MCP memory server running, connect Claude Code to it first, then Cursor. Do one real task in each and check what got saved. From there the habit builds itself, because the first time Cursor already knows what you decided in Claude Code, you won't want to go back.

Does Claude Remember Between Individual Chats in the Same Thread?

Alfredo Izquierdo — Thu, 03 Sep 2026 14:37:54 +0000

If you build with Claude, you've almost certainly asked it: does Claude remember between individual chats in the same thread? It's one of the most common questions developers have about Claude's memory, and the honest answer is more nuanced than a simple yes or no.

The short version: it depends on what you mean by "remember." Within a single conversation, Claude remembers your context really well. Start a brand-new chat, and that memory resets to zero. Understanding the gap between those two behaviors — how Claude remembers within a thread versus across separate chats — is the difference between an AI feature that works in a demo and one that holds up in production. Let's break down exactly how Claude's memory works, why it works that way, and what you can do about it.

How Claude's Memory Works: The Context Window

Claude, like every large language model, doesn't have persistent memory the way a person does. Claude's memory lives entirely inside the context window — the amount of text the model can "see" at once when it generates a response. Everything Claude knows in a given moment sits in that window: your current message, the earlier messages in the thread, any system instructions, and any files or data you've pasted in.

Claude's context window is large — currently up to 200,000 tokens, with versions supporting even bigger windows. A token is roughly three-quarters of a word, so that's a lot of room (hundreds of pages). But it isn't infinite, and — this is the key part — the context window doesn't carry over between separate chats. Open a new conversation and you get a fresh, empty window. Nothing from yesterday's chat is waiting there.

Does Claude Remember Previous Conversations?

This is where "does Claude remember between individual chats" splits into two very different answers:

Within a chat thread — yes, Claude remembers. The model keeps a running history of the conversation. Mention a constraint early on and refer back to it twenty messages later, and Claude can generally recall it. This is the smooth, "it just works" case, as long as the conversation fits inside the context window.
Across individual chats — no, Claude does not remember on its own. Creating a new chat starts a completely fresh context window. Claude does not automatically carry information from one separate chat into another. Think of it like starting a new email thread: none of the previous thread's content is present unless you bring it in. So if you're wondering whether Claude remembers previous conversations from last week, the answer is no — not without help.

Why Claude's Memory Trips People Up

The reason this is so easy to get wrong is that within a thread, Claude feels like it has real, persistent memory. It remembers your name, the bug you're chasing, the coding style you asked for. So it's natural to assume that memory follows you into the next session. It doesn't.

There's also a subtler failure mode inside a single thread: the context window filling up. On very long conversations, the earliest messages eventually fall out of the window to make room for new ones. When that happens, Claude appears to "forget" something from the start of the chat — not out of carelessness, but because that text is no longer in front of it. Knowing where that edge is lets you design around it instead of getting surprised.

Practical Examples: When Claude Remembers and When It Doesn't

Say you're building a customer-support chatbot.

Scenario 1 (good): A customer asks, "What's my order number?" Claude provides it. Later in the same chat they ask, "Can you track that order?" Claude handles it easily, because the order number is still inside the context window.
Scenario 2 (problematic): The customer ends the chat. The next day, in a new chat, they ask, "Can you track my order?" With no context provided, Claude has no idea which order they mean. Your app has to re-supply that history or the experience falls apart.

That second scenario quietly breaks a lot of AI features. The demo works because everything happens in one session. Real usage happens across many sessions — which is exactly why Claude's memory across chats becomes an architecture decision, not just trivia.

AI Agent Memory Across Tools and the Model Context Protocol (MCP)

The same limitation shows up hard once you move from chatbots to agents. AI agent memory across tools is the whole ballgame: an agent needs to remember its goals, its progress, and past decisions as it moves between a code editor, a browser, and a terminal. Without persistent memory, every hop is a fresh start.

This is exactly the gap the Model Context Protocol (MCP) is meant to close. MCP is a standardized way to feed context to LLMs from external sources — memory stores, databases, tools — instead of relying on whatever happens to be in the current chat window. The goal is one continuous "conversation" that survives across sessions and across applications, because the relevant context is retrieved and supplied on demand. It's an active, fast-moving space.

How to Give Claude Persistent Memory Today

You don't have to wait for the ecosystem to mature to get better continuity right now:

Re-supply context yourself. Store the important facts (user profile, past decisions, project state) in your own database and inject the relevant slice into each new prompt. This is the most reliable approach for production.
Summarize instead of dumping. Don't paste an entire previous conversation into a new one — you'll burn the context window fast. Distill it to the handful of facts that matter, then include that.
Use a persistent memory layer. Rather than hand-rolling all of this, a memory layer can store and retrieve context for you, so each new session starts with the relevant history already in place.

Where ContextForge Fits In

At ContextForge, we're focused on making Claude's memory problem manageable. The goal isn't to replace Claude or any other LLM — it's to give developers a persistent memory layer their apps can write to and read from across sessions, MCP-based access so context can flow between tools, and clear visibility into what's actually in the context window.

The Short Answer

So, does Claude remember between individual chats in the same thread? Within a thread, yes — across separate chats, not on its own. Claude faithfully uses whatever is in the current context window and nothing more. Once that clicks, the fix is obvious: stop hoping the model will remember, and start deciding what context to bring into each session. That single shift is the difference between a chatbot that forgets everyone the moment they leave and an AI assistant that actually feels like it knows them.

What's your experience with Claude's memory across sessions? If you want to go deeper on persistent memory, AI agent memory, and MCP, take a look around the site.

How to Give Claude & Cursor Persistent Memory 2026

Alfredo Izquierdo — Wed, 26 Aug 2026 15:42:48 +0000

Install the free official MCP memory server, then upgrade to project-aware ContextForge. 2026 guide.

Here's a small tragedy that plays out in my terminal every single morning: I open
Claude Code, and it has no idea who I am, what I'm building, or what we decided
yesterday. Same with Cursor. Brilliant assistants, zero memory. It's like working
with a genius who has amnesia.

The fix is an MCP memory server — a little service that plugs into Claude or
Cursor over the Model Context Protocol and gives your assistant memory that
survives when the session ends. In this guide I'll show you exactly how to set one
up, starting with the free official server and then the project-aware option I
ended up building because the official one wasn't enough for real work.

New to this whole space? I ranked
the 8 best AI memory tools for Claude
and did a deep ContextForge vs Mem0 vs Zep
comparison in separate posts. This one is the hands-on how to actually install
one guide.

What is an MCP memory server?

MCP — the Model Context Protocol — is the open standard that lets tools like
Claude Code and Cursor talk to external services. An MCP memory server is just
one of those services, with one job: store what your assistant learns (facts,
decisions, project context) and hand the right pieces back at the start of the
next conversation.

Without one, everything your assistant knows lives inside a single session's
context window — and vanishes the moment that session closes. With one, memory
lives outside the model, so tomorrow's you doesn't start from zero.

Two ways to get there, from simplest to most capable. Let's do both.

Option 1: The official MCP memory server (free, 2 minutes)

The Model Context Protocol team ships a reference memory server. It's a
knowledge-graph memory that stores entities, relations, and observations in a
local JSON file. It's the fastest way to feel what MCP memory does, and it costs
nothing.

Install it in Claude Code / Claude Desktop. Open your MCP config
(claude_desktop_config.json, or .mcp.json in your project) and add:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

Install it in Cursor. Same idea — add the block to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

Restart the app, and your assistant can now save and recall entities across
sessions. That's genuinely useful — and for a lot of people it's enough.

Where it stops being enough. I ran the official server for weeks, and three
things wore me down:

It's one flat graph in a local file — no notion of which project a memory belongs to. My side project's facts and my client work bled into the same blob.
No sync. The memory lives on one machine; switch laptops or tools and it doesn't follow you.
You have to babysit recall. Nothing loads automatically at session start — you're nudging it to remember, every time.

For quick experiments, perfect. For the actual work I do every day, I wanted
something that understood projects. So I built it.

Option 2: ContextForge — a project-aware MCP memory server

ContextForge is an MCP memory server too — same standard, plugs into Claude
and Cursor the same way — but instead of one flat graph, it organizes memory
around your projects: spaces, items, tasks, and decisions that load
automatically the second a new session starts. No vector database to run, no local
file to babysit.

Connect it the same way you connected the official one — add it to your MCP
config, drop in your ContextForge API key, and restart. From that point on, when
you open Claude Code or Cursor, your assistant already knows what project you're
in and what you were doing. You can even import the ChatGPT and Claude history you
already have, so you're not starting your memory from scratch.

Here's the honest side-by-side:

	Official memory server	ContextForge
Cost	Free	Free tier, then paid
Setup	`npx`, 2 min	Connect MCP + API key
Storage	Local JSON file	Managed, no infra
Structure	One flat knowledge graph	Projects, spaces, tasks, decisions
Loads at session start	Manual	Automatic
Syncs across machines/tools	No	Yes
Import existing history	No	Yes (ChatGPT / Claude)
Best for	Quick experiments, local use	Real project work across sessions

Neither is "the winner" in the abstract. If you want a free, local, kick-the-tires
memory, the official server is a great first stop. If you live in Claude Code or
Cursor and want memory that actually understands your projects and follows you
around, that's the gap ContextForge was built to fill.

Which should you pick?

Just curious how MCP memory feels? → the official @modelcontextprotocol/server-memory. Free, two minutes, done.
Working on real projects across sessions, machines, or tools? → ContextForge.
Not sure which memory tool at all yet? → start with my top-8 ranking.

FAQ

What is an MCP memory server?
It's a service that connects to Claude, Cursor, or any MCP client over the Model
Context Protocol and stores your assistant's memory outside the session, so facts,
decisions, and project context persist across conversations instead of resetting
each time.

How do I install the official MCP memory server?
Add @modelcontextprotocol/server-memory to your MCP config
(claude_desktop_config.json, .mcp.json, or ~/.cursor/mcp.json) with the
command npx -y @modelcontextprotocol/server-memory, then restart the app.

Does this work with both Claude Code and Cursor?
Yes. Both speak MCP, so the same memory server plugs into either one — you just add
the server to each tool's MCP config file.

What's the difference between the official server and ContextForge?
The official server stores one flat knowledge graph in a local file. ContextForge
organizes memory by project (spaces, tasks, decisions), loads it automatically at
session start, needs no local infrastructure, and syncs across your tools and
machines.

Do I need a vector database?
No. Neither the official server nor ContextForge asks you to run a vector database
— that's part of the appeal of an MCP memory server over building recall yourself.

Tired of re-introducing your project to Claude and Cursor every morning? I built
ContextForge to be the MCP memory server I wanted —
project-aware, zero infrastructure, connected in minutes.

ContextForge vs Mem0 vs Zep: Best AI Memory Layer (2026)

Alfredo Izquierdo — Tue, 25 Aug 2026 14:18:05 +0000

I'll be honest with you: I build one of the three tools in this post, so you'd
be right to raise an eyebrow. But I've spent the last year staring at this exact
decision — which memory layer do I actually trust with my agents? — and I got
tired of comparisons that were really just sales pages in disguise.

So here's the version I wish someone had written me. Three tools, head to head,
including the parts where mine loses. If you use Claude and MCP, ContextForge
is in the mix. If you don't, Mem0 or Zep is probably your answer — and
I'll tell you exactly when.

Already narrowed it down to these three? Good — that's what this post is for. If
you're still scanning the whole field, I ranked
the 8 best AI memory tools for Claude
in a separate guide. Come back here once you've got your finalists.

TL;DR: Pick ContextForge if you live in Claude / Claude Code and want
project-aware memory that plugs in over MCP with zero infrastructure. Pick
Mem0 if you want a general, framework-agnostic memory API with the biggest
community behind it. Pick Zep if you need temporal, entity-aware memory
with the best published accuracy benchmarks.

The 30-second verdict

If you only have a minute, this table is the whole post:

	ContextForge	Mem0	Zep
Best for	Claude + MCP workflows	General memory API	Temporal / entity memory
Architecture	Project/space memory over MCP	Vector-first, layered scopes	Temporal knowledge graph (Graphiti)
Setup	Connect as MCP server, no infra	SDK or managed cloud	Managed or self-host graph
Standout	Loads project context at session start	~48K GitHub stars, wide adoption	63.8% LongMemEval (accuracy leader)
Free tier	Yes	~10k memory adds/mo	~1k credits/mo
Open source	—	Yes	Engine (Graphiti, Apache 2.0)

The rest of this post is about the why — because the three don't just differ on
features, they disagree on what "memory" even means.

The real difference: three philosophies, not three feature lists

Here's the thing that took me embarrassingly long to see. These tools aren't
competing on who has more features — they start from three different beliefs
about what your agent should remember:

Mem0 believes memory is a pile of facts you retrieve by similarity.
Zep believes memory is a web of entities and events that change over time.
ContextForge believes memory is your project — the tasks, decisions, and context of the work in front of you.

Once you see it that way, the "which is best" question dissolves into a much
better one: which shape matches how you actually work? Let's take them one at a
time.

Mem0: memory as a pile of facts

Mem0 is the one you've probably already heard of — with roughly 48K GitHub stars,
it's the popular kid. Its whole bet is generality: drop it onto almost any stack,
and it quietly files away facts and pulls back the ones that look relevant when
you ask. It even reaches into Claude Desktop and Cursor through an MCP server, so
your facts can follow you between tools.

The trade-off is baked into that same bet. Retrieving by similarity is fast and
flexible, but it's a little forgetful about relationships — how two facts
connect, or which one is still true today. Ask it "what did we decide about auth,
and did that change?" and it'll hand you every auth-flavored memory it has, newest
and stalest alike, and let you sort it out. For a lot of apps that's plenty. For a
messy, evolving project, you feel the gap.

Reach for Mem0 when: you're building on any framework and want one simple,
well-supported memory API that just works everywhere.

Zep: memory as a timeline of entities

If Mem0 is the popular kid, Zep is the honor student. It doesn't store loose facts
— it builds a graph where the people, projects, and things in your data are
connected, and every connection is stamped with when it was true. That's why it
can answer the question Mem0 fumbles: what was true last Tuesday, and what
changed since?

And it's not just theory — Zep posts the best public accuracy numbers in this
space, 63.8% on LongMemEval against Mem0's 49.0%. When I say it earns my respect,
that benchmark is a big part of why.

The catch is the same thing that makes it powerful: a graph is something you
design and maintain, not something you drop in and forget. If your goal is
"help my assistant remember this project," Zep can feel like hiring a librarian to
organize a single shelf — genuinely excellent, just more machine than the moment
calls for.

Reach for Zep when: you're building conversational agents that track real
entities over time and accuracy is the hill you'll die on.

ContextForge: memory as your project

This is mine, so read it with your skepticism turned up. I didn't build
ContextForge to win a benchmark — I built it because I was tired of re-explaining
my own codebase to Claude every single morning. So instead of storing facts or
entities, it stores the thing I actually care about: the project. You connect
it as an MCP server, and your assistant gets spaces, items, tasks, and decisions
that survive across sessions and load automatically the second a new conversation
opens. No cold start.

What makes it click for Claude users: there's no vector database for you to run,
memory is organized by project and space instead of one giant blob, and it'll
pull in the ChatGPT and Claude history you already have.

And now the honest part. ContextForge is built around Claude and MCP. That's its
superpower and its ceiling. If you're not in that ecosystem, it's the wrong tool —
Mem0 is more general and I won't pretend otherwise. Zep will out-benchmark me on
raw recall accuracy. I'm not the best at everything; I'm the best at one specific
job.

Reach for ContextForge when: you live in Claude / Claude Code and you want
memory that understands your projects without you standing up any infrastructure.

Head-to-head by what actually matters

Enough philosophy — here's how they feel day to day:

Setup cost: ContextForge (connect MCP, no infra) < Mem0 (SDK/cloud) < Zep (graph, managed or self-host). If you hate infrastructure, that order is your whole decision.
Retrieval quality: Zep leads on benchmarks; Mem0 is solid on similarity; ContextForge keeps context scoped to your project instead of going global on you.
Claude / Claude Code fit: ContextForge is MCP-native and loads at session start; Mem0 offers an MCP server too; Zep integrates but isn't Claude-first.
Openness & price: Mem0 and Zep's engine are open source and self-hostable — Mem0's free tier runs ~10k adds/month, Zep's ~1k credits/month. ContextForge is a managed service with a free tier and nothing to self-host. If self-hosting is a hard requirement, that line just picked your tool.
Structure: ContextForge models projects, spaces, and tasks; Mem0 and Zep model facts and entities. If your memory is your project, structure wins.

A concrete way to choose

Still torn? Answer one question — what does your agent forget that hurts the
most?

It forgets my project, my decisions, my stack → ContextForge.
It forgets facts across a big general app → Mem0.
It forgets who's who and what changed when → Zep.

And here's the plot twist nobody tells you: these aren't mutually exclusive.
Plenty of teams run Zep or Mem0 for general app-level memory and ContextForge for
their Claude/MCP dev workflow. They're solving different halves of the problem, so
using two isn't hedging — it's just matching the tool to the job.

FAQ

Is Mem0 or Zep better?
Depends on what you're optimizing for. Mem0 leads on adoption and simplicity with
a vector-first layer; Zep leads on accuracy (63.8% vs 49.0% on LongMemEval) with
a temporal knowledge graph. Choose Mem0 for a general memory API, Zep for time-
and entity-aware recall.

What's the best memory tool for Claude specifically?
For Claude and Claude Code, ContextForge is purpose-built: it connects over MCP
and gives project-aware memory that loads automatically at session start —
without you running your own vector database.

Can I use more than one of these together?
Yes, and many teams do — for example Zep or Mem0 for broad app memory plus
ContextForge for the Claude/MCP developer workflow. They target different layers,
so combining them is common rather than redundant.

Are these open source?
Mem0 is open source; Zep's engine Graphiti is Apache 2.0 and self-hostable.
ContextForge is a managed service with a free tier.

Using Claude and tired of re-explaining your project every single session? I
built ContextForge precisely because I was — it's
persistent, project-aware memory over MCP, and you can be set up in minutes.

Best AI Memory Tools for Claude in 2026 (Top 8 Ranked)

Alfredo Izquierdo — Mon, 24 Aug 2026 16:39:43 +0000

If your AI assistant forgets your project every time you open a new session,
you don't have a model problem — you have a memory problem. In 2026, memory
stopped being a nice-to-have and became core AI infrastructure. This guide ranks
the 8 best AI memory tools you can use with Claude, Claude Code, and other agents,
with honest picks for each use case.

TL;DR: For Claude and MCP-native workflows, ContextForge is the fastest
way to give your assistant persistent, project-aware memory. For a general
vector memory layer, Mem0 leads on adoption. For temporal, entity-aware
memory, Zep leads on accuracy. For fully self-hosted graph memory, pick
Cognee or Letta.

What "AI memory" actually means

An AI memory tool stores facts, preferences, decisions, and project context
outside the model's context window, then retrieves the right pieces on demand —
so your agent remembers across sessions, tools, and days instead of starting cold
every time. The approaches differ: some are vector-first, some build knowledge
graphs, some manage the context window like an operating system manages RAM.

How we ranked these

Persistence across sessions — does it actually survive a new conversation?
Retrieval quality — does it pull the relevant memory, not everything?
Setup cost — managed vs. self-hosted infrastructure.
Claude / MCP fit — how cleanly it plugs into Claude Code and MCP clients.
Pricing & openness — free tier, open source, self-hostable.

1. ContextForge — Best for Claude + MCP persistent memory

ContextForge is a persistent memory system built for Claude and MCP clients.
Instead of running a vector database yourself, you connect it as an MCP server and
your assistant gains project-scoped, git-aware memory: spaces and items,
tasks, and project context that persist across every session and sync across tools
(Claude Code, Cursor, and imported ChatGPT history).

Best for: Claude / Claude Code users who want project-aware memory without standing up infrastructure.
Why it wins its niche: MCP-native, so memory loads at session start automatically; organized by project and space, not one flat blob; captures tasks and decisions, not just chat facts.
Trade-off: purpose-built around the Claude/MCP workflow rather than a general-purpose SDK for any stack.

2. Mem0 — Best overall adoption / general memory layer

Mem0 is a vector-first memory layer you bolt onto almost any agent stack. It
organizes memory by scope (conversation, session, user, organization) and promotes
facts between layers over time. With ~48K GitHub stars it's the most widely adopted
option, and its OpenMemory MCP server carries memory across clients.

Best for: teams wanting a general, framework-agnostic memory API.
Pricing: open source + managed cloud; free tier ~10,000 memory adds/month.
Trade-off: vector-first recall can miss how facts relate or change over time.

3. Zep — Best for temporal, entity-aware memory

Zep builds a temporal knowledge graph (via Graphiti, Apache 2.0) where
entities are nodes and facts are edges with validity intervals — so it tracks how
facts change over time. It leads published accuracy benchmarks (63.8% on
LongMemEval vs. Mem0's 49.0%).

Best for: conversational agents that need entity memory and "what was true when" reasoning.
Pricing: open-source engine; managed free tier ~1,000 credits/month.
Trade-off: graph model is more to reason about than a simple vector store.

4. Cognee — Best self-hosted graph memory (open source)

Cognee is the open-source memory platform that natively combines graph,
vector, and relational storage into one self-improving "memory control plane."

Best for: teams that want full data ownership and a graph+vector hybrid.
Pricing: open source, self-hostable.
Trade-off: you run and maintain the infrastructure.

5. Letta (formerly MemGPT) — Best for agent-managed context

Letta treats the context window as a constrained resource — like RAM in an OS —
letting the agent move data between in-context "core" memory and external
recall/archival memory. It's the MemGPT tradition, and its OSS self-host is the
most complete open-source offering.

Best for: long-running autonomous agents that self-manage memory.
Pricing: open source; managed tiers roughly $19–$125/mo for early production.
Trade-off: more framework than drop-in layer.

6. Supermemory — Best lightweight managed option

Supermemory is a managed memory API focused on simplicity and fast setup for
adding recall to assistants and apps without infrastructure overhead.

Best for: shipping memory quickly in a small product.
Trade-off: less control than a self-hosted graph.

7. Basic Memory (Official Memory MCP) — Best minimal MCP server

Basic Memory is a lightweight MCP memory server: create entities, add
observations, search by keyword or semantics, persist across sessions. Runs via
npx, Docker, or local install with minimal dependencies.

Best for: developers who want a tiny, official MCP memory primitive.
Trade-off: minimal by design — no project/task structure or team features.

8. Pinecone — Best managed vector store to build on

Pinecone isn't a memory framework — it's the managed vector database many
memory layers are built on. Choose it when you're building custom memory retrieval
and want a scalable, managed index underneath.

Best for: teams rolling their own memory pipeline.
Trade-off: you build the memory logic; it only stores/retrieves vectors.

Quick comparison

Tool	Best for	Approach	Open source	Free tier
ContextForge	Claude + MCP persistent memory	Project/space + MCP	—	Yes
Mem0	General adoption	Vector-first, layered	Yes	~10k adds/mo
Zep	Temporal / entity memory	Temporal knowledge graph	Yes (Graphiti)	~1k credits/mo
Cognee	Self-hosted graph memory	Graph + vector + relational	Yes	Self-host
Letta	Agent-managed context	Context-as-RAM (MemGPT)	Yes	OSS / $19+
Supermemory	Lightweight managed	Managed API	Partial	Yes
Basic Memory	Minimal MCP server	Entity/observation store	Yes	Self-host
Pinecone	Build-your-own	Managed vector DB	No	Yes

How to choose

You use Claude / Claude Code and want it to remember your projects → ContextForge (MCP-native, project-aware, zero infra).
You want one memory API across any framework → Mem0.
You need entity memory and time-aware facts → Zep.
You want to self-host a graph+vector brain → Cognee or Letta.
You're building custom retrieval → Pinecone underneath.

FAQ

What is the best AI memory tool for Claude in 2026?
For Claude and Claude Code specifically, ContextForge is the fastest path to
persistent, project-aware memory because it connects as an MCP server and loads
context automatically at session start. For a general-purpose memory layer across
any stack, Mem0 leads on adoption and Zep on benchmark accuracy.

Does Claude have built-in memory?
Claude Code has CLAUDE.md files and auto-memory for lightweight persistence. For
richer, searchable, project-scoped memory that syncs across tools, teams add a
dedicated memory tool like ContextForge or an MCP memory server.

What's the difference between vector memory and knowledge-graph memory?
Vector memory (Mem0, Pinecone) retrieves by semantic similarity. Knowledge-graph
memory (Zep, Cognee) stores entities and relationships, so it can reason about how
facts connect and change over time — at the cost of more complexity.

Are these AI memory tools free?
Most ship meaningful free tiers or are fully open source and self-hostable —
Mem0 (~10k adds/mo), Zep (~1k credits/mo), Letta and Cognee (OSS). ContextForge
offers a free tier to start.

Want persistent memory for Claude in about five minutes? Try ContextForge —
connect it as an MCP server and your assistant remembers your projects across
every session.

One Developer, Five Terminals, Zero Awareness

Alfredo Izquierdo — Wed, 08 Jul 2026 13:43:46 +0000

One Developer, Five Terminals, Zero Awareness

It's 11 p.m. and I have four terminals open.

One is running a Claude Code session on the auth refactor. Another is in a git worktree, rebuilding the tests. A third is reviewing a pull request. A fourth is just… there, waiting, because I know I'll need it in ten minutes. Somewhere in the mix there's a small team of sub-agents fanning out on a migration.

I'm not doing this because I enjoy the chaos. I'm doing it because this is what "productive" looks like now.

If you ship software with AI agents, you already know the feeling. One agent working one task, start to finish, is too slow. So you split the work. You open a second window. Then a third. You spin up a worktree so two branches can move at once. You hand a batch of independent tasks to a fleet of sub-agents and let them run. Parallelism is the only lever left when a single session can't keep up with the size of what you're trying to do.

And it works — right up until it doesn't.

The parallel blind spot

Here's the thing nobody tells you when you start running sessions in parallel: every one of those sessions is an island.

Session A is deep in the auth module. It's been there for twenty minutes, halfway through a refactor, files open, changes uncommitted. Three minutes later, Session B — a completely separate process, in a completely separate terminal — also reaches for the auth module. Not because it's reckless. Because it has no idea Session A exists.

Now you have two agents editing the same code with no knowledge of each other. One overwrites the other's assumptions. A merge conflict blooms out of nowhere. Or worse — no conflict, just two half-finished ideas quietly braided into the same file, and you don't notice until the tests go red for reasons that make no sense.

You lose exactly the time parallelism was supposed to save. That's the trap. The faster you go by splitting work, the more surface area you create for the splits to collide — because none of them can see the others.

I started calling this the parallel blind spot. You added more hands to move faster, and the hands can't see each other.

Memory solves "what happened." This is "what's happening."

If you've used ContextForge, you know it already gives your agents a memory that survives every session — the decisions, the corrections, the constraints, carried from one session to the next so your agent stops forgetting Friday by Monday.

But durable memory answers a question about the past: what happened before. The parallel blind spot is a different question entirely — a question about right now:

Who else is working on this, at this moment, while I am?

Memory is history. This is presence. A session's history tells you what it did yesterday; it tells you nothing about the session running in the terminal next to it this second. No amount of "remember what happened" fixes "I can't see what's happening."

That's the gap. And for a while, it was a gap I only half-noticed — because when it's just you and one terminal, it doesn't exist. It only shows up once you're deep enough into parallel work to get bitten by it.

The comment that named it

Then a reader left a comment on one of my posts that named it exactly.

They pointed out that ContextForge covered the single-session story beautifully — memory that persists — but that the multi-session case was wide open. When you run two or more agents against the same project, there's no live shared-state layer. Nothing that lets Session A raise a hand and say "I've got the auth module right now" so Session B doesn't walk into it.

Reading it, I felt that particular sting of good feedback: the obvious thing you somehow hadn't let yourself see. They were right. Memory across sessions was solved. Awareness between sessions wasn't. It had a name now, and once something has a name, you have to go build it.

So I did.

Session Presence: a live "who's here" for your agents

The new feature is called Session Presence, and the whole idea fits in one sentence: your parallel sessions can now see each other in real time.

Here's how it actually works, because the best part is how little you have to do:

It registers itself. Every Claude Code session (or Cursor, or any MCP client) automatically announces itself as live the first time it does anything. You don't run a command. You don't think about it. The moment a session starts working, it's on the board.
It stays honest. Each session sends a quiet heartbeat every couple of minutes. So the list is always live sessions — not a graveyard of things you closed hours ago. A session that dies without saying goodbye simply ages off on its own.
It disappears cleanly. When you close a session, it's removed at once — even in the split second before the process is fully killed. No stale ghosts lingering on the list.

On top of that, three small tools give the agent a voice:

session_update — "I'm working on the auth module." One session declares what it's focused on.
session_list — "Who else is on this project right now, and what are they doing?"
session_end — "I'm done here."

And you don't have to memorize any of that. You just talk. Ask your agent, in plain English, "is anyone else working on this project right now?" — and it checks the board and tells you: yes, another session has been on the auth module for the last few minutes; you might want to steer clear.

One more thing that matters: it's advisory, not a lock. Presence is a "busy" sign on a door, not a key that bolts it shut. It doesn't stop you from doing anything — it just makes sure you're never doing it blind. You stay in control; you just get to make the call with the full picture instead of half of it. And it's scoped to the project you're actually in, so a busy afternoon across five different repos doesn't turn into noise — you see the sessions that can actually collide with yours, and nothing else.

What it feels like in practice

Back to that 11 p.m. scene. Two sessions, both drifting toward the auth module.

With presence, the second one asks the board before it dives in. It sees that Session A is already there, focused on exactly that. So instead of colliding, it picks up the tests — the other thing on the list that nobody's touching. No conflict. No braided half-ideas. No 30 minutes lost untangling a mess that never needed to happen.

That's the whole win. It's not flashy. It's the quiet difference between five sessions working near each other and five sessions working blind next to each other.

Try it this week

If you're already running parallel sessions — worktrees, agent teams, three terminals before lunch — this is for you.

Update to the latest ContextForge MCP. Session Presence ships in the current release and works with Claude Code, Cursor, and Copilot through MCP — so even if you bounce between all three tools in a day, your sessions still see each other.
Ask "who else is here?" at the start of a session. Make it the first thing you do when you sit down, the same way you'd glance around an office before taking a desk.
Say what you're working on when you switch tasks. One sentence — "I'm on the payments flow now" — and every other session can see it.
Already have a CLAUDE.md? Re-running npx contextforge-mcp init is safe, it's idempotent per section. It checks for a hidden marker and only appends what's missing. Your existing content and your own edits stay exactly as they are; it just adds the new "Session Presence, Coordination Rules" block if it isn't there yet.

It's on the free tier. Five minutes to set up. And if you've ever lost an evening to two of your own agents fighting over the same file, you already know exactly what it's worth.

Parallelism without awareness isn't speed. It's a collision waiting to happen.

Give your sessions a way to see each other.

Give Your AI Coding Agent a Memory That Survives Every Session

Alfredo Izquierdo — Fri, 26 Jun 2026 22:02:27 +0000

Open a new session with Claude Code, Cursor, or Copilot and it has no idea what you were doing yesterday. Your stack, your decisions, the bug you spent an hour explaining — gone. So you re-explain. Again.

The root cause is simple: your AI's memory only lasts one conversation. Close the terminal and it's wiped.

ContextForge fixes that. It's an MCP server that gives any AI agent a permanent, searchable memory that carries across every session and every project. Below is the full setup — it takes three commands.

The walkthrough uses Claude Code as the example, but the same setup works for Cursor, ChatGPT, Claude Desktop, Windsurf, and GitHub Copilot.

📺 Watch the full walkthrough

▶️ Watch the setup on YouTube →

The setup, in three commands

1. Install the MCP server

npm install -g contextforge-mcp

2. Connect it to your editor — the wizard asks for your API key (grab a free one at contextforge.dev):

npx contextforge-setup

3. Initialize your project — this is the step people skip:

npx contextforge-mcp init

That last command writes a small rules file (CLAUDE.md for Claude Code, .cursorrules for Cursor) that tells your AI to use ContextForge for memory. Without it, your agent silently falls back to its built-in memory and ignores ContextForge — even though the server is connected.

The payoff

Once it's connected, you just talk to your agent like normal:

"Remember this is a todo app with Next.js and Supabase, deployed on Vercel. Save it to memory."

It stores that as a real, searchable memory — not in the chat, in a permanent store. Plant a couple of tasks the same way, then close the terminal and open a brand-new session:

"Let's start working on this project. What do I have pending?"

And it knows. New session, clean slate, and your agent already has your stack, your context, and your open tasks — no re-explaining. You can browse everything in the dashboard, organized by project.

Try it

ContextForge has a free tier — no credit card. Give your AI a memory that actually sticks:

👉 Get started at contextforge.dev

Works with Claude Code, Cursor, ChatGPT, Claude Desktop, Windsurf, and GitHub Copilot.

Your CLAUDE.md Is Lying to Your Agent — Why a Stale Instructions File Is Worse Than None

Alfredo Izquierdo — Tue, 23 Jun 2026 14:20:31 +0000

Your CLAUDE.md Is Lying to Your Agent

An empty CLAUDE.md is honest.

When the file isn't there, your agent does the sensible thing: it looks around. It reads the code. It asks you a question. It admits, in its quiet way, that it doesn't know yet — and so it goes and finds out.

A stale CLAUDE.md does the opposite. It walks into the room with total confidence and tells your agent something that used to be true. And your agent believes it. Why wouldn't it? You wrote it down. You committed it. It's the context file.

That's the part nobody warns you about. We talk about CLAUDE.md like it's free insurance — write it once, and your agent stops doing dumb things. Nobody mentions that the file has a half-life, and that a decayed instruction doesn't fall silent. It keeps talking. It just starts being wrong.

The Friday I got betrayed by my own notes

Let me tell you how I learned this, because I learned it the embarrassing way.

A few months ago I spent a Friday afternoon cleaning up a project. You know the kind of afternoon — the satisfying one. I pulled authentication out of a fat utils.ts file and gave it its own home. I renamed a module that had been bugging me for weeks. I deleted a helper we'd stopped using and replaced it with something cleaner. I committed all of it, closed the laptop, and felt like a responsible adult.

What I did not do was open CLAUDE.md. It was three weeks old. It still said "auth lives in utils.ts." It still named the module I'd just renamed. It still recommended the helper I'd just deleted.

Monday morning, I asked my agent to add a small feature near the auth flow. And it did exactly what I'd told it to do — back in a version of the project that no longer existed. It went looking for auth in utils.ts. It reached for the dead helper. When it couldn't find them, it didn't stop and ask. It reconstructed them. It rebuilt a little ghost of last month's codebase, confidently, because the one document I'd told it to trust said that's how things were.

The model wasn't broken. The reasoning was fine. It followed its instructions perfectly. The instructions were just lying to it — and I was the one who'd written the lie and signed it.

The half-life of a CLAUDE.md

Here's the uncomfortable truth about that file: it starts dying the moment you save it.

A CLAUDE.md is a static photograph. Your codebase is a moving thing. Every commit, every rename, every "actually, let's not do it that way" pulls the real project a half-step away from the photograph. None of those moves announce themselves to the file. The file has no idea Friday happened.

So the gap opens quietly. Day one, the photo is perfect. Week two, a couple of details are off. Month two, whole paragraphs describe a project that's been refactored out from under them. And the worst part is that it still reads fine. Stale documentation doesn't look stale. It looks authoritative. That's exactly what makes it dangerous.

This is the same disease I wrote about in context rot — more text doesn't mean more truth. A longer CLAUDE.md isn't a more reliable one. It's just a bigger surface for the rot to spread across.

Why "wrong" is worse than "empty"

We treat having some context as strictly better than having none. With static files, that math is backwards.

Anthropic's own data tells you why. The biggest single category of agent failure isn't creativity or hallucination — it's consistent wrong interpretation: the agent making the same incorrect assumption, every single run. A stale CLAUDE.md is a factory for exactly that failure. It hands the agent a wrong assumption and stamps it "official." Now the mistake isn't a one-off. It's load-bearing. Every session starts from the same wrong place and marches confidently in the same wrong direction.

Compare the two failure modes honestly:

No file: the agent is uncertain, so it explores, asks, and checks. Slower, occasionally annoying — but it self-corrects.
Stale file: the agent is certain, so it doesn't check. It just executes. Fast, smooth, and wrong in a way you won't catch until it's three commits deep.

Uncertainty is recoverable. Misplaced confidence is the thing that ships the bug.

The three ways it rots

It's never dramatic. It's always small. In my experience it's almost always one of these three:

The map stops matching the territory. You move a file, rename a module, restructure a folder. The CLAUDE.md still points at the old address, so your agent keeps knocking on a door that isn't there — and then builds a new door rather than admit it's lost.
A reversed decision keeps giving orders. "We use library X." Three weeks later you rip out library X because it didn't support your runtime. Nobody tells the file. It keeps cheerfully recommending the thing you spent a whole afternoon removing.
Yesterday's conventions outlive themselves. The rule that was right when it was just you becomes wrong the moment a teammate joins, or the project grows past the shape it had when you wrote it down.

Each one is tiny. Each one is invisible until an agent acts on it. And the friction of keeping all three in sync, by hand, forever — that's the actual problem.

"Just keep it updated" is not a plan

I know what you're thinking, because I thought it too: fine, I'll just keep the file current.

You won't. Not because you're lazy — because nobody does. Documentation that has to be hand-updated drifts out of date in every team that has ever existed, and a CLAUDE.md is documentation wearing an agent's clothes. The instinct to write down what you learn is exactly right. The mechanism — a flat file you have to remember to edit at the precise moment your hands are busy doing the thing that just made it wrong — is what's broken.

This is the same gap I keep circling back to in why your AI forgets everything: the problem was never that the agent had no memory. It's that the memory lived in a place that couldn't keep up with you. A static file can't keep up. It was never built to.

What living memory actually looks like

The fix isn't a better file. It's a different shape entirely.

Imagine memory that updates from the work instead of from your discipline. You correct the agent once — "auth moved, it's in its own module now" — and that correction sticks, surfacing the next time it's relevant instead of waiting for you to remember to go edit a paragraph. The renamed module updates because you renamed it, not because you also opened a markdown file afterward. The reversed decision stops giving orders the moment you reverse it.

And because it isn't trapped in one tool's config file, it follows you. Claude Code on Monday, Cursor on Tuesday, Copilot for the PR review on Wednesday — same memory, same truth, no three-way drift between three stale files telling three agents three different versions of last month.

That living layer is what I built ContextForge to be: a memory that plugs into Claude Code, Cursor, and Copilot over MCP, holds your corrections and decisions in one place, and surfaces the right one at the right moment instead of handing your agent a month-old photograph and calling it context.

You don't have to use mine. You can roll your own. What you can't do — what I tried to do, on that Friday, and failed — is keep a static file honest by sheer force of will.

What to do this week

Three things, and you can start the first one in the next ten minutes:

Audit your CLAUDE.md for lies. Open it and read it like a stranger. Every path, every "we use," every convention — is it still true today? Count the ones that aren't. That number is how often your agent has been confidently misled this month.
Split the durable from the decaying. Some things in that file are genuinely stable (the project's purpose, hard constraints). Some are just state that caches the current shape of the code — and state belongs somewhere that updates itself, not in a file you have to babysit.
Try a memory layer. ContextForge has a free tier that plugs into Claude Code, Cursor, and Copilot via MCP. Five minutes to set up. Your corrections start sticking instead of rotting.

An empty CLAUDE.md admits it doesn't know. A stale one pretends it does — and your agent can't tell the difference.

Stop asking your agent to trust a photograph. Give it something that can actually keep up with you.

DEV Community: Alfredo Izquierdo

Claude Code Compaction: Why Your Session Forgets Mid-Task (and the Fix)

What compaction actually does

Why you can't tell what you lost

What survives a compaction

The fix: a hook that runs after every /compact

What the hook does after every /compact

Setting it up

Where it falls short

FAQ

Claude Code Session Handoff: How to Resume Work Without Re-Explaining Everything

Claude Code Session Handoff: How to Resume Work Without Re-Explaining Everything

What Claude Code Gives You Out of the Box

Where --resume Stops Working

The Manual Handoff, and Why It Rots

Persistent Memory: Saving the Decisions, Not the Transcript

A Handoff That Actually Survives

Where It Falls Short

A Practical Next Step

Cursor Rules vs Persistent Memory

What Cursor Rules Actually Are

Why Rules Can't Remember Decisions

What Persistent Memory Adds

How ContextForge Fits In

Where It Falls Short

A Practical Next Step

How ContextForge Saves Tokens in Claude Code and Cursor

Where the tokens actually go in a coding session

Pull the two facts you need, not the forty you don't

69 tools, but the model only sees 11

The tokens you don't spend twice

Where ContextForge does not save tokens

A rough picture of one week

Where to start

How to Share Context Between Claude Code and Cursor

The Core Problem: Context Dies With the Session

The Usual Workarounds (and Why They Don't Hold Up)

What MCP Changes

A Concrete Example with ContextForge

Spaces, Projects, and Keeping Memory Honest

Limitations, Honestly

Where to Start

Does Claude Remember Between Individual Chats in the Same Thread?

How Claude's Memory Works: The Context Window

Does Claude Remember Previous Conversations?

Why Claude's Memory Trips People Up

Practical Examples: When Claude Remembers and When It Doesn't

AI Agent Memory Across Tools and the Model Context Protocol (MCP)

How to Give Claude Persistent Memory Today

Where ContextForge Fits In

The Short Answer

How to Give Claude & Cursor Persistent Memory 2026

What is an MCP memory server?

Option 1: The official MCP memory server (free, 2 minutes)

Option 2: ContextForge — a project-aware MCP memory server

Which should you pick?

FAQ

ContextForge vs Mem0 vs Zep: Best AI Memory Layer (2026)

The 30-second verdict

The real difference: three philosophies, not three feature lists

Mem0: memory as a pile of facts

Zep: memory as a timeline of entities

ContextForge: memory as your project

Head-to-head by what actually matters

A concrete way to choose

FAQ

Best AI Memory Tools for Claude in 2026 (Top 8 Ranked)

What "AI memory" actually means

How we ranked these

1. ContextForge — Best for Claude + MCP persistent memory

2. Mem0 — Best overall adoption / general memory layer

3. Zep — Best for temporal, entity-aware memory

4. Cognee — Best self-hosted graph memory (open source)

5. Letta (formerly MemGPT) — Best for agent-managed context

6. Supermemory — Best lightweight managed option

7. Basic Memory (Official Memory MCP) — Best minimal MCP server

8. Pinecone — Best managed vector store to build on

Quick comparison

How to choose

FAQ

Where `--resume` Stops Working