MCP memory servers for Claude Code and Cursor: which client, and whose memory

This is the written half of a video, What are the top MCP memory servers for Claude Code and Cursor?, and the sections below follow its chapters in order so anyone arriving from the end card can pick up where they stopped. Two of the claims in that video are wrong. Both are ours, both are corrected here rather than quietly, and the correction comes before the comparison does.

The question in the title cannot be answered as asked. "Top MCP memory server for Claude Code and Cursor" hides two earlier questions, and until those are answered no name is meaningful: which of the two clients are you actually in, and should the memory belong to the repository you are working in or to you, across everything you work on. Six systems answer those two questions differently enough that the field reorders twice.

TL;DR

• In the terminal, the shape has changed. All five competing vendors checked here now ship a first-party plugin for Claude Code, four of them documented on a page of the vendor's own, so what you are usually choosing is a plugin with a protocol server inside rather than a bare server. One of them ships a plugin with no protocol server at all.
• The asymmetry between the two clients is real, and it flips vendor by vendor. Cognee gives the terminal a plugin and the editor a hand-edited configuration block; Supermemory does the reverse on its client list; Graphiti documents Cursor by name and gives Claude Code no setup page we found.
• Hooks and tools fail differently, and neither failure is in a headline. A tool that never gets called saves nothing and errors nothing. A hook that fires while the backend is unreachable drops that stretch of the session for good, which the vendor shipping hooks says itself.
• The row that actually decides is where the memory is keyed: to the repository, to a dataset, or to the person signed in.
• Cursor is the cleanest illustration of the question, and it is the one people get wrong in both directions. Its editor memory was announced, made generally available, and then the interface for managing it went, with everything said about that in public said on the support forum by one staff account whose replies contradict each other.
• Disclosure, in full, in the next section rather than in the footer: we build one of the six, we publish a plugin for each client, and on the two rows this article turns on we come off worst.

Disclosure, and it goes first

We build one of the systems compared here. Mnemoverse is a hosted memory layer, and we publish a plugin for each of the two clients in the question: mnemoverse/claude-plugin and mnemoverse/cursor-plugin, both public, both MIT. Here is where we come off worst, on the two rows this piece turns on.

Neither of our plugins registers a lifecycle hook. Every text file in both repositories was read on 8 September 2026, nine files in one and five in the other, the licence aside: the word hook occurs in none of them, and neither repository holds a hooks manifest or a hooks directory. What ours ship instead is a standing instruction, a skill in the Claude Code plugin and a rule plus the same skill in the Cursor one. A standing instruction works only if the model reads it and then does what it says, and our own documentation states that without softening it: "Connecting Mnemoverse gives your agent the memory tools. It does not guarantee the agent uses them." The Cursor rule ships with alwaysApply: false in its front matter, which leaves it to the editor and the model whether it enters the session at all.

The second one is worse, because it is not a design trade. Our own documentation site does not mention either plugin. Checked live on 8 September 2026: every /docs/api page in the sidebar, eighteen of them, plus the site's llms.txt, its llms-full.txt, and five marketing pages. The word plugin appears zero times in all of them except llms-full.txt, where all thirteen occurrences describe somebody else's plugin. Our VS Code extension is documented, with its marketplace link. The two plugins in this comparison are on GitHub and nowhere else we publish.

So the way in that our own documentation hands a reader is the bare protocol server, which is the shape this article is about to say the rest of the field has been moving away from. And the install path a reader would try first does not work today either: the plugin's own README puts the marketplace route behind a condition, "From the community marketplace (once the plugin is accepted there):", and on 8 September 2026 a search of that community listing returns zero files and zero pull requests naming us, against a control that returns fifty-one files for the word plugin. The path that works is the one in the same README below it, installing from the repository directory itself.

Two corrections to the video, and the single cause behind both

Correction one, Letta. The video says four of the five competitors ship Claude Code memory as a plugin. It is five of five. letta-ai/claude-subconscious is a first-party Letta repository: owner letta-ai, owner type Organization, public, not archived, not a fork, MIT, described in one line as "Give Claude Code a subconscious". Its plugin manifest is version 2.1.1 and names Letta as author, with the description "A subconscious for Claude Code. A Letta agent watches your sessions, accumulates context, and whispers guidance back." Its hooks manifest registers four lifecycle events, SessionStart, PreToolUse, UserPromptSubmit and Stop, across five command entries, because SessionStart carries two. The repository was created on 14 January 2026 and last pushed on 27 August 2026, so this is not the vendor moving after we looked. It is us not finding it.

