OpenMemory Cognitive Memory Engine
A self-hosted cognitive memory engine for LLMs and agents, offering real long-term memory with a local-first design, Python and Node support.
Evidence shows: README emphasizes local-first, self-hosted, but no permission model details; MCP tests show tenant isolation, but no user confirmation mechanism; data flow transparency partially, README mentions explainable traces, but not detailed data flow; sensitive data handling, SECURITY.md advises avoiding storing sensitive personal info, but no concrete measures like encryption; dependency security, SECURITY.md advises regular updates and scanning, but no specific dependency list or vulnerability scan results; external effects, connectors require tokens, but no scope explanation; rollback, no rollback mechanism mentioned; source attribution, README and LICENSE provide copyright and contributor info, but publisher unverified. Deductions: lack of user confirmation, rollback, unclear permission model, dependency security measures only advisory.
Evidence shows: README and test files are largely consistent in feature description, but README states project is being rewritten, may introduce inconsistency; dependency availability, README provides PyPI and npm packages, but no version compatibility info; failure messages, tests show error handling, but no user-friendly error messages. Deductions: rewrite status may cause inconsistency, dependency availability not fully explained, failure messages not detailed.
Evidence shows: README identifies target audience (LLM app developers) and multiple usage scenarios (SDK, server, MCP); capability boundaries, README lists features, but no explicit limits; trigger precision, MCP tool names are clear, but no trigger conditions; environment fit, supports multiple deployment modes (local, Docker, cloud), but no detailed configuration. Deductions: capability boundaries and trigger precision insufficiently described.
Evidence shows: README structure is clear, with installation, usage, architecture sections; install notes provide pip and npm commands; naming stability, package and tool names consistent in README, but project in rewrite may change; examples and FAQ, README provides multiple examples, but no FAQ; known limitations, README mentions rewrite, but no other limitations; license is Apache-2.0, but copyright year 2025; versioning changelog missing; maintenance responsibility, README provides contribution guide, but no explicit maintainers. Deductions: missing FAQ, changelog, incomplete known limitations.
Evidence shows: output usability, README provides clear API examples and MCP tools; marginal value, compares with RAG, emphasizes unique features; cost benefit, local-first, self-hosted, reduces cloud costs. Deductions: no performance benchmarks or real-world use cases.
Evidence shows: some feature claims in README are supported by tests (e.g., MCP tenant isolation test), but not all claims; cross-source corroboration, test files partially align with README, but no external verification; fact-inference separation, README distinguishes feature descriptions and architecture diagram, but not explicitly labeled. Deductions: test coverage incomplete, lack of external verification.
- Project is under rewrite, expect breaking changes and potential bugs; use with caution in production.
- Publisher identity unverified; dependency security measures are only advisory, no specific vulnerability scan results provided.
- Lack of user confirmation and rollback mechanisms; permission model unclear; sensitive data handling lacks concrete encryption measures.
What does this agent do, and when should you use it?
OpenMemory is a self-hosted cognitive memory engine that provides real long-term memory for LLMs and AI agents, going beyond simple RAG or vector databases. It features multi-sector memory (episodic, semantic, procedural, emotional, reflective), a temporal knowledge graph, composite scoring, decay mechanisms, and explainable recall traces. The project offers Python and Node SDKs, a backend server with dashboard and MCP, a CLI tool, and a VS Code extension, along with connectors to ingest data from GitHub, Notion, Google Drive, and more. The project is currently being rewritten, so expect breaking changes.
OpenMemory provides persistent memory for LLM applications. It offers Memory class with async methods add, search, delete, and supports user-scoped memory via user_id. It classifies memories into sectors (episodic, semantic, procedural, emotional, reflective), maintains a temporal knowledge graph with valid_from/valid_to windows, and uses composite scoring (salience, recency, coactivation) for recall. It includes a CLI (opm), an MCP server exposed at /mcp over HTTP, and integrations with LangChain, CrewAI, AutoGen, and Streamlit. Connectors allow ingesting data from external sources like GitHub.
- A developer building a chatbot wants to remember user preferences persistently, such as 'user prefers dark mode'.
- A data scientist using LangChain wants to add persistent memory to their conversation chains without deploying extra services.
- An organization needs multi-user memory isolation with a central dashboard and HTTP API for their internal tools.
- A developer using Claude Code or Cursor wants to let their IDE assistant query and store code-related memories via MCP.
- A personal knowledge management user imports data from Notion and Google Drive, and uses temporal queries to track fact changes over time.
What are this agent's strengths and limitations?
- Multi-sector memory classification goes beyond simple vector search, distinguishing facts, events, preferences, etc.
- Temporal knowledge graph enables point-in-time queries and auto-closes outdated facts.
- Self-hosted and local-first with SQLite/Postgres, avoiding vendor lock-in.
- Explainable recall traces show which nodes were used and why.
- Supports multiple embedding providers (OpenAI, Gemini, Ollama) and a synthetic fallback.
- Project is in active rewrite, with breaking changes and potential bugs.
- Deployment requires setting up multiple components (Python/Node, Docker, backend server), which can be complex.
- No native integration with ChatGPT as a platform; only via OpenAI API adapter.
- Migration tool only supports specific sources (Mem0, Zep, Supermemory), not all existing memory systems.
- While self-hosted ensures data ownership, encryption at rest is not yet implemented (on roadmap).
How do you install or deploy this agent?
Python SDK: pip install openmemory-py. Node SDK: npm install openmemory-js. Backend server: clone the repo, copy .env.example to .env, then inside packages/openmemory-js run npm install and npm run dev (default port 8080). Docker: docker compose up --build -d, optionally with UI: docker compose --profile ui up --build -d.
How do you use this agent?
Python: from openmemory.client import Memory; mem = Memory(); await mem.add("user prefers dark mode", user_id="u1"); results = await mem.search("preferences", user_id="u1"). Node: const { Memory } = require("openmemory-js"); const mem = new Memory(); await mem.add("user likes spicy food", { user_id: "u1" }); const results = await mem.search("food?", { user_id: "u1" }). CLI: start server with opm serve, then add: opm add "user prefers dark mode" --user u1 --tags prefs, query: opm query "preferences" --user u1.
How does this agent compare with similar options?
Compared to memory systems like Mem0, Zep, or Supermemory, OpenMemory emphasizes multi-sector memory and explainability rather than just vector retrieval. The code examples show its difference from LangChain with Pinecone, offering a more lightweight, local-first approach.