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.
- Source repo
- CaviraOSS/LongMemory
- Stars
- ★ 4.5k
- Last updated
- today
- License
- Apache-2.0
- Primary language
- TypeScript
- FA score
- 41/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformClaude Code · OpenAI API
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A developer building a chatbot wants to remember user preferences persistently, such as 'user prefers dark mode'.
- Not a fit if
- Users wanting a zero-setup tool with no server or database to run
- Teams relying on a hosted platform's native memory instead of self-hosting
- Source review
- 41/100 · Major gaps 2 safety controls not found
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.
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.
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 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.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| OpenMemory Cognitive Memory Engine This agent | 41 · Major gaps | Library / SDKFree + model costs | ★ 4.5k | today | TypeScript | Claude Code · OpenAI API |
| Remnic Agent Memory | 85 · Good | CLIFree + model costs | ★ 227 | 3d ago | TypeScript | ChatGPT · Codex · Claude Code · OpenAI API |
| Remembra Relay | 72 · Some gaps | Agent plugin / skillFreemium | ★ 16 | 7d ago | Python | Claude Code |
| TeleMem: Long-Term and Multimodal Memory for Agentic AI | 57 · Major gaps | Library / SDKFree + model costs | ★ 494 | 6d ago | Python | OpenAI API |
How does FollowAgents rate this agent?
Why each dimension lost points
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.
- Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
- Not found in source: rollback or recovery pathBack up first, or work on a git branch or snapshot, so its changes can be undone.
- 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.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v1.3.0 Beta v1.3.0
Release notes excerpt
Changelog api simplification - python sdk: simplified to zero-config Memory() api matching javascript - from openmemory.client import Memory → mem = Memory() - works out of the box with sensible defaults (in-memory sqlite, fast tier, synthetic embeddings) - optional configuration via environment variables or constructor - breaking change: moved from OpenMemory class to Memory class benchmark suite rewrite - implemented comprehensive benchmark suite in temp/benchmarks/ - typescript-based using tsx for execution …View on GitHub ↗ -
Release notes excerpt
1.2.3 - 2025-12-14 Added - Temporal Filtering: Enables precise time-based memory retrieval - Added startTime and endTime filters to query method across Backend, JS SDK, and Python SDK. - Allows filtering memories by creation time range. - Fully integrated into hsg_query logic. Fixed - JavaScript SDK Types: Fixed IngestURLResult import error and v.v property access bug in VectorStore integration. - Python SDK Filtering: Fixed missing implementation of user_id and temporal filters in hsg_query loop. What's Changed …View on GitHub ↗ -
Release notes excerpt
Fixed - MCP Server Path Resolution: Fixed ENOENT error in stdio mode (Claude Desktop) - Enforced absolute path resolution for SQLite database - Ensures correct data directory creation regardless of working directory - Critical fix for local desktop client integration - VectorStore Refactor: Fixed build regressions in backend - Migrated deprecated q vector operations to VectorStore interface - Fixed users.ts, memory.ts, graph.ts, mcp.ts, and decay.ts - Removed partial SQL updates in favor of unified vector store methods Added …View on GitHub ↗