Correction two, Supermemory and the free tier. The video says Supermemory's own pages disagree about whether its plugins are on the free plan, and that the video will not pick a side. The vendor had already spoken, in a dated entry we did not read, and the state today is a third thing rather than either of the first two. It is set out in full in the gates section below.

Both misses have the same cause, and it is worth stating on its own. We swept documentation trees. A changelog and a vendor's own GitHub organisation are documentation too, and that is exactly where both of these lived. This is not an abstract lesson; it is mechanical, and both vendors demonstrate it. Supermemory's machine-readable documentation index lists its billing reference, "Billing & usage: Enterprise-grade reference for Supermemory metering", and lists no changelog at all, zero lines containing the word: a tree sweep therefore finds one of the vendor's two answers, and it is the one the vendor later corrected. On the Letta side, docs.letta.com/sitemap-0.xml holds 632 addresses and zero occurrences of subconscious, llms.txt has zero against a control of 155 lines carrying the vendor's own name, and the changelog has zero against a control of 1,496 occurrences of it. Listing the organisation's repositories instead returns 61 public repositories, of which exactly two name Claude in their name or description, and the plugin is one of them. One sweep finds nothing; the other finds it on the first pass.

Three different things are called Claude's memory

Before naming a single server, one separation has to be made, because three different things are called Claude's memory, they are built differently, and only the third is what this question is about.

The first is the memory in the chat application. Anthropic unified it with Cowork at the end of August, and it is on by default on the consumer plans, the free one included: "Memory is on by default for Free, Pro, and Max plans on the web, Claude Desktop, and Claude Mobile". Listen to which surfaces that names. Web, desktop, mobile. Across the announcement and both help articles, the words Claude Code, terminal and API appear zero times in the article text. That last unit matters, because a reader checking it will find those words in the site navigation and footer. Anthropic has not published a sentence saying that memory does not reach the terminal. It has published a scope that does not contain it, which is a smaller claim and the only one the pages support.

The second is the one Claude Code keeps for itself, on your own disk, and it is already switched on: "Auto memory is on by default."

The third is memory over the Model Context Protocol, which is what the rest of this page is about. Worth noticing that Anthropic documents the pipe and never the use case: on its own page about connecting these servers, the word memory appears zero times.

What you already have, before installing anything

Since the terminal already ships a memory, the honest question is not how to get one. It is what a server adds that this does not have. Claude Code writes its own notes, in plain files, one directory per project, and loads them every session. The limit that decides this comparison is the other one, and it is stated in four words: "Auto memory is machine-local."

Per repository, on this computer. Not per account, not synchronised. So what a memory server actually answers is not whether the agent can remember. It is how far the remembering reaches.

Cursor shipped one too, and it is the one people get wrong in both directions

Say Cursor has nothing documented about memory and its own changelog contradicts you. Say its editor memory is working today and its own support forum contradicts you. So start with the part nobody disputes.

Announced, then generally available. Cursor announced editor Memories in changelog 1.0, dated 4 June 2025, and announced it as a beta: "We're rolling out Memories as a beta feature." The same entry describes the scope: "With Memories, Cursor can remember facts from conversations and reference them in the future. Memories are stored per project on an individual level, and can be managed from Settings." A month later changelog 1.2, dated 3 July 2025, marked it generally available: "Memories is now GA. Since 1.0, we've improved memory generation quality, added in-editor UI polish, and introduced user approvals for background-generated memories to preserve trust." Both entries are live today.

