Full Pro free for 7 days, no credit card. Start free →
← All posts
September 28, 2026 · 6 min read

CLAUDE.md Is Not a Memory System: 6 Coding-Agent Memory Layers, Compared

CLAUDE.md Is Not a Memory System: 6 Coding-Agent Memory Layers, Compared Somewhere on your machine there is a markdown file that started as a clean list of project rules and grew into a second job. Every session reads the entire thing, billed by the token. Outdated instructions sit next to new ones with no referee. And when your scheduled agent wakes up on another machine, none of it helps. CLAUDE.md is a document, not a memory system. A memory system keeps decisions, task state, and learnings

CLAUDE.md Is Not a Memory System: 6 Coding-Agent Memory Layers, Compared

Somewhere on your machine there is a markdown file that started as a clean list of project rules and grew into a second job. Every session reads the entire thing, billed by the token. Outdated instructions sit next to new ones with no referee. And when your scheduled agent wakes up on another machine, none of it helps.

CLAUDE.md is a document, not a memory system. A memory system keeps decisions, task state, and learnings alive between sessions and compactions, and gives each session only the slice it needs. Six real ones shipping now, with the honest tradeoffs.

1. wasurezu (Kusabi): built to survive the compact button

Claude Code compacts long sessions; sessions crash; the next one starts cold and you re-explain yesterday's decision. wasurezu (watchout/agent-memory, public alias Kusabi) is an MCP server aimed at that: a structured decision log with supersede chains, cross-session task state, and knowledge retrieval in SQLite or Postgres. Its tools live under the mcp__wasurezu__* namespace.

It fits when the compact button is the main enemy. The caveat is age: v0.3.0, self-described as an internal-use snapshot, with the API free to change before a public alpha. You would be adopting it mid-transition.

2. archeus: your sessions, finally findable

Half the forgetting problem is not storage, it is retrieval: old sessions are unfindable, so every launch starts from a guess. archeus (babarmuhammad/archeus) is a Python memory and workspace layer pairing per-project semantic memory of the codebase with a session launcher. Pick the project, see every session, launch with the model, effort, permissions, and context you meant; each session gets only the relevant slice of memory.

Setup is pipx install archeus on Python 3.10+ with the Claude Code CLI on PATH; it reuses your Claude Code auth, ships zero runtime dependencies, and comes as a terminal UI, a desktop GUI, and a Claude Code plugin. Note the shape: Claude Code is the agent it drives today. Broader support is a goal, not a feature yet.

3. ReflectLog: two ways to find every memory

Most memory tools retrieve one way: meaning, or keyword. ReflectLog (iworkforces/reflectlog) does both per project: semantic similarity over USearch plus exact phrase matching over Tantivy, fused with reciprocal rank fusion, recency-aware scoring so contradictions settle toward the newest, and an LLM-based step that detects when a memory has been superseded. Multiple transports (stdio, HTTP, SSE, streamable HTTP) if you need them.

The price of that quality is setup: clone, uv sync, a .env file, and an OpenRouter key for the smarter parts. It is real infrastructure, not a one-liner. Worth it when your memories need to be findable by what they mean and by exact phrase.

4. Runtime Memory: memories graded on their record

Runtime Memory (runtimenoteslabs/memory-layer) treats memories like staff: the ones that help get promoted. It stores knowledge from your coding sessions and records outcomes, boosting memories that worked (+0.2) and penalizing ones that failed (-0.3), so retrieval favors memories with a good track record and stops serving ones that keep failing.

pip install runtime-memory (not the unrelated memory-layer package on PyPI) gets you the Python SDK, a mem CLI, and a web UI; the first run pulls a roughly 100MB embedding model once and caches it. The boundary is the machine: it is a local library, so its memory does not travel to other machines or serve agents running elsewhere.

5. Friday: one local brain for every editor

Friday (friday-memory/friday) ships v1.0 as the self-hosted answer: Mem0 plus ChromaDB plus Neo4j behind a single MCP server, stood up with one Docker Compose command. Cursor, Claude Code, VS Code, and Antigravity all point at the same central brain, and a built-in graph visualizer lets you inspect what it knows.

