Every Claude Code Memory System Compared (So You Don't Have To)

The presenter opens by acknowledging the overwhelming number of Claude Code memory tools available and reframes them not as competitors but as six distinct levels that address different stages of memory complexity. The core insight underpinning all levels is the same question: how does Claude pull the right context at the right time? Every system differs only in where memory is stored and how it is retrieved.

Level one covers Claude's native built-in tools: claude.md and the auto-memory system that generates memory.md files. The presenter warns against stuffing too much into claude.md, recommending a 200-line cap with external files referenced as needed to avoid 'context rot,' the degradation of recall as context windows fill up. He also references a leaked internal Anthropic framework called 'Chyros,' an unreleased always-on daemon designed to continuously watch projects and consolidate memories automatically.

Level two builds on level one by introducing a structured memory prompt system inspired by Pavl Hurin and implemented by John Connelly. This adds a formal directory structure with general, domain-specific, and tool-specific markdown files, plus a session-start hook that auto-injects the memory index into every new Claude session. The presenter demonstrates this live, showing how it reorganizes existing memory files, deletes empty ones, resolves open threads, and adds cross-references. He also highlights the potential for team-sharing of domain memory files.

Level three addresses the scaling limits of keyword search by introducing MemSearch, a plugin from Zillus (creators of a popular open-source vector database) that ports OpenClaw's memory architecture into Claude Code. It uses semantic vector search to find relevant memories by meaning rather than keyword, and automatically injects the top three matches into every prompt via a user-prompt-submit hook. The presenter also briefly covers Claude Mem as an alternative, noting it uses MCP tools requiring Claude to actively call search rather than injecting automatically, and stores data in a non-readable format.

Level four introduces Mem Palace, a local RAG system using verbatim storage across an SQL database and ChromaDB. It uses an ancient memory palace structure (wings, rooms, closets, drawers) and a symbolic index language for ultra-fast retrieval (reportedly 42ms). Nothing is summarized, so nothing is theoretically lost, and it claims the highest published benchmark score of any memory system. It operates via silent background hooks on session end and pre-compaction events.

Level five shifts entirely away from conversation recall toward building an interconnected knowledge base. The presenter covers Andrej Karpathy's LLM Wiki pattern, which uses a raw folder for source documents and a wiki folder owned entirely by Claude, visualized through Obsidian. He also covers Recall, a hosted service that automates the same process with a browser extension and MCP access, though he raises concerns about data ownership and its orientation toward content consumption rather than operational memory. LightRAG is mentioned as an enterprise-grade but overkill alternative.

Level six, called Open Brain by Nate Jones, is the only cross-tool memory layer covered, storing memories in a user-owned Postgres database on Supabase accessible by Claude Code, ChatGPT, Claude Desktop, and Cursor simultaneously. It uses an MCP server and Supabase edge functions as a universal front door. Mem0 is mentioned as a more production-ready hosted alternative for developers shipping AI products, though with the trade-off of data living on external servers.

The presenter concludes with a practical decision framework: beginners should use level one, intermediate users should add level two and stop there, and only those with months of accumulated context or multi-tool workflows should consider levels three through six. He personally implements up to level three in his own Agentic OS.