Then the interface for managing it went, and everything said about that in public was said on the support forum. Five replies, in four threads, all from one account carrying the CursorStaff group, and they do not agree with each other. On 24 November 2025 it answered a bug report: "The Memories feature was removed starting from version 2.1.17, so it no longer appears in your current version (2.1.25)." The next day, a second thread: "The Memories feature was intentionally removed starting from version 2.1.x." Then on 7 January 2026, a third: "The Memories feature was intentionally removed starting in version 2.1.x, so the UI to manage them is no longer available. Even though this feature was removed from Cursor, it still works, just without a UI." And on 10 January 2026, a fourth: "The Memories feature hasn’t been removed. In version 2.1.x, only the UI to manage it was removed. The feature itself still works." Users had reported the loss three days before the first of those replies: "After upgrading to version 2.1.17, there is no longer any memories in the cursor settings." All five replies were re-read from the forum’s raw endpoint on 8 September 2026, with a control: a fabricated post id returns 404 on the same endpoint. The one thing every reply agrees on is that the interface for managing memories left at 2.1.x. Whether the feature itself is gone is a question the vendor has answered both ways, which is why this article says the interface went and does not say the feature was withdrawn. Cursor did not announce any of this in the changelog, and this article does not say the vendor hid it either, because nobody outside Cursor knows why.

The changelog, with the unit named, because a reader will re-check it. The changelog archive was enumerated in full on 8 September 2026: 251 entries, every one answering 200, from May 2023 to today. Seventeen of them contain the string memor. Thirteen of those are about RAM or an in-memory store, the editor feature is in exactly two of them, 1.0 and 1.2, and two later entries are about memory for cloud automations. No entry announces the removal. Anyone repeating this with a plain grep will get seventeen entries rather than two, which is why the count is given together with what each entry is actually about.

The address that would hold a reference page tells the same story twice. cursor.com/docs/memories returns 404 with no redirect, and cursor.com/docs/context/memories takes one hop to cursor.com/docs/rules. Read on its own that looks like a page somebody forgot to write. Read next to the migration the staff reply offered, "You can export your memories and move them into Rules:", it is the trace of the move, because rules is where the vendor pointed people. The rules page carries the reasoning in the vendor's own words: "Large language models don't retain memory between completions. Rules provide persistent, reusable context at the prompt level."

A feature named Memories is documented today, and it is not the editor one. It belongs to cloud automations: "Memories let the agent read and write persistent notes across runs for the same automation." Each one is a named entry, "Each memory is stored as a named entry (MEMORIES.md by default) that exists outside the agent's working filesystem.", they are on unless you switch them off, "Memories are enabled by default but can be disabled.", and the page carries its own warning rather than leaving it to a reviewer: "Memories persist across runs and should be used with caution if your automation handles untrusted input." Cursor also documents memory for its Bots without calling it Memories: "A Bot retains stable preferences, important facts, and summaries from its work, which lets it keep a role over time without replaying every prior message." So the sentence that survives is narrow. The editor feature is gone from the editor. Memory under other names is documented and shipping.

It would also be wrong to finish this row with the words no cross-session context. Cursor documents a conversation search today, and it is worth being exact about who runs it. The page describes a person's search rather than a call the agent makes: "Find past agent conversations and jump to matches inside long transcripts", opened from the Agents Window through the command palette, and "Cursor builds a local search index that scales to thousands of conversations." The documentation index lists four agent tool pages, terminal, browser, search and canvas, and conversation search is not one of them. The one place where the agent is the one doing the searching is a forum reply from a CursorStaff account on 18 August 2026: "Search across past chats: the agent can search previous conversations to pull up context from earlier work." Past sessions are reachable. Which side of the keyboard reaches them is answered differently by the documentation and by the forum, and this article reports both rather than picking.

One more thing anyone re-checking this will find, so it belongs here rather than in a correction later. On 18 August 2026 the same staff account listed, among things that "might help you right now", the bullet "Memories: the agent can save facts and decisions across sessions, so you don't have to re-explain context every time." That bullet carries no link, while the Rules bullet in the same list links to the documentation. The same reply also says "Agent memory is being actively discussed" and routes the reader to two open feature requests. This article reports what the vendor said and when it said it. It does not claim to know what the current build does.

The migration is reported here as what was said, not as a step to run today. In the same November thread, one day after the export advice, a user on build 2.1.34 answered: "That option is not available for me, and I do not have access to my memories, which I would like to recover." The one person who did report a successful export had gone back to build 2.0.77 first. Nobody has shown the command on the current build.

One boundary, stated here rather than assumed. Everything above is a claim about what the vendor has published. Nobody on this side opened a running Cursor and looked at its settings; the current stable build reported by Cursor's own download endpoint on 8 September 2026 is 3.19.13.

