Open Memory Protocol Released: One Memory Feeds All Large Models

The open-source project **Open Memory Protocol** attempts to build a shared memory layer for models like Claude, ChatGPT, and Cursor, so that what you tell the AI in tool A doesn’t need to be repeated in tool B. The real challenge here has never been storage, but the protocol itself.
One Memory Across Four Chat Windows
In the developer community, a new GitHub repository has been attracting attention—Open Memory Protocol (OMP). The project’s goal sounds simple: allow Claude, ChatGPT, Cursor, and other tools you switch between every day to share the same long-term memory. If you tell the AI in Cursor your coding style preferences, then switch to Claude to write a design document, it shouldn’t ask again, “What programming language do you prefer?”
Everyone agrees this is the way it should work, yet no one has actually pulled it off in the past two years. The reason isn’t technology—vector databases are everywhere—but that each vendor keeps their memory locked inside their own walled garden. OpenAI added memory to ChatGPT in February 2024, but stores it on its own servers; Anthropic didn’t offer a memory importing tool for Claude’s paid users until October 2025, and only in March 2026 opened it to free users. Honestly, Claude’s memory mechanism is much simpler than ChatGPT’s—more like “retrieving old conversations on demand” than a true user profile; Gemini took the ChatGPT approach, allowing manual user input. The three systems are mutually incompatible.
OMP’s solution is to bypass vendors and define its own layer of protocol.

What It Actually Is
Strictly speaking, Open Memory Protocol is not a product; it’s a specification plus a reference implementation. The specification defines the data structure of memory entries, read/write interfaces, and a permission model; the reference implementation provides a locally running server and client adapters for Claude Desktop, ChatGPT Desktop, and Cursor.
The core data model is pretty restrained—each memory entry consists of:
id: UUID, globally uniquecontent: the memory itself, in natural language textcategory: tag such aspreference,project,factsource: which client wrote the memorycreated_at/updated_at: timestampsembedding: optional vector representation for semantic searchmetadata: free-form extension fields
Read/write happens over HTTP, default port 8765, running locally. Clients connect via the MCP (Model Context Protocol)—a critical point, meaning OMP hasn’t reinvented the wheel, but builds on Anthropic’s MCP from last year. Claude Desktop natively supports MCP; Cursor has followed suit; ChatGPT Desktop currently connects through an intermediary adapter.
Search logic follows two paths: exact match via traditional keywords, semantic recall via vector similarity. By default, embeddings are generated locally using a sentence-transformers model, avoiding any cloud dependency—a friendly feature for privacy-conscious developers.
Why Now
To understand OMP’s significance, it helps to look at how crowded the LLM memory space has become.
Between 2024 and 2025, academia alone produced numerous solutions. MemGPT borrowed the paging mechanism from operating systems to create layered memory for large models; BUPT’s MemoryOS merged segment-page storage with layered human memory; MIRIX divided memory into six specialized components; ByteDance partnered with Zhejiang University and Shanghai Jiao Tong University to create M3-Agent, extending memory capabilities to video and audio. Commercial products include Letta (from the MemGPT team), Mem0, Zep, and MemoryOS from Memory Tensor, lined up one after another.
These solutions share a key limitation: they focus on “how a single Agent can remember more,” not “how multiple Agents can share memory.” Mem0 once offered a browser plugin to sync ChatGPT and Claude memories in their web interfaces, but it was more of a hack—reading the DOM via Tampermonkey scripts and injecting prompts—effectively stitching together at the UI level, not achieving protocol-level interoperability.
OMP’s position is different. It defines itself at the protocol layer, like LSP (Language Server Protocol) for editors, or the OpenAI Chat Completions API for inference services. Once the protocol is widely accepted, who implements the clients or the servers becomes a market decision.
That explains why the open-source community is watching it. MCP has become a de facto standard after half a year, with even OpenAI supporting it by the end of last year. Adding a memory layer on top of MCP comes at just the right time.
How It Compares to Existing Solutions

