I compared 12 AI coding agent memories. Most only remember what, not why

Your agent does not have a memory problem. It has a "why" problem.

Every tool in this post can make an agent remember something tomorrow. A markdown file remembers what you typed into it. A memory layer remembers facts it extracted from a chat. A session recorder remembers what tools ran. Very few of them remember the thing that actually costs you time: why a fix landed, and which three obvious fixes were already tried and failed.

I spent the last few weeks reading the docs and source of every agent memory option I could find, and sending about 400 cold emails to dev teams asking how they handle memory for Claude Code, Cursor and Codex. Most of them were not convinced they needed anything new. Some of them were right. This post is the guide I wish I had before I started: what each option really stores, who writes it, how it is retrieved, whether a team can share it, and where it breaks.

Disclosure up front: I build one of the tools in this comparison (palace-rs, and the Palace team server on top of it). I have tried to describe it with the same rules as everything else: only what the repo and docs confirm, drawbacks included. You can weigh my opinions accordingly.

Monday: Alice's agent hits a flaky test in the payment webhook. It tries a retry wrapper (makes it worse). Then a longer timeout (hides it). Then it finds the real cause: the test fixture shares a database connection across workers. It fixes the fixture. The commit says:

fix: isolate webhook fixture connection Enter fullscreen mode Exit fullscreen mode Thursday: Bob's agent sees a different flaky test in the same area. It reads CLAUDE.md. Nothing about webhooks. It reads the git log and finds Alice's commit, but the commit does not say "retries and timeouts are traps here". So Bob's agent tries a retry wrapper. Then a longer timeout. Forty minutes later it lands on the same fixture fix.

Nothing in that story is exotic. It is three separate failures stacked on top of each other:

Keep those three in mind. Every option below solves some of them and ignores the rest.

"Memory" is used for at least seven different things. Mixing them up is the main reason these comparisons go nowhere.

palace-rs does not fit in one box: it is a personal memory layer, a temporal graph and agent-managed memory in one local engine. It is still single-machine; the team version of the same model is Palace Server, in family 7.

The table covers 19 live options (plus Cursor Memories, which no longer exists). The grid after it scores the 12 most common head to head. The table is long because the differences are in the details. "Who writes it" and "can it invalidate" are the two columns that matter most for coding agents, and they are the ones marketing pages skip.