And this is why Cursor is in an article about memory servers at all. A memory that ships inside the editor answers a different question from a memory that ships as a protocol server or a plugin, and it can also be taken back out by the vendor between two minor versions, which a server you installed yourself cannot be. That is not a mark against Cursor. It is the shape of the choice, and it is the reason the row about where the memory lives decides more than the row about who has the feature.

In the terminal, five of five now hand you a plugin

Here is the finding, and it partly refuses the question. Checked live on 8 September 2026, every one of the five competing vendors ships a first-party plugin for Claude Code, and four of the five document the install on a page of their own. So in the terminal, what you are choosing is usually not a bare protocol server. It is a plugin with a protocol server inside, and in one case a plugin with none.

Mem0 documents the plugin on its own integrations page, which opens by naming the problem: "Claude Code forgets everything between sessions. This plugin fixes that." The install line on that page is claude plugin install mem0@mem0-plugins --scope user --config api_key="$MEM0_API_KEY", and the marketplace manifest sits in Mem0's own repository, describing itself as official Mem0 plugins for Claude.

Cognee documents both paths and then steers you off the protocol one, calling the plugin the simpler route. Its page installs with claude plugin install cognee-memory@cognee and states plainly what the plugin does that a server does not: "The plugin registers Claude Code lifecycle hooks:", followed by a table naming six of them.

Supermemory is the sharpest case for the shape of the change. Its Claude Code page opens by saying the tool "is a Claude Code plugin that gives your AI persistent memory across sessions", and on that page the words MCP and protocol appear zero times each, against forty-eight occurrences of memory. The instructions a person follows to give Claude Code memory never mention the protocol at all.

Zep documents a Claude Code section inside its help centre with a marketplace block and the line claude plugin install zep-memory@zep-memory, and it is careful about two things that catch people: "A Claude app marketplace install does not apply to Claude Code." and "Enabling a plug-in from a GitHub marketplace does not install the files".

And Letta, which the video got wrong. The plugin is real, first-party and eight months old, and its details are in the corrections section above.

One caveat travels with that count, and it belongs in this paragraph rather than a footnote, because this article is about to tell readers to check a vendor's GitHub organisation. Zep's row rests on its help centre, which documents the Claude Code install by name. The README of the very repository that help centre tells you to add says, in its opening paragraph: "Not positioned for Claude Code, Codex, or other coding-agent CLIs." The README inside the plugin folder names Cursor, the Claude chat and desktop products and ChatGPT for knowledge work, and does not name Claude Code; the plugin manifest does not name it either. Both surfaces are the vendor's. That line is not a fresh edit: the README's last commit is dated 25 August 2026, so it was there when we did the research too. We report where each page sits and what it says, and we do not guess which one reflects intent.

One claim from the video survives the Letta correction intact. A first-party npm package under Letta's name does exist for a memory MCP server, @letta-ai/memory-mcp. The repository field in its metadata points at an address that returns 404, checked with a control that returns 200 on the repository above, and the README published with the package belongs to a different project entirely: it opens "The MCP registry provides MCP clients with a list of MCP servers, like an app store for MCP servers." Nobody here installed or ran it, so this article does not say it is broken and does not describe it as a maintained path. It says what the published metadata shows.

The asymmetry is real, and it flips vendor by vendor

Now the other client in the question. Each vendor treats the two differently, and which client gets the fuller path is not the same answer twice.

Cognee is the clean case: its plugin index names four coding tools and Cursor is not one of them, so Cursor gets a configuration block edited by hand.

Mem0 looks like the same story and is not. Its Cursor page labels all three routes protocol only, while its own machine-readable documentation index describes a shared editor plugin providing, in its words, "MCP server connection, lifecycle hooks, and skill bundling for Cursor". So Cursor is served, just not from the page a person reading about Cursor lands on. That single line is also what broke the first draft of the video: a sweep of the Cursor page alone reported an absence that the vendor's own index refutes.

Supermemory inverts it. The page listing its memory server's clients does not name Claude Code, and its Claude Code page never uses the word protocol; Cursor is on that client list and has a plugin of its own besides. The client missing from that list is the terminal, not the editor.

