DEV Community: Alfredo Izquierdo

Self-Hosted Memory for AI Agents: What It Takes

Alfredo Izquierdo — Tue, 03 Nov 2026 16:32:16 +0000

Originally published on contextforge.dev.

Self-hosted memory for AI agents sounds like a database problem, and the database turns out to be the easy part.

I know because I went the other way. I build ContextForge, a memory layer for Claude Code, Cursor and Copilot, and I run it as a hosted service. The MCP server you install is open source. The storage behind it is not something you can run on your own machine today. Every few weeks someone asks me, politely, why not. This post is my honest answer, including the cases where you should not use what I built.

What "memory" has to do before it counts

Strip away the vendor language and an agent memory does three jobs:

Save a decision with its reason. "We use GraphQL for the API layer" is a fact. "Because the mobile screens needed a dozen REST calls each" is the part that stops the next agent from reopening the question.
Recall by meaning, at the right moment. Not a keyword grep. The agent working on payments/webhook.ts should get the note about the double-charge bug without knowing it exists.
Notice when it goes stale. Someone renames the file the note talks about. If the memory doesn't know, every agent that reads it is working from an old map. Static files have the same problem, just slower.

Any option below that does only the first job is a notes folder. That's fine, as long as you call it that.

The four ways to self-host it

1. Files in the repo

CLAUDE.md, .cursorrules, a docs/decisions/ folder. Zero infrastructure, versioned with the code, readable by every tool and every teammate who clones the repo.

This is where most people should start, and where I started. It fails in two predictable ways. Nothing recalls by meaning; the agent reads what fits in context and skips the rest. And nothing flags staleness; the file says whatever it said the day someone last edited it. I wrote about cursor rules versus persistent memory if you want the long version.

2. A local MCP memory server

The Model Context Protocol made this practical. A memory server is a small process your tools talk to over MCP, so Claude Code, Cursor and Copilot can all read and write the same store without custom plugins. The reference memory server from the MCP project keeps a knowledge graph in a JSON file on disk. Open-source projects like Mem0 and Graphiti can run fully local too, with your own vector store underneath.

What you get: one memory across tools, on your machine, with no account anywhere. What you don't get, out of the box: anything on your second laptop, anything for your teammate, backups, or a way to tell a stale note from a fresh one. It is memory for one person on one computer, and for a lot of developers that is exactly the right size.

3. Your own Postgres plus embeddings

The serious version. Postgres with pgvector, an embedding model running on Ollama so nothing leaves your network, a thin MCP server in front, and a job that watches git so notes tied to changed files get flagged. Now it works across machines and across people, because it's a service.

That last word is the cost. You now own uptime, auth, backups, migrations, and the Saturday when the embedding model changes and every stored vector needs recomputing. None of it is hard. All of it is time you are not spending on the product you were trying to build. I know this because that service is, roughly, what I ended up building and hosting for other people.

4. Hosted

You install an MCP server, point it at an account, and the storage, search, freshness checks and team access are someone else's job. That's ContextForge, and it's also Mem0's platform and a handful of others. The trade is obvious: your decisions live in a database you don't control.

Where ContextForge fits, and where it doesn't

Here's the honest version, since the original draft of this post (written by a model, reviewed by me) claimed you could clone ContextForge and run it on your own server. You can't, and I'd rather correct that in public than let it stand.

What you can do today:

The MCP server (contextforge-mcp, MIT) is open source. You can read every line of what runs on your machine.
It gives one memory to Claude Code, Cursor, Copilot, Claude Desktop and Windsurf, with a free tier that's enough to find out whether it changes how you work.
It does job three. Memories link to files and commits; when the code moves, the agent is told the note may be outdated and can confirm, correct or forget it.
Git integration pulls commits and PRs in as context, so "why did we do this" has the diff next to it.

What you can't do today:

Run the backend yourself. Your memories are stored in our database. If your contract or your compliance team says project decisions cannot leave your network, ContextForge is the wrong tool for you right now, and option 2 or 3 above is the right one. I'd rather say that here than have you find out after setup.
Bring your own embedding model. Search runs on our side.

Self-hosting is on my list. It isn't next, because the people writing to me are mostly stuck on jobs two and three, not on where the bytes live. If that's wrong for your case, tell me; those emails are how the list gets reordered.

How to choose

