Free forever, no credit card.Get Started for 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.

Get Started for Free

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

Get Started for Free

Free forever, no credit card.

Keep reading
Your Scheduled Agent Has No Past. Give It One: Seeding Agent Memory From Existing Conversations

Your Scheduled Agent Has No Past. Give It One: Seeding Agent Memory From Existing Conversations You have spent two years telling ChatGPT about your business. Your Claude chats hold the naming conventions, the deploy targets, the API versions, and the hundred little corrections you made along the way. Then you deploy a scheduled agent in n8n or a cron script, connect a memory layer, and watch it wake up knowing absolutely nothing. That empty start is not a bug. Memory systems only store what fl

Your Relevance AI Agent Has a Memory Feature. Your Scheduled Runs Still Start Blind.

You set a Relevance AI agent on a recurring schedule. Every morning at 7 it wakes up, pulls the new leads, scores them, and fires off the follow-ups. It works beautifully for a week. Then one morning it re-scores a lead it already contacted on Tuesday, sends a second follow-up to a prospect who said no, and completely misses the one who said "call me next week" because nobody told the agent that last week ended. The agent did not malfunction. It did not hallucinate. It just started blank, the s

Our AI Agent Forgets Everything Between Sessions. What Should We Put Underneath It?

Our AI Agent Forgets Everything Between Sessions. What Should We Put Underneath It? The short answer: an agent is stateless by default, so it forgets unless something outside it stores and returns context. What goes underneath is a memory layer: a store that saves what matters from each session and hands the right pieces back at the start of the next one. You have five real options: a plain database, a vector store, an embedded memory library like Mem0, Zep, Letta, or Cognee, a hosted memory se