Objectively, OMP’s current version (v0.3) is still early-stage. It lacks Mem0’s mature graph memory, MemoryOS’s segment-page scheduling, and MIRIX’s finely tuned multimodal memory components. In terms of technical depth, it’s one or two tiers below academic solutions.
But it hits two key pain points:
First: a “protocol-first” stance. OMP doesn’t spend effort on fancy memory algorithms; instead, it locks down the “boring but critical” aspects—data formats, interface contracts, permission models. Such an approach often succeeds in engineering—Docker wasn’t the first container system, Kubernetes wasn’t the most powerful orchestrator, but both won through protocol and ecosystem.
Second: a “local-first” deployment model. All memory defaults to local SQLite + vector index, without forcing cloud storage. This is a key selling point for enterprise users and privacy-minded developers. Anthropic’s memory import tool, though opened to free users in March, still stores memories on Anthropic servers; ChatGPT is similar. OMP restores data ownership to users.
Its weaknesses are also clear:
- No forgetting mechanism. In the oft-cited Survey of Memory in AI, “forgetting” is listed as one of six atomic operations. OMP currently only supports simple expiration deletion, without semantic-level forgetting.
- No conflict handling. If ChatGPT writes “user likes Vim” and Cursor writes “user uses VSCode,” OMP doesn’t detect contradictions—it just stores both.
- Weak multimodal support. Currently text-only; images and code snippets must be manually serialized into strings.
Will It Be Adopted?
This is worth discussing.
Whether an open-source project succeeds isn’t just about code quality. MCP took off because Anthropic used it themselves, built it into Claude Desktop, and pushed it to the community—a protocol with heavyweight backing naturally gains momentum. OMP lacks such backing; it’s a community-driven project by author SMJAI, who has no notable prior works.
But it has a hidden advantage: it doesn’t require vendor approval. Since the protocol runs on the client side, connecting via MCP, theoretically as long as Claude Desktop and Cursor continue to support MCP, OMP can work. It doesn’t need Anthropic’s consent or OpenAI’s cooperation—only that users install a local service.
This “vendor bypass” design is reminiscent of early RSS—you didn’t need Twitter’s consent to use an RSS reader to subscribe to it (until Twitter shut RSS off). The trade-off is that if vendors tighten MCP compatibility, the ecosystem will be affected.
In the short term, OMP is most likely to spread first among developers. They are used to switching between multiple tools and feel the pain of “fragmented memory” most acutely. Developers who switch daily between Cursor for coding, Claude for documentation, and ChatGPT for brainstorming need a unified memory layer badly.
In the medium to long term, if one or two tool vendors actively adapt OMP, or it deeply integrates with a mainstream AI client framework (like Open WebUI or LibreChat), its momentum could increase rapidly.
Observations for Developers
If you plan to try it, a few points to note:
- MCP compatibility is a prerequisite. Confirm your client supports MCP; Claude Desktop and Cursor work out of the box, ChatGPT Desktop requires OMP’s proxy adapter.
- Default embedding model is small. It uses
all-MiniLM-L6-v2, 384 dimensions—fast but with average semantic precision. If you have large memory volume, consider switching tobge-largeor directly using OpenAI’s embedding API. - Permission model is still crude. Current version supports only “fully open” and “read-only” modes, without client-specific fine-grained permissions—use cautiously in production.
- Manual backups needed. SQLite database is stored at
~/.omp/memory.dbwith no built-in sync or backup.
For teams needing to switch between multiple models, the unified memory layer concept of OMP is worth tracking. OpenAI Hub now lets you call GPT, Claude, Gemini, DeepSeek, and other mainstream models with one key—solving the “unified call interface” problem. Adding OMP’s memory layer could theoretically unify both calling and context. Of course, that’s for later—OMP is still v0.3 and some distance from production readiness.
Memory Is AI’s Next Watershed
Looking at the bigger picture:
Over the past three years, the main competition in large models has been on two fronts: model capabilities themselves, and context window length. The former involves scaling parameters, RLHF, and reasoning; the latter has gone from 4K tokens to 200K, then to 1 million. Increasingly, practitioners realize stuffing everything into the context isn’t sustainable—high cost, high latency, diluted attention.
Memory is another path. It moves “letting the model remember more” from inference time to storage time—from one-off prompt engineering to persistent state management. This paradigm is closer to real software system design—databases and application layers should be separated.
A survey by teams from Chinese University of Hong Kong and University of Edinburgh last year categorized AI memory into parameterized and contextual types, then outlined six atomic operations: consolidate, update, index, forget, retrieve, compress. This theoretical framework is elegant, but engineering lacks a standard for implementation.
OMP may not be that standard, but it represents a direction: memory shouldn’t be a proprietary feature of one vendor; it should be infrastructure—like file systems, databases, message queues—defined by open protocols, implemented by different providers, with users voting via usage.
The road is long, but starting is better than keeping memory locked in black boxes.
References
- Open Memory Protocol – GitHub repository: project code, protocol specification, and reference implementation; the issues section has many community discussions worth reviewing
- In-depth analysis of ChatGPT and Claude’s memory mechanisms – Zhihu: detailed technical breakdown of the two leading AI memory designs
- Anthropic offering free memory import tool, reaching out to ChatGPT users – iThome: report from March on Anthropic’s release of memory import tools to free users, illustrating vendor moves in the memory feature space