Your situation	Start with
One tool, one machine, you just want fewer repeated explanations	Files in the repo
Several tools on the same laptop, nothing may leave the machine	Local MCP memory server
A team or several machines, and data residency is a hard rule	Your own Postgres plus embeddings
A team or several machines, and you'd rather not run a service	Hosted

Whatever you pick, the thing that decides whether it works is not the storage. It's whether anyone writes to it. A memory nobody saves to is empty in every architecture.

FAQ

Is a vector database the same as agent memory?
No. It's the index. Memory also needs a write path the agent actually uses, metadata that ties notes to files and commits, and some way to detect staleness. Most self-hosted setups stop after the index.

Can I self-host ContextForge?
Not today. The MCP server is open source; the storage and search are hosted. If that rules it out for you, a local MCP memory server or Postgres with pgvector will do the job with more work on your side.

Does self-hosting make the memory more accurate?
Not by itself. Accuracy comes from what gets saved and whether stale notes get caught. Hosting changes who operates the system, not what it remembers.

If you want to try the hosted path

One command, in the repo you're working on:

npx contextforge-mcp init

It links the folder to a project so every agent in that repo shares the same memory, and adds the hooks that reload context after Claude Code compacts. Then, when something worth keeping happens, say it plainly: "Save to ContextForge: no automatic retries on the payment webhook, they double-charged customers." The next agent that touches that webhook, in whichever tool, will hear about it.

And if your answer to the data question is "it has to stay here", go build option 3. It's a good weekend. Just budget for the Saturdays after it.