Graphiti, the self-hosted half of Zep, documents Cursor by name with its own walkthrough, while no page we found gives Claude Code a setup of its own. Its server also describes itself, in its own readme, as experimental.

Letta, after the correction, lands on the other side of the same asymmetry: a first-party plugin for the terminal and, on the surfaces swept here, nothing for the editor.

So the same vendor often builds the two clients different things, and which one is more fully served changes depending on whose page you are on. A recommendation that does not ask which client you are in is not an answer.

A hook fires. A tool has to be chosen.

That difference in shape is not packaging, and this is why. A plugin's hooks fire on events in the session, whether or not the model thinks of it. A protocol tool fires when the model decides to call it. Anthropic states the second half plainly: "You don't normally need to name a server in your prompt, since Claude chooses relevant tools on its own."

Most of the time that is exactly what you want. When it is not, the failure is quiet, and one vendor documents the symptom against a neighbouring surface in its own troubleshooting list: "Claude never calls the mem0 tools, even though the connector shows as connected". Connected, listed, and unused. Nothing errors. That is the real argument for hooks, and it is a good one.

It is not a free one, and the same vendor that ships hooks says why: "Hooks are callbacks from Claude Code, not a durable job queue: events that happen while the plugin is uninstalled, failing, or unable to reach the backend are not replayed later."

So the two shapes fail differently, and neither failure is in anybody's headline: a tool that never gets called saves nothing, and a hook that fires while the backend is unreachable drops that stretch of the session for good.

Who documents which, with the sources named, because attribution is the whole point here. Cognee names its events on its own documentation page, six of them in a table: SessionStart, UserPromptSubmit, PostToolUse, Stop, PreCompact and SessionEnd. Mem0 names hooks on its Claude Code page. Supermemory's page mentions them once, saying "the memory hooks run as Node scripts", and does not name the events; the events are in its plugin repository instead, four of them in the plugin's own hooks manifest, so that attribution is available but it comes from the repository rather than the documentation. Letta's plugin registers four lifecycle events across five command entries, as set out above. Zep's plugin registers none: nineteen files in the repository, no path containing the word hook, and zero occurrences of hook across three of its help pages. Ours register none either.

Repository, account, or person: the row that decides everything

Here is the question that actually decides the choice, and it is not the one people ask first. Where does the memory live: with the repository you are in, or with you, across everything you work on.

Supermemory keys its coding plugins to the repository, sharing one tag across its coding tools, and the tag is derived by default rather than chosen: "The project ID is a stable hash of the normalized Git remote. Repositories without a remote fall back to their resolved local path."

Mem0's plugin is repository-scoped too, and its cross-machine behaviour is not automatic: the identifier defaults to your local account name, and the vendor's own instruction is to set it by hand if you want memories shared between machines.

Cognee goes the other way. Its memory is scoped to a dataset rather than a folder, so it crosses projects, and across its own plugins it crosses tools: "The Claude Code and Codex plugins share the default dataset, so memory carries across both."

Zep's hosted server is bound to the person rather than the place. Nothing is scoped to a directory at all, and one boundary is worth knowing: the project is fixed inside the token you signed in with, so a client cannot switch it without signing in again.

Letta's plugin is deliberately not placed in this row. Nothing in this sweep checked how it scopes, and an unchecked answer is worse than a missing one.

Ours sits with the account. Both of our plugins point at one hosted endpoint, "url": "https://mcp.mnemoverse.com/mcp", reached by signing in rather than by a key in the configuration file, so the same memory reads from the other client. The command our own Claude Code page prints registers the server with claude mcp add mnemoverse -s user, at user scope rather than inside one project.

The gates nobody puts in the headline, ours first

Now the parts that decide whether any of this works on a Tuesday afternoon. Ours goes first, because it is the one we have least excuse for getting wrong.

Mnemoverse. The gap is the hook gap, stated in the disclosure above and restated here because this is the section where it costs something. A skill still depends on the model cooperating; a hook does not. Our own Cursor page says the same thing in its own words: "Connecting adds the memory tools; it doesn't make the assistant use them. By default it answers from its own context, not Mnemoverse." And our guide on the subject does not soften it either: "But a tool being available is not the same as the agent calling it." Two of the five competitors name the session events their hooks fire on in their documentation, a third names them only inside its plugin repository, a fourth registers four events, and the fifth, like ours, ships a skill and a protocol server and no hooks at all. So we are not alone in the shape, and we are still on the wrong side of the gap. One more piece of our own housekeeping, since it is on a page a stranger lands on: the package our plugins wrap is pre-1.0, and our own changelog says what that means, "The project is pre-1.0, so a MINOR bump may change behaviour."

