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.