kaeru gives Claude Code and Codex graph-based memory instead of CLAUDE.md

⚡ The gist in 5 seconds

• The Lamantin AI team has released kaeru — a local MCP server that keeps an AI agent's memory across sessions.
• It connects to Claude Code, Codex, Cursor, OpenCode and other MCP clients; the data stays on your machine, and for a team you can run a shared server.
• The agent decides on its own what to record, and at startup it asks for a project summary — there's no "remember everything" button.

🔍 What happened

The author of the article on Habr works at Lamantin AI — the very team behind kaeru. He went through his own logs and noticed something unpleasant: the agent keeps re-asking about things it has already recorded. Hence the tool — an MCP server that lives on your machine and stores the agent's memory as a graph.

What sits in the nodes: observations, decisions, tasks with deadlines, hypotheses along with the results of their verification, and saved documents. An example observation from the article — "the client's files come in cp1251." Every record has a change history, and every link has meaning: this decision grew out of that observation, this record supersedes that one, this check disproved that hypothesis. The agent pulls the whole chain from observation to decision, and the author calls it preserved reasoning.

The mechanics are simple. When connected via MCP, the server hands over a short instruction, and then the agent writes to memory as it works. There's also a separate rule type — a record marked as a persistent project constraint — and a reminder that pops up from a certain date. Records are organized by project: the author has more than thirty in one storage, and the agent only sees the one it opened. kaeru handles storage and summaries, and the sources are on GitHub.

In a separate section, the author takes aim at rule files. CLAUDE.md, AGENTS.md,.cursorrules work for a month, then the trouble starts: the file grows, deleting things feels risky, and the agent believes yesterday's rule just as much as the one repealed last month. And the main thing — the file contains the "what" but not the "why." ADRs cover the "why," but only for major decisions. Trackers like beads hold the plan, not what was figured out along the way.

🧠 Our take

It looks like this problem has been brewing for more than one author. Agents live long enough to hit the context window and dialogue compression: half of what was discussed turns into a couple of lines of summary. While the industry argues about window size, this project suggests looking not at volume but at structure — what exactly is worth remembering. Our assessment: this is a more honest framing of the task than another hundred thousand tokens.

What it changes. A rule file and ADRs are about durable agreements that go through review and live in git. But between commits there's a working layer: hypotheses, checks, quirks of test environments. Dragging it into the repository means polluting history; not recording it means losing it. We believe this gap was the real pain point, not "too little context."

Who wins. Those who juggle several projects at once and re-brief the agent from scratch every day. Who loses — or rather, who stays put: fans of a single rule file in git. They value reproducibility and review more, and that's a fair argument. What bothers me here is something else: local memory without review is yet another source of truth that no one has verified.

⚠️ What we don't know

The article contains not a single number: how many tokens the summary saves, how fast it's assembled, how often the agent writes junk, and who cleans it up. This is a developer's story about their own product, i.e. not an independent test, and we see no second opinion. It's worth checking yourself: open the sources on GitHub, spin up the server on your own project, and see what the agent recorded in a day. Also check how the memory behaves on a large graph — the text says nothing about that.

Prediction: by the end of the quarter, at least one open-source analog with graph memory on top of MCP will appear — the scheme is too simple not to be copied.

Disclaimer: the article was written by the kaeru developer at Lamantin AI; it's a story about their own product, not an independent review.

Source: Habr — it also has links to the sources and a walkthrough of memory workflows over the course of a day.