Claude Mem

A memory and work-state layer that lets your coding agent pick up where the last session stopped

Persistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions. Works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode + More

No video published yet. The write-up below covers what the tool does and how to try it.

Category
Developer tools
Audience
Developers
Language
TypeScript
Licence
Apache-2.0

Published Updated

Claude Mem is a persistent memory layer for terminal coding agents: it records what the agent did during a session, compresses that record with a model, and injects the relevant parts back when you open the project again. It is for developers who live in Claude Code or a similar agent for days at a stretch and are tired of re-explaining the same codebase every morning. The repository is TypeScript, Apache-2.0 licensed, and GitHub's counters currently show about 95,400 stars and 8,450 forks, with the latest push dated the same day this entry was written.

What it does

The base idea is session continuity. Claude Mem captures what your agent does, compresses it, and feeds context back into later sessions. The project's own description says it works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot and OpenCode among others — that list is the authors' claim, not an independent compatibility matrix.

The newer piece, and the one the video focuses on, is a persistent work-state to-do list. Claude's models ship with no built-in to-do tool of their own, so the agent has nowhere durable to put "what I am in the middle of". Claude Mem adds that:

  • a write tool logs a task
  • a read tool shows what is still open
  • each task carries one of four statuses: todo, doing, done, or dropped
  • the list follows you into every worktree you open on the project

So the memory side answers "what did we decide last week" and the work-state side answers "what was I literally doing when the window closed".

How it works

Claude Mem runs as a worker process alongside your agent. When a worker-based session starts, work-state is loaded first, and memory then fills whatever room is left in the context window — a deliberate ordering, since open tasks are more useful than general recollection when space is tight. The project's server runtime does not do the work-state-first ordering yet.

Storage is local. The repository's topics name SQLite, Chroma and embeddings, which points at compressed session summaries indexed for retrieval rather than a full transcript replayed back at the model. The saved README is almost entirely a logo and a wall of translated-README links, so it does not spell out the schema or the retrieval tuning; treat the topic list as the best available hint and read the docs directory in the repo for detail.

Getting started

The code lives at github.com/thedotmack/claude-mem and is a normal clone-or-install project, not a release-only binary. It is TypeScript, so expect a JavaScript runtime; beyond that the project does not list operating systems, chips, memory or VRAM requirements in the material available here, so do not assume it has been exercised on your platform.

Cost is worth being precise about. The code itself is free and self-hosted under Apache-2.0, and the storage pieces named in the topics run on your own machine. But compression is done by a model, and the materials do not say which model or whose key pays for it — in practice that is either the agent session you are already paying for or a key you supply. Nothing here is free of model costs, and nothing here replaces a Claude Code subscription.

The operational requirement to plan for: the to-do lists need Claude Mem's worker process running. Start the worker, then open Claude Code, and your tasks come back.

When to use it / when not

The main catch is that dependency on the worker. If the worker is not up, the work-state list is not there, and the server runtime still does not prioritise work-state at session start. This is a young, fast-moving project — created in late August 2025 and pushed to constantly since — so expect the surface to shift.

Use it instead of a hand-maintained CLAUDE.md and a pile of scratch Markdown files when your sessions are long, your task list is real, and you keep losing the thread between worktrees. Don't use it if you work in short, self-contained sessions, if you cannot keep a background process alive, or if you need an exact audit trail — compressed summaries are summaries, and detail is lost by design.

Alternatives

The topic list name-checks the neighbourhood: mem0, OpenMemory and Supermemory are the general-purpose memory layers a reader may already know, and they are broader and less tied to coding agents. The zero-install alternative is the one most people use: paste a status note at the top of each session, or keep a to-do file in the repo and tell the agent to read it. That works; it just depends on you remembering to do it.

Take this seriously if an agent is your main editor and context loss is a daily tax rather than an occasional annoyance — the work-state list is the kind of small, boring plumbing that changes how a long project feels. If you mostly use an agent for one-off questions, or you are unwilling to run and babysit a worker process, the honest answer is that a text file in your repo gets you most of the way there.

More in Developer tools

All of Developer tools →