CLAUDE.md, AGENTS.md,.cursor/rules/*.mdc and.github/copilot-instructions.md are the right home for rules. Build commands. "Use pnpm, not npm." "Never touch the generated client." Codex concatenates AGENTS.md files from the repo root down to the current directory and stops at 32 KiB by default. Claude Code loads CLAUDE.md files at the start of every conversation and can read AGENTS.md in their place. Cursor rules can be always-on, glob-scoped, agent-selected or manual.

Even the vendors draw this line. OpenAI's Codex docs say to keep required team guidance in AGENTS.md and treat memories as "a helpful recall layer". Anthropic's docs describe CLAUDE.md as instructions you write and auto memory as notes Claude writes itself. Instruction files are configuration. They are not memory, and they were never meant to be.

This is where I disagree with a lot of people, so I will argue it properly.

Cline's memory bank is a prompt pattern: six markdown files ( projectbrief.md, productContext.md, activeContext.md, systemPatterns.md, techContext.md, progress.md ). The agent reads all of them at task start and rewrites them when you say "update memory bank". It is a real improvement over nothing, and for a solo developer on one project it can be enough.

ADRs and commit messages are the oldest memory system we have, and the best one for decisions. One team I emailed keeps the why of every change in commit messages and swears by it. They are right that the why belongs in git.

Allium (from JUXT, MIT,.allium files) is a behavioural spec language for agentic engineering: entities plus rules in the form when / requires / ensures, with skills like /elicit (forward from intent), /distill (backward from code), /weed (reconcile spec and code) and /propagate (generate tests). Its own site pitches it as something that "persists between sessions" and surfaces contradictions that markdown lets two requirements hide. It is not YAML, despite looking a bit like it.

My argument against treating any of these as agent memory:

Allium deserves a separate note, because it is solving a different problem well. Intent drift inside a long session is real, and a formal spec that generates tests is a sharper tool than a prose PRD. But a behaviour spec is not a memory of what happened. It will tell the next agent that webhooks must be idempotent. It will not tell it that a retry wrapper already made the flaky test worse. If you adopt it, adopt it as a spec, not as your memory layer.

Where file-based approaches genuinely win: solo developers, small repos, short-lived projects, and anything that must be reviewable line by line in a PR. If that is you, stop reading here and write a good AGENTS.md.

Claude Code auto memory is on by default in local sessions. Claude writes four kinds of notes for itself ( user, feedback, project, reference ) under ~/.claude/projects/<project>/memory/, with a MEMORY.md index whose first 200 lines or 25 KB load at every session start. The docs are explicit that it skips anything derivable from the code, "such as architecture, file paths, or debugging fixes". That is a sensible design for preferences, and it also means debugging history is out of scope by design. It is per machine; your teammate's Claude does not see it.

Codex memories are off by default, live under ~/.codex/memories/, are generated in the background once a chat has gone idle, and are described by OpenAI as useful recall that is not guaranteed to load. Again: per machine.

Copilot Memory is the most interesting design of the three. Repository facts are stored with citations to the code that supports them, and before using a memory the agent checks those citations against the current branch. If the code contradicts the memory, the agent is encouraged to store a corrected version. Unused memories are deleted after 28 days. Repo facts are shared with everyone who has Copilot Memory on that repo. The catches: it is GitHub-hosted, it works with Copilot's own agents (cloud agent, code review, CLI), and it launched as a public preview, so check its current status.

Cursor Memories no longer exist. Cursor removed the feature in 2.1 (November 2025) and told users to export memories into rules. One user in that forum thread summed it up: memories were "almost no different than.mdc files".

claude-mem had 103,026 stars on GitHub when I checked today, which makes it by far the most starred project in this post. It deserves a careful look.

How it works, from its README, docs and source:

Why I do not count it as real memory for coding teams:

If you want a searchable black-box recorder of your own Claude Code sessions, claude-mem is good at that. Just be clear that a recorder answers "what happened" and you still need something that answers "what did we learn".

Mem0 (Apache-2.0, about 68k stars) is the best known memory layer. You send it conversation turns; an LLM extracts durable facts, deduplicates them, embeds them and stores them. Its own docs show the transform: "Let's use Postgres for this project" becomes Project decision: use Postgres. You can pass infer=False to store text verbatim. Retrieval fuses semantic, keyword and entity signals. Memories are scoped by user_id, agent_id and run_id. The OSS default LLM and embedder are OpenAI models, though both are configurable. OpenMemory, its local MCP server, is being sunset in favour of the Mem0 self-hosted server.

Mem0 is excellent for what it was built for: assistants that need to remember facts about a person across chats. For coding agents the extraction step is the problem. "Project decision: use Postgres" is exactly the sentence that loses the why. Its docs also note that automatic extraction is additive, so contradictions are handled with explicit update or delete calls that your app has to make.

Supermemory (MIT SDKs, about 31k stars) offers a hosted API and, more recently, a local single binary with embedded storage and local embeddings. Two details matter: its docs say the downloadable server binary is built from a separate non-public codebase, and its MCP server is available on the hosted platform only.

The official MCP knowledge-graph memory server ( @modelcontextprotocol/server-memory ) stores entities, relations and atomic observations in a local JSONL file. It describes itself as "a basic implementation". It is a perfect way to learn how MCP memory works, and a weak production choice: no semantic search, no time, one file.

Basic Memory (AGPL-3.0) keeps knowledge as markdown notes that you and the agent both edit, with observations, wikilinks and semantic search. It is the best of the "markdown, but searchable" options. The AGPL licence and the shift of its team features to a cloud offering are worth noting if you plan to embed or share it.

Zep / Graphiti brings the most rigorous idea in this space: a bi-temporal knowledge graph. Every fact edge carries when it was true and when the system learned it. When a new fact contradicts an old one, an LLM detects the overlap and the old edge is invalidated, with history kept.

Graphiti (Apache-2.0, about 32k stars) is the open framework. Zep is the commercial cloud. Zep Community Edition was discontinued in April 2025.

Graphiti's own README is honest about the cost: "You supply the graph database, LLM, and embedder, and you build the service around it: ingestion, tenancy, access control, and operations." It even says "Neither is an agent memory product". If you need temporal reasoning over business data, this is the reference design. If you want your coding agent to stop repeating dead ends this week, it is a lot of building.

Cognee (Apache-2.0, about 33k stars) builds a knowledge graph plus vector index from text, code and conversations, runs locally on SQLite, LanceDB and Kuzu by default, and exposes remember, recall and forget over MCP. It adds a code graph for questions like "what breaks if I change this signature", and a temporal mode that keeps superseded facts. Strong if you want a graph of your codebase; the memory of sessions is a smaller part of what it does.

Letta (formerly MemGPT, Apache-2.0) is agent-managed memory: core memory blocks that are always in the prompt and that the agent edits itself, plus archival memory searched with tools. Self-hosting means a server with Postgres and pgvector. The idea that the agent curates its own memory is right. The catch for coding is that Letta works best when you run your agent inside Letta (including its own Letta Code harness); bolting it onto Claude Code or Cursor gives you less of the benefit.

LangMem (MIT) is a LangGraph library for semantic, episodic and procedural memory with background consolidation. It is a toolkit, not a product. Good if you are already on LangGraph and building your own agent.

palace-rs belongs in this section too, not only with the personal layers. Its repo confirms three things that overlap with the tools above:

So for a coding agent on one machine, palace-rs gives you a temporal graph and agent-managed memory without standing up a graph database, a Postgres server or a new agent runtime. What it does not give you is cross-machine sharing (that is Palace Server), LLM-driven contradiction detection, or Cognee's code-structure graph.

Every team with a Postgres instance has thought "we could just embed our docs and chats". You can. One team I talked to did it properly, and it is the most impressive setup in this post (see below). The honest cost: you now own chunking, embedding, ranking, deduplication, staleness, permissions and the hooks that make agents use it. Vector search alone is also bad at exact names and commands, so you end up rebuilding hybrid search. DIY is the right call when memory is your product or your platform team's job. It is the wrong call when you wanted to stop re-explaining the webhook fixture.

Disclosure again: I build these. Here is what the repo and docs confirm, and where they fall short.

palace-rs (MIT, Rust) is local-first memory for one developer's agents. One binary, one SQLite file, local all-MiniLM-L6-v2 embeddings on ONNX Runtime, no API keys. palace install wires it into Claude Code, Codex, Cursor, Gemini CLI, VS Code, OpenCode, Cline, Zed, Goose, Windsurf and Claude Desktop.

What it stores: verbatim "drawers" (chunks of your repo, notes and transcripts, not LLM summaries) organised into wings (projects or topics) and rooms, with tunnels linking rooms across wings; per-agent diaries; standing rules and preferences in general/preferences, injected verbatim at every session start in every project, alongside the current project's own knowledge; and a temporal knowledge graph of facts with valid_from and valid_to (covered in the graphs section above).

Who writes it: the working agent. Hooks inject memory at session start, when you send a prompt, and while the agent greps and reads files. The installed rule tells agents to write a diary entry and record durable facts after substantive work, and a stop hook asks once if a session did real work and saved nothing. Because the agent that did the work writes the entry, "tried retries, tried timeouts, real cause was the shared fixture" can be written by the one party that actually knows it.

Correction: when a fact changes, the agent calls palace_kg_invalidate and adds the new fact, so the timeline keeps both. palace_conflicts surfaces facts that look stale or contradictory, and palace_forget removes drawers. In practice the human is the final judge: you tell the agent what is wrong, and it invalidates and refiles. Agents on the same machine share one palace, so a Codex session can pick up a Claude Code session's diary.

Drawbacks: it only shares across agents on one machine; there is no human approval gate in the code, so a wrong diary entry is stored until someone or something corrects it; quality depends on agents following the protocol; the embedding model is a one-time ~90 MB download; macOS Intel is not supported; and the published LongMemEval numbers (R@5 0.981) measure retrieval recall, not end-to-end answer quality.

Palace Server is the commercial team edition, self-hosted only. Every developer's local palace points at it with palace remote on, so the same MCP tools read and write shared drawers, knowledge-graph facts and diaries. It runs as a Docker Compose starter kit (server plus Postgres with pgvector) or a static binary with your own Postgres, computes embeddings locally, and its Docker image ships the embedding model so it can run with no outbound traffic. It adds roles, per-organisation row-level isolation in Postgres, SSO via OIDC and an audit log of memory writes.

Drawbacks: it is one more server and one more database to run, exactly the objection I heard most (below), and it is not open source.

I emailed roughly 400 teams that use coding agents, asking how they handle memory. The honest headline: most were not convinced they needed a memory product. The replies were more useful than the silence, though. Anonymised, here is what came back.

And two lessons from comment threads on my earlier posts, which changed how I think about this:

1. Do your agents run on your customers' machines? Use the assistant's built-in memory (Claude Code auto memory, Codex memories) plus a tight CLAUDE.md or AGENTS.md shipped with your product. Do not add a server or database dependency to someone else's machine.

2. Are you solo, or is this one person's agents?

3. You are a team. Can memory leave your network?

4. Do your agents need to share the why and the dead ends across developers, with invalidation, on your own infrastructure?

5. Are you building your own agent rather than using Claude Code, Cursor or Codex? Letta (agent-managed memory) or LangMem (on LangGraph). Both shine when memory is part of the agent's own loop.

Before you pick anything, answer these on one page:

If you only do one thing after reading this: next time an agent finishes a nasty bug, make it write two lines somewhere the next agent will see: the cause, and the things that looked right but were not. Whatever tool you use, that is the part that is missing today.

What does your team do with the dead ends? I am genuinely curious, especially if you have a setup that works without any of the tools above.