The appeal is consolidation: every editor on your machine shares one memory. The bill is operations: three stores, a compose file, backups, upgrades, all yours. A managed cloud version is on the roadmap, not in the world yet. Pick it if you run infrastructure anyway and want one local memory.

6. Vilix AI: the managed, multi-tool memory

The last option is the one that requires no server at all. Vilix AI is cloud-hosted, so there is nothing to install or operate. Each AI tool, Claude, Codex, Cursor, OpenClaw, Hermes, and other MCP-compatible clients, connects to your Vilix AI account over MCP, and the same memory follows everywhere. Agents save full exchanges with save_turn (full conversations, not just extracted facts); the next session retrieves what is relevant semantically, with keyword search alongside for exact strings. Projects, tasks, and rules are manageable from any connected AI or the dashboard at app.vilix.ai; conflicts resolve last-write-wins, stated up front; your data exports in a portable format anytime and deletes instantly. Free plan forever, with a 7-day Pro trial that needs no credit card.

It is the right shape when your agents span tools and devices, especially scheduled or background agents that never touch your hardware. The honest limit: cloud-only. If your threat model keeps data on your hardware, choose a local option above.

Side-by-side

What you run Memory travels Full conversation kept
wasurezu An MCP server Via MCP Task state + learnings
archeus A Python install Claude Code-first Session history
ReflectLog A server + OpenRouter key Via MCP Project memories
Runtime Memory A Python library One machine What you store
Friday A Docker stack Via MCP Sessions + graph
Vilix AI Nothing Every tool, every device Full exchanges

FAQ

Why not just keep everything in CLAUDE.md? Because it scales badly: the agent reads and pays for the whole file every run, stale and fresh instructions coexist with no referee, and it cannot serve an agent running on another machine. A memory layer retrieves only the relevant slice and can be shared.

Do these replace my context window? No. They sit underneath it. The agent's context window is still where thinking happens; the memory layer decides what gets loaded into it each session.

Which option fits a scheduled agent on a cron job? The scheduled agent is the hardest case for local options: it runs on machines you may not own, in bursts, with no persistent home. That points at the managed layer (Vilix AI) or a server you already operate (Friday or ReflectLog over HTTP). The local libraries and per-machine stores do not fit a workload with no machine to live on.

Choose by where your agents run

The whole decision in one line: single machine, single tool, the local options give privacy and control. Multiple tools and devices, agents on schedules, zero infrastructure: Vilix AI is the cloud version of the same idea, free plan forever, 7-day Pro trial with no card. The file full of rules was never the memory system. Now you have six.

Try Vilix Pro free for 7 days

Persistent memory across ChatGPT, Claude, and the AI tools you already use in Vilix AI.

Get started free
Keep reading
Your Agent Believes Everything the Internet Tells It. That Is the Attack.

Every part of your automation stack got a security review. The API keys are in a vault. The webhooks are signed. The n8n instance sits behind auth. And then, every night, your scheduled agent reads a pile of untrusted content — inboxes, ticket queues, vendor portals — and writes its conclusions into long-term memory. Nobody reviewed that part. Nobody watches it. That is the hole. It has a name: memory poisoning. Unlike a prompt injection, which dies when the run ends, a poisoned memory persists

One Agent, Many Clients: Stopping Scheduled Agent Memory From Leaking Across Users

One Agent, Many Clients: Stopping Scheduled Agent Memory From Leaking Across Users Agencies and solo operators love the economics of scheduled agents: one workflow, one schedule, many clients served. A Monday-morning briefing agent that summarizes the weekend's support tickets. A nightly lead-research agent that enriches new signups. Build it once, aim it at every client. There is a catch that does not show up in the demo. A scheduled agent with memory serves whoever its memory serves. The mom

Vilix AI vs Zep: Which Memory Layer Fits Your AI Agents?

Vilix AI vs Zep: Which Memory Layer Fits Your AI Agents? The short answer: Vilix AI and Zep both give AI agents a memory, but they sell to different people. Zep is a temporal knowledge-graph memory you wire into agent software you build, with best-in-class "what was true when" reasoning, starting at $125/mo for production. Vilix AI is a hosted shared memory layer you attach to tools you didn't build (Claude, Codex, n8n agents, headless runners), one memory across all of them, with full conversa