Shared Memory for Multiple AI Coding Agents (What They Already Share, and What They Don't)

Alfredo Izquierdo — Thu, 29 Oct 2026 17:45:57 +0000

This morning I watched two AI agents share a memory, and neither of them used the one I built.

I was testing ContextForge's setup with a brand-new account. I asked Claude to remember a test decision: use GraphQL instead of REST for the API layer. Claude tried to search ContextForge first, got an error back, shrugged, and wrote the decision to its own built-in memory file instead. A few minutes later I opened a second session in the same folder. It found the decision right away. "This was already in my local memory," it said.

So the two sessions did share a memory. It was a markdown file on my laptop.

The error was ours. On an empty account, our search returned an error instead of an empty answer, and the fix for it had been sitting in the repo since July without ever being deployed. New users whose agent searched before saving had been hitting that same wall ever since. I deployed the fix today, ran the same test again, and this time the second session saved the decision to ContextForge too. But the detour taught me more about shared memory for multiple AI coding agents than anything I'd written about it before, so this post is about that.

"Multiple agents" means four different things

When people say they want shared memory across agents, they usually mean one of these. They don't share the same things.

Setup	What they already share	What they don't
Subagents inside one session	Whatever the parent writes into each subagent's brief, and the results they hand back	Anything the parent didn't think to pass down
Two sessions of the same tool, same folder, same machine	The tool's built-in memory for that project (in Claude Code, a `MEMORY.md` folder per project)	What the other session is doing right now
Different tools on the same repo (Claude Code and Cursor, say)	Nothing, except the files in the repo	Every decision made in the other tool
Your agent and a teammate's agent	Nothing, except what's committed	Everything that lives in either person's tool or account

The first two rows are better than they were a year ago. Claude now keeps memory per project, Claude Code writes its own notes between sessions, and that's exactly what my second session picked up this morning. If you work alone, in one tool, on one machine, you may already have all the shared memory you need. I'd rather tell you that than sell you something.

The last two rows are where it falls apart. Built-in memory lives inside one tool and one account. It doesn't cross into Cursor, it doesn't reach your other laptop, and it never reaches the person you work with.

Where shared memory actually breaks

Running into this every day, I keep seeing the same three failures.

It crosses a boundary. The decision was made in Claude Code; the next change happens in Cursor. Or on the other machine. Or in your teammate's session. The new agent has never heard of it and confidently does the opposite. I wrote about that pattern in why AI coding agents contradict earlier decisions.

The reason gets dropped. Most notes record what was decided, not why. "Use GraphQL" survives; the reason behind it (say, "the mobile screens needed a dozen REST calls each") doesn't. Without the why, the next agent re-opens the question the first time it looks inconvenient.

The memory goes stale. Someone renames the file the note talks about. The note doesn't know. Now every agent that reads it is working from a map of a building that has been remodeled. Static files like CLAUDE.md have the same problem, just slower.

What a shared memory needs to do

After this morning, my list has four items instead of three.

One place every agent can reach. Not a file inside one tool's config. Something Claude Code, Cursor, Copilot and Claude Desktop can all read and write. That's what MCP is for: one memory server, any client that speaks the protocol.
Decisions with their reason attached. Save "API layer uses GraphQL because the mobile screens needed a dozen REST calls each," not "GraphQL."
A way to notice when the code moved. If a memory points at files, it should get flagged when those files change, so an agent confirms or corrects it instead of trusting it.
It has to work on day one, when it's empty. This is the one I learned today. When an agent has two memories available, it uses whichever one answers. If the shared one returns an error, or makes the agent work for an empty answer, the agent falls back to its private memory, and your "shared" memory never gets the first entry. A shared memory that fails on empty never stops being empty.

There's also a fifth thing that isn't memory at all: knowing what the other agents are doing right now. Memory is history. If two sessions are about to edit the same module this minute, you need presence, not recall. I wrote about that separately in One Developer, Five Terminals, Zero Awareness.

How I set it up

I build ContextForge, so this is the setup I use, with my bias stated up front. In Claude Code:

claude mcp add contextforge -s user -e CONTEXTFORGE_API_KEY=<your-key> -- npx -y contextforge-mcp
cd your-project && npx contextforge-mcp init

init links the folder to a project, so every agent working in that repo reads and writes the same memory, and it adds the rules that make sessions check who else is live before big changes. For Cursor, Copilot, Claude Desktop and Windsurf it's the same server added to that tool's MCP config; the setup page now walks you through each one, because "add this to your MCP config" turned out to be where people got stuck.

Then, when something worth keeping happens, say it plainly: "Save to ContextForge: we use GraphQL for the API layer because the mobile screens needed a dozen REST calls each." Naming the memory matters more than it should. Ask an assistant to "remember" something and it may reach for its built-in memory first, which is exactly what I watched happen this morning.

What it won't do

It won't save things on its own judgment alone. Agents save what they're asked to, plus what they decide is worth keeping. A memory nobody writes to stays empty.
It isn't a lock. Presence tells one session another is on the auth module; it doesn't stop it from going there.
It doesn't replace reading the code. It tells the next agent what was decided and why. The code is still the truth for what is.

If you only ever run one tool on one machine, your built-in memory is probably enough, and you can skip all of this. If your agents cross tools, machines or people, they need one place to meet. Just make sure that place answers on day one.

Persistent Memory for Claude Desktop with MCP (Now That Claude Has Its Own)

Alfredo Izquierdo — Tue, 27 Oct 2026 16:12:59 +0000

Originally published on contextforge.dev.

When I wrote the setup guide for giving Claude persistent memory over MCP in March, Claude Desktop had no memory of its own. You closed the window and that was it. That is no longer true. Claude now saves memories on its own, lets you read and edit them in Settings, and keeps a separate memory per project. So if you're searching for persistent memory for Claude Desktop with MCP today, the honest question isn't how anymore. It's whether, and for what.

I build a memory server, so you'd expect me to say yes. The real answer is: it depends on what you need remembered. Here is what the built-in memory keeps, where it stops, and the two situations where memory over MCP earns its place next to it.

TL;DR: Claude Desktop's own memory is about you: topics, preferences, ongoing threads, saved as you chat and editable in Settings. It stays inside your Claude account. It does not reach Claude Code, Cursor, a teammate, or a repo, and it has no idea when the code it describes changed. If you only use Claude Desktop and you want it to remember you, turn it on and stop reading. If the thing you need remembered is a project (decisions, reasons, the branch you were on) that other tools or people also touch, that's the job of a memory server over MCP, and you can run both.

What Claude Desktop remembers on its own

The current memory feature, per Anthropic's help center, works like this:

Claude saves memory as individual topics while you chat, rather than summarizing afterwards. You can also say "remember this."
Each project has its own memory. In a project chat, Claude uses that project's memory plus your account memory, never another project's.
You can read, edit and delete every topic under Settings → Your Claude → Manage memory, or just tell Claude to change or forget something.
Chat search (paid plans) lets Claude look up earlier conversations when you ask. It shows up as a tool call and cites the chat it found.
Incognito chats are never saved or searched. Sensitive topics are excluded by default.
It's on by default for Free, Pro and Max on web, Desktop and mobile, as two toggles under Settings → Memory ("Search and reference chats" and "Generate memory from chats"). On Team and Enterprise an owner has to enable it, and owners cannot read members' memories.

That is a real memory. It's better than what most people had in March, and for a lot of use it is enough. The limits only show up when you look at what it is about and where it lives.

Where it stops

	Claude Desktop built-in memory	Memory over MCP (ContextForge or similar)
What it remembers	Topics about you and your ongoing conversations	Whatever the agent saves: decisions with the reason, project facts, tasks
Where it lives	Inside your Claude account	A server any MCP client can reach
Reaches Claude Code / Cursor	No	Yes, same memory from every tool
Reaches a teammate	No (owners can't even see it)	Yes, if you share the project
Tied to a repo or branch	No	Yes, memories link to a project and the files they describe
Knows when the code changed	No	Freshness check flags memories whose files changed
How it's recalled	Claude decides what's relevant	The agent runs a search, or you ask "why did we…"
What a reset does	Deletes everything, including project memories	Export, snapshot, restore

Two rows matter more than the rest. Reach: the built-in memory stops at the edge of the Claude app. The decision you made in Claude Desktop at 3 pm does not exist for Claude Code at 5 pm, and it never will, because the two don't share a store. Unit: the built-in memory is organized around you. A memory server is organized around a project, which is where "why did we make the landing page static" needs to live if a fresh session is going to stop contradicting it.

When the built-in memory is enough

Be honest with yourself about this one, because adding a server you don't need is just another thing to maintain.

You use Claude Desktop and nothing else. No Claude Code, no Cursor, no API.
What you want remembered is about you: how you like answers, what you're working on this month, the names of the things in your life.
Nobody else needs to see it.
No code is involved, or the code never changes under the memory.

If that's you, turn memory on, open Settings once to see what it saved, and you're done. I mean it.

When you need memory over MCP

You use more than one tool on the same project. This is the big one. Claude Desktop for thinking, Claude Code for building, maybe Cursor for the UI. The built-in memory lives in the first one only. Sharing context between Claude Code and Cursor is the same problem with different names.
The memory is about decisions, not preferences. "We chose soft deletes because the audit log needs the rows" has to be findable from any session, with the reason attached, or it gets re-decided.
Someone else works on it. A teammate's Claude has never heard of your Claude's memory.
The thing it describes changes. A memory that says "we're on Prisma" is actively harmful two weeks after you moved off it. Claude's built-in topics don't know your code moved. A memory server that links memories to files can flag them when those files change, which is the whole point of not letting your context go stale.

Setting it up in Claude Desktop

This part is short because the March guide has the long version. Claude Desktop reads MCP servers from one JSON file:

# macOS
~/Library/Application Support/Claude/claude_desktop_config.json
# Windows
%APPDATA%\Claude\claude_desktop_config.json

Add the server and your API key, then quit Claude Desktop completely (Cmd + Q on macOS) and reopen it:

{
  "mcpServers": {
    "contextforge": {
      "command": "npx",
      "args": ["-y", "contextforge-mcp"],
      "env": {
        "CONTEXTFORGE_API_KEY": "your-api-key-here"
      }
    }
  }
}

One thing that changed since March: Claude Desktop honors the instructions an MCP server declares about itself. Since contextforge-mcp 0.5.1 those instructions tell Claude to query memory before answering about a project and to save decisions as they happen, so on Desktop it gets used without you writing a system prompt for it. The init command and the post-compaction hook from the Claude Code guides don't apply here; Desktop has no compaction event to hook.

Running both, or just one

Full disclosure: on my own Claude Desktop both memory toggles are off. Not because the feature is bad, but because everything I'd want remembered is about a project, and I'd rather have one place to check than two. That's a preference, not a rule.

If you keep Claude's memory on, the two don't fight. Leave the built-in one for you. Point the project at the memory server. The one habit that makes it work is saying, once per project, something like: decisions and project facts go to ContextForge; use chat memory for me. After that the division holds on its own, because the server's instructions already push project decisions its way.

The honest caveat: you will occasionally get the same fact in both places. That's harmless. The harmful case is the opposite one, a decision that lives only in Desktop's memory and is invisible to the session that needed it.

What this doesn't fix

Memory over MCP is only as good as what got saved. If the agent never recorded that the migration uses soft deletes, no search will invent it.
It doesn't make Claude's built-in memory reach other tools. Nothing does; it's inside the account by design.
It's a small team's product. Setup is one JSON block, but if you want the post-compaction recall that Claude Code gets, that's a Claude Code feature, not a Desktop one.
None of this replaces reading your own code. It replaces re-explaining it.

FAQ

Does Claude Desktop's memory work in Claude Code?
No. The help center describes it for web, Desktop and mobile. Claude Code has its own mechanisms (CLAUDE.md, auto-memory, --resume) and they don't share a store with the app either.

Can I see what the MCP memory saved, the way I can in Settings?
Yes. Every memory is an item in a space in the dashboard, with the title, content and the files it references. You can edit, correct or delete it there or by asking the agent.

Do I have to turn Claude's memory off to use a memory server?
No. They coexist. Keep the built-in one for yourself and use the server for the project.

One thing to do today

Open Settings → Your Claude → Manage memory and read what Claude saved about you this month. Then ask yourself one question: is anything in there a project decision that Claude Code or a teammate would need tomorrow? If the answer is yes, that's the memory that needs to live somewhere both of them can reach.

How to Stop Claude Code From Losing Context (2026)

Alfredo Izquierdo — Fri, 16 Oct 2026 15:18:21 +0000

Originally published on contextforge.dev.

Yesterday I was in the middle of a release with Claude Code. Two hours in, the session hit the context limit and compacted itself. In the old days that was the moment everything went sideways: the summary kept the gist, dropped the task, and the next answer started from "let's review the auth changes" when we had been shipping a hook for twenty minutes. This time I asked it what it still knew, and it quoted my first request of the session, the last one before the cut, and the five memories that mattered for the branch I was on.

That difference is not luck. If you've been searching for how to stop Claude Code from losing context, here's the honest version: Claude Code loses context at four specific moments, and each one has a different fix. Some are a flag. One is a hook. None of them is "buy a bigger context window."

TL;DR: Context gets lost when the window compacts, when you start a new session, when you switch tools, and when your CLAUDE.md is out of date. Keep rules in CLAUDE.md, resume sessions instead of restarting them, install a post-compaction hook that re-injects the task, and keep decisions in a memory the agent can query from any session. The table below says which fix covers which moment.

The four moments Claude Code loses context

It helps to be precise about when it happens, because people blame the model for all four and only one is really about the model.

Compaction. The window fills, Claude Code summarizes the conversation to free space, and the summary is lossy. Decisions and the original task are the usual casualties. I wrote the long version in why your session forgets mid-task.
A new session. You close the terminal, come back tomorrow, type claude, and it's a blank slate. Everything you explained lives in a transcript it isn't reading. The session handoff post covers the manual workarounds.
A tool switch. You move to Cursor for the UI work. Nothing from Claude Code follows you, because each tool keeps its own state. Sharing context between Claude Code and Cursor is its own problem.
A stale CLAUDE.md. The file loads every session, which feels like memory until the codebase moves on and the file doesn't. Now the agent confidently follows rules that stopped being true in August. Why CLAUDE.md goes stale has the pattern.

Within a single uncompacted session, by the way, Claude does remember what you said ten messages ago. That part works. The question of whether Claude remembers between chats in the same thread is really about the four moments above.

Which fix covers which moment

Where context lives	Survives compaction	Survives a new session	Survives a tool switch	Where it breaks
`CLAUDE.md`	yes	yes	no (Cursor reads `.cursorrules`)	goes stale; nobody updates it
`claude --continue` / `--resume`	partly (the transcript is kept, the summary is what the model sees)	yes, same machine only	no	a second machine, a teammate, a different tool
Claude Code auto-memory notes	yes	yes	no	one tool, one machine, the agent decides what to write
A post-compaction hook	yes, that's its job	no	no	only Claude Code; only what the hook re-injects
Memory over MCP (ContextForge or similar)	yes, if something re-injects it	yes	yes	only as good as what the agent saved

No single row covers everything. The combination that works for me is the first, fourth and fifth rows together, and the second row for the days I just need to pick up where I left off.

Fix 1: Put rules in CLAUDE.md, not facts

CLAUDE.md is loaded on every session, so it's tempting to put everything there: the architecture, the decisions, the schema. Don't. Facts change and the file won't. Keep it for things that are true for the life of the project: how to run tests, what never to do, which tool holds the memory. Mine has one rule that matters more than the rest: at the start of a session, query memory before answering anything about the project. That single line turns a static file into a pointer at something that stays current.

If your CLAUDE.md is more than a screen long, that's the symptom. Move the facts somewhere with a date on them.

Fix 2: Resume, don't restart

The cheapest fix most people skip. claude --continue reopens the most recent session in the current directory; claude --resume lets you pick one. The transcript comes back, including what you explained an hour ago. It doesn't help you on a second machine or in another tool, and it doesn't undo a compaction that already happened, but for "I closed the terminal to get coffee" it's the whole answer.

Fix 3: Make compaction restore the task

This is the moment that used to hurt most, and it's the one where a hook changes the outcome. Claude Code runs a SessionStart hook with the matcher compact right after every compaction, and whatever that hook prints is injected into the fresh context. I covered the mechanics and the setup in the compaction post; the short version is two commands:

claude mcp add contextforge -e CONTEXTFORGE_API_KEY=<your_key> -- npx -y contextforge-mcp
npx contextforge-mcp init

What's new since that post is the second hook init now installs. A UserPromptSubmit hook records each prompt you type to a local file, so when the recall hook runs after compaction it can print your session objective (the first real request) and the last request before the cut, ahead of the memories relevant to your branch, the project's recent memories and its pending tasks. The task itself, which is what the summary drops most often, is the first line the model sees.

This is what came back after yesterday's compaction, trimmed:

## ContextForge: context restored after compaction
Session objective (the user's first request): "ya esta areglado e implementado?"
Latest request before compaction: "ok dale arranca con el 13.2"
Relevant to current work:
- contextforge-mcp 0.13.1 shipped: staged recall deadlines ...
- ROOT CAUSE stale CONTEXTFORGE_API_KEY in Claude Code env ...
Recent memories: (10)
Pending tasks: (5)

Two honest notes. The prompt log stays on your machine and is never uploaded; what leaves is the objective text, at most 600 characters, sent as a search query the same way any memory query is. And the hook never blocks a session: no key, no linked project, a slow network, and it prints nothing and exits.

Fix 4: Keep decisions where any session can ask for them

The hook only re-injects what exists. For a decision to come back next week, in Cursor, on your laptop, it has to be saved somewhere outside the transcript, with the reason attached. That's the part MCP memory does.

One correction to how this usually gets described, including by the first draft of this post: nothing is captured silently. The agent calls a tool, memory_ingest, with a title, the content and the space it belongs to. It does that on its own when the server's instructions tell it to save decisions proactively, and it does it when you say "remember this." Reading works the same way: memory_query is a semantic search, so "why did we make the landing page static" finds the decision even if nobody used those words. Memories live in spaces (topics) inside a project linked to your repo, and a freshness check flags the ones that reference files that changed since, so the agent can confirm, correct or forget them instead of acting on a fact from August.

If you want to see what that looks like when it fails, why AI coding agents contradict earlier decisions is the companion piece: the decision was saved, but without the why.

What this doesn't fix

The hooks are Claude Code only. Cursor and Windsurf get the memory over MCP but not the post-compaction re-injection, because they don't expose that event.
The objective is the first real prompt the hook logged. If you started the session with "hola" and then pasted a 2,000-word brief, the brief is what comes back, cut at 300 characters.
The relevance search is one metered query per compaction. It only runs when there's an objective or you're on a non-default branch, and it has a six-second deadline so a slow search trims the block instead of erasing it.
It's a small team's early product. Setup is one command, but the quality of what comes back is exactly the quality of what got saved. If the agent never recorded that the migration uses soft deletes, no search will invent it.
None of this replaces reading the code. It replaces re-explaining it.

FAQ

Does /compact delete my context?
It replaces the conversation with a summary. The transcript on disk is intact, but the model only sees the summary, so anything the summary dropped is gone for the session unless a hook puts it back.

Does CLAUDE.md load automatically?
Yes, at the start of every session in that directory, which is why it's the right place for rules and the wrong place for facts that change.

Does the post-compaction hook work in Cursor?
No. Cursor has no compaction hook. Memory over MCP works there; the re-injection step doesn't.

One thing to do today

Open .claude/settings.json in the project you use most. If there's no SessionStart entry with the matcher compact, you're relying on the summary to remember your task. Run npx contextforge-mcp init, work until the next compaction, and ask Claude what it still knows.

Why AI Coding Agents Contradict Earlier Decisions (and How to Stop It)

Alfredo Izquierdo — Thu, 15 Oct 2026 14:47:59 +0000

Originally published on contextforge.dev.

Two weeks ago Claude Code and I spent an afternoon on the ContextForge landing page. We decided it would be fully static, regenerated in the background, and that the live numbers would stream only in the admin. We measured it, it was faster, and I wrote the reasoning into the pull request. The following Tuesday a fresh session looked at the same page and proposed making it dynamic "so the stats are always fresh." Same model, same repo, opposite decision, delivered with total confidence.

If you've searched for why AI coding agents contradict earlier decisions, you've had a Tuesday like that. Here's the honest answer, and it isn't the one I expected when I started digging.

TL;DR: The agent isn't changing its mind. Either the decision never reached the session you're in, or it arrived stripped of the reason behind it. There are five ways that happens, and each one has a cheap fix. The expensive part is turning the fix into a habit.

It's not memory loss. It's missing input.

A language model doesn't hold opinions between calls. Every answer is computed from what's in front of it right now: your prompt, the files it opened, the conversation so far. If a decision isn't in that input, the agent isn't ignoring it. It's reasoning from the code as it is today, and in the code as it is today, the dynamic version of my landing page looks perfectly sensible.

So the frustrating question, "why does it keep contradicting me?", turns into a more useful one: "why wasn't the decision in its input?" I found five reasons. Here they are in the order I hit them.

1. The decision lives in a chat you closed

The obvious one. You and the agent worked something out in a conversation, the conversation ended, and the next session started from nothing. Claude Code can reopen a past session with --resume, and for the same machine and the same repo that's often enough. I wrote about where that stops in Claude Code session handoff.

Fix: anything you'd be annoyed to explain twice, write down somewhere the next session will read before it starts working.

2. Compaction summarized it away

This one bites inside a single session. When the context window fills up, Claude Code summarizes the conversation and continues from the summary. The summary keeps "we're working on the landing page." It drops "static, because streaming cost 40 ms and nobody needs live stats on a marketing page." Ten minutes later the agent is cheerfully proposing the thing you ruled out, and from inside the session there's no seam to notice. I dug into the mechanics in why your session forgets mid-task.

Fix: keep decisions outside the transcript and put them back after every compaction. Claude Code has a hook for exactly that moment.

3. You switched tools

Cursor in the morning, Claude Code in the afternoon, Copilot for the review. Each one has its own context, its own rules file, its own idea of your project. A decision made in one of them never visits the others. This is why the contradiction so often shows up as "but we agreed on this yesterday," when yesterday was a different tool. More on that in how to share context between Claude Code and Cursor.

Fix: one place every tool reads from, instead of one notes file per tool.

4. Your instructions file says one thing and the code says another

CLAUDE.md, .cursor/rules, copilot-instructions.md. You write them once, carefully, and then the code moves on without them. When the file says "we use library X" and the code has quietly migrated to Y, the agent has to pick a side, and it picks differently on different days. A stale instructions file is worse than none, because the agent trusts it. I've made this mistake enough times to write why your CLAUDE.md goes stale about it.

Fix: treat rules files as living documents. Prune them when a decision changes, and date the decisions you keep there.

5. You saved the what, not the why

This is the sneaky one, and the one I see most. The commit says "remove cache layer." An agent reading that learns there was a cache and now there isn't. It does not learn that the cache added latency for nothing. So the next time it meets a slow endpoint it does what any good engineer would do: it adds a cache. It isn't contradicting you. It's following the only reasoning it can see.

A decision without its reason is just a fact waiting to be overturned.

Fix: one sentence of why, every time. "Removed the cache layer: it added 40 ms and nothing read it twice." That sentence is what stops the re-litigation.

Where to keep a decision so the agent finds it again

Place	What it keeps well	Where it fails
Rules files (`CLAUDE.md`, `.cursor/rules`)	Standing conventions, how to behave	Drifts, no per-decision reasoning, one file per tool
Git commits and PRs	What changed and when	The why is thin, and agents rarely read history unless told to
ADRs in the repo	The full reasoning	Someone has to point the agent at them, and nobody updates them
Memory over MCP (ContextForge and others)	Decision plus reason plus date, searchable from any tool	Only holds what was saved, and needs a one-time setup

None of these is wrong. The mistake is expecting a rules file to carry decisions, or a commit log to carry reasons.

What I do now

I built ContextForge because I was losing this argument with my own agents several times a week. The idea is small: when we decide something, the agent saves the decision with the reason, in the project's memory. The next session, in Claude Code, Cursor or Copilot, loads that memory over MCP (Model Context Protocol) and can search it by meaning, so "landing page rendering" finds the static-page decision even if nobody used those words. After a compaction, a hook prints the latest decisions and open tasks back into the context. And when the code behind a memory changes, a freshness check flags it so the agent can confirm, correct or forget it instead of defending something that's no longer true.

Setup is one command:

claude mcp add contextforge -s user \
  -e CONTEXTFORGE_API_KEY=your-key \
  -- npx -y contextforge-mcp

Now the honest part.

It only recalls what was saved. The habit of saying "save that, with the why" is the real product. The tool just makes the habit cheap.
It won't stop an agent from arguing. It gives the agent the reason not to. That's usually enough, and sometimes the agent is right and the old decision deserves a second look.
A stale decision in memory gets defended faithfully. Freshness checks catch the cases tied to code changes. They don't replace your judgment on the rest.
It's an early product from a small team. It works for me every day. It still has rough edges, and I'd rather you hear that from me.

FAQ

Would a bigger context window fix this?
No. A bigger window lets one session hold more, and it still ends when the session ends. Most of the five causes above happen between sessions or between tools. I wrote a longer answer in bigger windows won't save you.

Doesn't Claude Code's auto-memory already handle this?
Partly. It's useful for the agent's own notes, and it stays on that machine, inside that tool. The moment you open Cursor or a laptop at home, it's not there.

Should I just put every decision in CLAUDE.md?
It'll work for a while. Then the file grows until the agent stops honoring half of it, and you're back to cause number four. Keep conventions in the rules file and decisions, with their reasons, somewhere searchable.

One thing to do today

Write down the last three decisions you made with an agent, each with a single sentence of why. Put them where the next session will read them: your rules file at minimum, a memory layer if you have one. Tomorrow, before you ask the agent to build anything, ask it "what did we decide about X?" If it answers correctly, you've just closed all five causes for that decision. Then do it for the next three.

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.

DEV Community: Alfredo Izquierdo

Self-Hosted Memory for AI Agents: What It Takes

What "memory" has to do before it counts

The four ways to self-host it

1. Files in the repo

2. A local MCP memory server

3. Your own Postgres plus embeddings

4. Hosted

Where ContextForge fits, and where it doesn't

How to choose

FAQ

If you want to try the hosted path

Shared Memory for Multiple AI Coding Agents (What They Already Share, and What They Don't)

"Multiple agents" means four different things

Where shared memory actually breaks

What a shared memory needs to do

How I set it up

What it won't do

Persistent Memory for Claude Desktop with MCP (Now That Claude Has Its Own)

What Claude Desktop remembers on its own

Where it stops

When the built-in memory is enough

When you need memory over MCP

Setting it up in Claude Desktop

Running both, or just one

What this doesn't fix

FAQ

One thing to do today

How to Stop Claude Code From Losing Context (2026)

The four moments Claude Code loses context

Which fix covers which moment

Fix 1: Put rules in CLAUDE.md, not facts

Fix 2: Resume, don't restart

Fix 3: Make compaction restore the task

Fix 4: Keep decisions where any session can ask for them

What this doesn't fix

FAQ

One thing to do today

Why AI Coding Agents Contradict Earlier Decisions (and How to Stop It)

It's not memory loss. It's missing input.

1. The decision lives in a chat you closed

2. Compaction summarized it away

3. You switched tools

4. Your instructions file says one thing and the code says another

5. You saved the what, not the why

Where to keep a decision so the agent finds it again

What I do now

FAQ

One thing to do today

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

Where `--resume` Stops Working