What's the Difference Between Open Engrams and Model-Native Memory?
Model-native memory is locked to the vendor that created it. Open engrams are a portable, developer-controlled memory format that any model in your stack can read. ChatGPT, Claude, and Gemini each have their own built-in memory systems — useful within their own interfaces, but siloed: what ChatGPT learns about you never reaches Claude, and vice versa. Open engrams (the format used by PLUR) are structured memory units stored locally in a format you own, so any model, tool, or agent workflow can read and write the same memory store without crossing a vendor boundary.
The Problem: Your Memory Is Fragmented Across Vendors
If you use multiple AI tools — and most developers do — your context is split across closed silos:
- ChatGPT Memory stores up to ~1,500 words of extracted facts tied to your OpenAI account. When you open Claude or Cursor to continue the same project, it knows nothing about you (source).
- Gemini's memory doesn't sync to ChatGPT or Claude (source).
- Claude's memory for managed agents is in public beta — cross-session recall within Claude, not portable outside it (source).
This is a structural problem: every vendor solves memory for their own surface, not for your workflow. When you run a multi-agent pipeline that touches Claude Code, a Hermes agent, and a custom CLI tool, there is no shared memory layer unless you build one.
What Is Model-Native Memory?
Model-native memory is memory managed and controlled by the model vendor:
| Feature | Typical model-native memory |
|---|---|
| Storage location | Vendor cloud |
| Who controls what's stored | The model (implicit extraction) |
| Portability | Locked to one vendor |
| Auditability | Limited — you can view some, rarely edit raw data |
| API access | Proprietary or none |
| Works across models | No |
ChatGPT Memory uses implicit extraction: the model decides what to save from your conversations. You can view and delete memories, but you can't query them programmatically or export them to another tool in a structured format (source). Claude's managed-agent memory is similar: optimized for recall within Claude, not designed to be read by a Cursor plugin or a Python script.
This is appropriate for consumer chat use cases. It is not appropriate for agent workflows where memory needs to cross tool and model boundaries.
What Are Open Engrams?
An engram is a single, structured unit of memory: a statement, a type, a confidence score, and metadata — stored in a format you own.
{
"statement": "Use snake_case for all database column names in this project.",
"type": "architectural",
"domain": "conventions",
"confidence": 0.95
}
The open engram format (used by PLUR) is:
| Feature | Open engrams |
|---|---|
| Storage location | Local SQLite on your machine |
| Who controls what's stored | You or your agent, explicitly |
| Portability | Any MCP-compatible model or tool |
| Auditability | Full — inspect, edit, or delete any engram |
| API access | MCP tools: plur_learn, plur_recall, plur_recall_hybrid
|
| Works across models | Yes — Claude, Cursor, Hermes, custom agents |
Because engrams are stored in a local SQLite file and accessed via the Model Context Protocol, any model in your stack can read the same memory. Claude Code, a Hermes agent, and a custom Python script all see the same engram store.
Side-by-Side Comparison
| Dimension | Model-native memory | Open engrams (PLUR) |
|---|---|---|
| Portability | Vendor-locked | Any MCP client |
| Transparency | Opaque synthesis | Every engram readable |
| Control | Implicit background extraction | Explicit, developer-driven |
| Auditability | View + delete (limited) | Full CRUD on every record |
| Staleness handling | Contradictions accumulate silently | Confidence decay + retirement |
| Infrastructure | Vendor cloud | Local-first, you own the data |
| Cross-model | No | Yes |
| Works for agent workflows | Limited | Designed for it |
They Do Different Jobs — Use Both
Model-native memory and open engrams are not in competition. They target different jobs:
- Model-native memory is best for conversational continuity within one vendor's surface — remembering your name, your preferences for that product, the last project you discussed.
- Open engrams are best for programmable, portable recall across agent workflows — conventions, corrections, project context, facts that need to survive across models, tools, and sessions.
The question to ask is: who needs to read this memory? If the answer is "just ChatGPT," model-native memory is fine. If the answer is "my Claude Code session, my Hermes agent, and my custom script," you need open engrams.
Getting Started
PLUR is an open-source memory layer that implements the open engram format. Install the MCP server and your memory is instantly available to any MCP-compatible client:
npx @plur-ai/mcp init
After setup, call plur_learn to write an engram and plur_recall or plur_recall_hybrid to retrieve it — from any model in your stack.
FAQ
Can I use open engrams alongside ChatGPT or Claude memory?
Yes. They operate at different layers. Model-native memory handles session context within a vendor's product; open engrams handle portable, cross-model recall. Running both is the recommended setup for developers who use multiple AI tools.
Is the open engram format a specification or a product?
Both. The open engram format is a specification for how memory units are structured. PLUR is an open-source implementation of that specification. The goal is to prevent vendor lock-in at the memory layer the same way SQLite prevents vendor lock-in at the storage layer.
Do I have to choose one model to use PLUR?
No. PLUR connects to any MCP-compatible client — Claude Code, Cursor, Hermes agents, and custom applications. You write to one engram store; every tool reads from it.