Supermemory, and the free tier, which is correction two. This takes three moves, because the vendor's surfaces do not currently agree with each other. First, the dated word from the vendor. A changelog entry of 15 August 2026, titled "All coding agent plugins are now free, including OpenClaw", says: "No Supermemory plugin sits behind a paid plan any more. Claude Code, Cursor, Codex, OpenCode, and OpenClaw are all free on any account, including the free tier." The same entry draws its own boundary in the next breath: "OpenClaw is now free too, so no coding agent plugin sits behind a plan gate. Usage still counts toward your plan's included credits." A free plugin is not free usage, and the vendor is the one saying so. Second, what the vendor's other pages show on the day this article is published. On 8 September 2026 the pricing page carries "All plugins: Claude Code, Cursor, Hermes and more" as a bullet of the Pro plan at 19 USD a month, while the free plan's four bullets name no plugin at all; and the billing reference in the documentation tree still holds a feature-matrix row whose label cell reads "Plugins (Claude Code, Cursor, Hermes, …)" with a dash in the Free column, exactly as an archived copy from 15 August shows it. The changelog entry also says the billing screen was updated, "Billing lists every plugin under Free, and the plan-specific errors on connect have been replaced with the real reason a key could not be created."; that screen sits behind a console sign-in and this review did not open it, which is said here rather than left as an assumption. Third, the conclusion, without a motive attached: which surface matches the code is not something we know or name. What we name is where each statement sits and what date it carries. And the mechanical detail that explains how easy this is to miss is the one from the corrections section: the vendor's own machine index lists the billing page and not the changelog, so a documentation-tree sweep finds one answer of two.

And our own two pages are on the wrong side of that same drift, which is the strictest thing in this section. Two live pages on this site, both dated in early September, tell readers that Supermemory's pricing page lists the plugins under the free plan. One of them says it in these words: "The pricing page, checked live, lists the plugins and the MCP server under the free plan, so plan access is not the gate either." As of 8 September 2026 the pricing page does not read that way, and none of the four pages in the vendor's MCP section contains the word free at all, checked against a control of seventy-six occurrences of the word memory on the overview page of that same section. Those readings were true on the day they were taken and they are dated on the page, which is the only reason this is drift rather than an error. It is the same failure as the video's, from the opposite side: the video reported a contradiction the vendor had already resolved, and our library reported a resolution the vendor's other pages have not followed.

Zep. The two install caveats quoted above are the gate, and they are the vendor's own words rather than our commentary: a marketplace install from the Claude application does not carry over to Claude Code, and enabling a plug-in from a GitHub marketplace is not the same as installing the files. Add to that the README mismatch already named, which is a gate of a different kind: two vendor surfaces answering the same question differently.

Mem0 needs an account and a key, which is visible in the install line itself rather than a page further in.

Cognee ships the hooks, and the counterweight it publishes about them is quoted above. It is worth reading before choosing hooks for reliability reasons.

Letta. The plugin exists, it is first-party, and its own README declines the role a reader might give it: "Claude Subconscious is demo app built using the Letta Code SDK, and is not intended to be used in production." The missing article in that sentence is the vendor's and is left alone. Separately, and this is the claim from the video that survives, Letta documents the plugin on none of the three surfaces swept here: sitemap, machine index and changelog, each with a control.

What "top" means once you have picked

So, the actual answer. There is no single top server here, and anybody who hands you one has skipped the question that decides it: which client, and whether the memory should belong to the repository or to you.

In the terminal, five of five now ship a plugin, four of them documented on the vendor's own pages, and at least one steers you onto it, so what you are choosing there usually has a protocol server inside a plugin rather than on its own. In Cursor the answer does not simply flip: several of those five ship the editor a plugin as well, and at least one ships the editor the fuller path and the terminal the thinner one.

Ask for repository memory and two of the plugin paths are built for it, by a git-remote hash in one case and a hand-set identifier in the other. Ask for one that follows you across both clients and it is the account-scoped and dataset-scoped ones, ours among them, with the honest catch that ours only works when the model actually calls it, and that a hook does not have that catch.

There is not one performance number on this page, ours or anyone else's. Every claim came from what its own vendor publishes, checked on the dates named, and where that meant saying something uncomfortable about us, it went in.

The table

system	Claude Code path	Cursor path	lifecycle hooks	where the memory is keyed
Mnemoverse	plugin published on GitHub; the documented way in is the protocol server, -s user	plugin published on GitHub; the documented way in is a configuration block	none in either plugin, a skill and a rule instead, the rule with alwaysApply: false	the account, one hosted endpoint reached by signing in
Mem0	plugin, install line on its own page, account and key required	protocol-only on its Cursor page; a shared editor plugin with hooks described in its documentation index	named on its Claude Code page	the repository; the cross-machine identifier defaults to the local account name
Supermemory	plugin; the page never uses the words MCP or protocol	on the memory server's client list, plus a plugin of its own	mentioned on the page as Node scripts, events named only in the plugin repository	the repository, by a stable hash of the git remote
Cognee	plugin, with six lifecycle events named in a table	not among the four coding tools its plugin index names; a hand-edited configuration block	six, named in the documentation	a dataset, so it crosses projects and its own tools
Zep / Graphiti	plugin section in the help centre; the plugin repository's README says it is not positioned for Claude Code	Graphiti documents Cursor by name with its own walkthrough; Graphiti calls itself experimental	none: nineteen files, no path containing hook	the person signed in; the project is fixed inside the token
Letta	first-party plugin repository, four lifecycle events, documented on no Letta page swept here; README calls it a demo rather than a production path	none found on the surfaces swept here	four events, five command entries	not checked here, and not guessed

A ten-minute check on your own setup

Do this before taking any comparison's word for it, including this one.

Open the vendor page you would actually follow and search that page for the word plugin and for the word protocol. If only one of them is there, you have learned which shape that vendor is steering you into, which is more useful than a feature list. Then open the vendor's GitHub organisation, not just its documentation, and read the README of the repository the documentation tells you to install: that is where two of the findings on this page came from, and one of them contradicts the vendor's own help centre. Then check the changelog, which is documentation the tree sweep misses and which is where a vendor most often answers a pricing or availability question. Finally, ask the only question that reorders the field: when you move to another repository tomorrow, should the memory come with you. Your answer to that decides more than any of the rows above.

Related

• What survives when AI agents restart: the client side of the same question, five coding tools on resume, compaction and built-in memory, and the same Cursor history in a shorter form
• Best persistent memory APIs compared: the vendor side, six systems on six criteria
• MCP servers that share state across IDEs: the cross-tool half, and the quiet ways sharing stops
• CLAUDE.md, AGENTS.md and Cursor rules do not enforce: why a standing instruction is not a hook, in more detail than the disclosure above allows
• Claude Code guide: connecting a memory layer to the client named most often above

---

Live probes for this article were run on 2026-09-08 with full browser headers, with negative results controlled and quotations taken from extracted page text rather than from raw HTML, because markup breaks a sentence across tags. Vendor pages re-checked that day: the Cursor changelog archive in full, cursor.com/docs/llms.txt and all 244 documentation pages listed in it, four Cursor forum topics, docs.mem0.ai, docs.cognee.ai, supermemory.ai/docs with its changelog and pricing page, help.getzep.com, github.com/getzep/zep-memory-plugin, github.com/letta-ai/claude-subconscious, docs.letta.com, and our own two plugin repositories and documentation site. The Anthropic and Claude Code quotations, and the vendor quotations in the hooks and scoping sections, were fetched live on 2026-09-04 for the paired video and re-checked at their sources on 2026-09-07; every quotation on this page is a contiguous substring of the page named beside it, with the vendor's own punctuation, spelling and missing articles preserved. Where this article states an absence, it names the surfaces its sweep covered rather than claiming a feature does not exist. Disclosure: this site publishes one of the six systems compared, and the sections about where we sit name our own gaps before anybody else's. No performance, latency, accuracy or benchmark number appears in this article, for any system.