3. Cross-Session Tools (Single User)
3.1 claude-mem
Repo: github.com/thedotmack/claude-mem | Stars: ~88.7K (2026-07-27) | License: Apache-2.0
Hooks into Claude Code lifecycle events (SessionStart, PostToolUse, Stop, SessionEnd). Records observations during sessions, semantically compresses them using an LLM worker (Bun, port 37777), stores results in SQLite plus optional Chroma vector search. Injects relevant context back at session start or when the agent faces a relevant task.
Key differentiator: compression and relevance filtering, not transcript storage. Distilled semantic summaries, injected only when relevant. Local-first. Uses Claude Haiku for summarization by default; configurable to Gemini 2.5 Flash Lite for cost reduction (up to 86% cheaper for heavy users).
Installation:
/plugin marketplace add thedotmack/claude-mem
/plugin install claude-mem
# Restart Claude CodeObservation types captured:
| Type | When | Example |
|---|---|---|
DISCOVERY | Reading/exploring code | "Explored auth module, found JWT in validateToken()" |
CHANGE | File edits | "Modified session.middleware.ts: added refresh logic" |
FEATURE | New functionality | "Implemented OAuth2 flow in auth.service.ts" |
BUGFIX | Bug corrections | "Fixed null pointer in UserController.getById()" |
Progressive disclosure (3 layers to save tokens):
Layer 1: Search (50-100 tokens) → 5 relevant session summaries
Layer 2: Timeline (500-1000 tokens) → chronological observation list
Layer 3: Details (full context) → complete tool call + result~10x token reduction vs loading full session history.
Security warning: GET /api/settings returns API keys in plain text. Set host: "127.0.0.1" (not "0.0.0.0"). Never run on a shared machine.
Cost: ~$0.15 per 100 observations (AI summarization). Typical: $5-15/month for heavy users (100+ sessions). Switch to Gemini 2.5 Flash Lite to cut to ~$14/month at 400 sessions.
Hooks coexistence gotcha: claude-mem will overwrite your existing settings.json hooks arrays, not merge with them. Back up settings.json before installing, then manually verify both your existing hooks and the new claude-mem hooks are present.
Fail-open architecture (v9.1.0+): if the worker process is down, Claude Code continues normally; sessions simply aren't captured until the worker restarts.
Limitations: CLI only, no cloud sync.
Field audit: A four-and-a-half-month audit of one local claude-mem installation found six failures that produced no error, including incomplete project coverage, an empty semantic index, ineffective cost routing, and stalled reconciliation. See Persistent memory: the six failures that never raise an error. The audit covers one installation, not every claude-mem deployment.
3.2 agentmemory
Repo: github.com/rohitg00/agentmemory | Stars: 25,872 (2026-07-27, was 16,167 in May 2026) | License: Apache 2.0 | Language: TypeScript
Memory server running on port 3111 with a real-time viewer on port 3113. Zero external dependencies: SQLite plus the in-house iii engine. No Cloudflare, no Neo4j, no Docker.
Installation:
npm install -g @agentmemory/agentmemory
agentmemory
agentmemory connect claude-code # auto-wires 12 hooks into settings.jsonHybrid search (the key differentiator): BM25 + Vector + Graph fused via Reciprocal Rank Fusion. Four-tier memory consolidation with decay and auto-forget. The agentmemory connect claude-code command auto-wires 12 hooks (PostToolUse, SessionStart, SessionEnd, and others) into settings.json. This is the hook problem that ICM leaves unsolved.
Benchmarks (reproducible via eval/README.md, published corpus coding-agent-life-v1):
| System | R@5 (LongMemEval-S) | R@10 | MRR |
|---|---|---|---|
| agentmemory | 95.2% | 98.6% | 88.2% |
| BM25-only | 86.2% | 94.6% | 71.5% |
| mem0 (their harness) | 68.5% | - | - |
| Letta (their harness) | 83.2% | - | - |
The corpus and adapter code are published so numbers can be verified independently. This is more than most tools offer. Note that competitor comparisons (mem0, Letta) are run by the tool's author. Methodology is disclosed but not independently audited.
Token cost: ~170K tokens/year (~$10) vs ~650K for LLM-summarized summaries.
Multi-agent coordination: MCP + REST + leases + signals. Leases allow agents to lock a memory region while working on it. Signals allow agents to notify each other of state changes. "All agents share the same memory server."
For team use: the server listens on port 3111. If deployed on a shared host and exposed internally, all team members' agents point to the same instance. Not explicitly documented in the README for the team scenario, but the architecture supports it.
Agent support: Claude Code (native plugin + 12 hooks + MCP), Codex CLI (6 hooks + MCP), OpenCode (22 hooks), Cursor, Gemini CLI, Claude Desktop, Windsurf, Cline, Goose, Roo Code (MCP), Aider (REST API).
Honest caveats: Benchmarks use an in-house corpus alongside LongMemEval-S. The iii engine is not a third-party project. Production REX is limited given the tool's recent release.
3.3 ICM (Infinite Context Memory)
Install: brew tap rtk-ai/tap && brew install icm | Version: 0.10.49 (May 2026) | License: Source-Available (free for teams ≤20)
DB location (macOS): ~/Library/Application Support/dev.icm.icm/memories.db
ICM has three distinct operating modes that are easy to conflate:
MCP mode (icm init --mode mcp): Exposes 31 MCP tools via stdio. Every tool call costs 20-50 tokens. The default configuration. Claude calls icm_memory_recall at session start and icm_memory_store when triggered by the MCP instructions (5 standard triggers: resolved error, architecture decision, discovered preference, completed significant task, ~20 tool calls without a store).
Hook mode (icm init --mode hook): Direct CLI, ~30ms latency, zero token overhead. Extraction is rule-based, fires automatically every N tool calls (default 15). The hook file ships with ICM at ~/.claude/hooks/icm-post-tool.sh after installation, but must be manually registered in ~/.claude/settings.json to activate. If not in settings, it never fires.
To activate hook mode, add to ~/.claude/settings.json:
{
"hooks": {
"PostToolUse": [
{"matcher": "*", "hooks": [{"type": "command", "command": "~/.claude/hooks/icm-post-tool.sh"}]}
]
}
}This is the single highest-ROI configuration change for ICM users. Hook mode at zero tokens vs. 20-50 tokens per MCP call is the difference between memory that runs automatically and memory that only persists when Claude explicitly decides to call icm_memory_store.
Skills mode (icm init --mode skill): Installs /recall and /remember slash commands.
Two memory types:
Memories are episodic with temporal decay. Importance levels control decay rate: critical never decays, high decays slowly, medium follows normal decay, low fades quickly. Frequently recalled memories also decay more slowly. Consolidation triggers when a topic exceeds seven entries.
Memoirs are a permanent knowledge graph: concepts linked by typed relations (depends_on, contradicts, superseded_by, plus 6 others). Unlike memories, memoirs do not decay. This is the part of ICM that answers the "shared graph for multi-agent communication" use case: multiple agents writing to the same memoir create a persistent relationship map for the project.
icm memoir create -n "project-arch"
icm memoir add-concept -m "project-arch" -n "auth-service"
icm memoir add-concept -m "project-arch" -n "user-service"
icm memoir link -m "project-arch" --from "auth-service" --to "user-service" -r depends-on
icm memoir export -m "project-arch" -f asciiCross-tool reach: the same SQLite database is shared across 17 tools after icm init: Claude Code, Gemini CLI, Cursor, Codex, Windsurf, VS Code, Zed, Amp, Continue.dev, Aider, and others.
Benchmarks (vendor-claimed, unverified independently): 100% LongMemEval recall. 5% factual accuracy without ICM vs. 68% with ICM in their evaluation. 29-40% fewer turns in multi-session tests.
Team use: not designed for it. Each machine has its own local SQLite. No shared server mode exists in ICM.
3.4 Kairn
Repo: github.com/primeline-ai/kairn (renamed from kairn-ai/kairn) | Stars: 13 (2026-07-27) | License: MIT | Language: Python
Long-term project memory organized as a knowledge graph with automatic biological decay. Stale information expires on its own, preventing context pollution.
| Feature | doobidoo | Kairn |
|---|---|---|
| Storage model | Semantic embeddings | Knowledge graph |
| Memory decay | No | Yes (biological) |
| Typed relationships | Tags only | depends-on / resolves / causes |
| Auto-pruning stale info | No | Yes |
Solutions persist ~200 days; workarounds persist ~50 days. 18 MCP tools covering graph ops, project tracking, experience management, and an intelligence layer (full-text search, confidence routing, cross-workspace patterns).
When Kairn makes sense: long-running projects where workarounds from months ago become noise; when causality matters ("this breaks because of that"); teams wanting automatic knowledge hygiene without manual cleanup.
pip install kairn
# or: git clone https://github.com/kairn-ai/kairn && pip install -e .3.5 doobidoo mcp-memory-service
Repo: github.com/doobidoo/mcp-memory-service | Version: v10.0.2 | Stars: [UNVERIFIED, the doobidoo GitHub account no longer resolves as of the 2026-07-27 check (API returns 404). Last confirmed count: ~1.6K, May 2026. Verify before citing.] | License: MIT
Semantic memory with cross-session search and multi-client support (13+ AI tools). Moved from ChromaDB to SQLite-vec at v8.0.0 (breaking change). Default backend is sqlite_vec.
pip install mcp-memory-service
python -m mcp_memory_service.scripts.installation.install --quickKey difference from Serena: Serena uses key-value memory (requires knowing the key). doobidoo uses semantic search (retrieve_memory("what did we decide about auth?")); it finds by meaning.
Storage backends:
| Backend | Usage | Best for |
|---|---|---|
sqlite_vec (default) | Local, lightweight | Solo dev, single machine |
cloudflare | Cloud, multi-device sync | Team sharing, multi-device |
hybrid | Local fast + cloud background sync | Best of both |
Known issues (from GitHub history, May 2026):
SQLite concurrent access: When multiple clients access the same database simultaneously, the default busy_timeout=5000ms is too short. Produces intermittent errors in team scenarios. Fix: MCP_MEMORY_SQLITE_PRAGMAS=busy_timeout=15000,cache_size=20000 in your .env. The v8.9.0 installer sets this for new installs; upgrades require manual configuration.
ChromaDB migration (v8.0.0): Breaking change when upgrading from v7.x. Must migrate rather than upgrade directly.
Consolidation was blocked: The consolidation system was non-functional for a period due to missing update_memory() implementations. Fixed in October 2025 commits. If consolidation seems not to run, verify you are on a post-October 2025 build.
Backend mismatch: When MCP server and HTTP dashboard use different MCP_MEMORY_STORAGE_BACKEND values, they access different databases. Always verify /api/health/detailed shows the expected backend.
OAuth scope errors: Users report 403 Forbidden after OAuth flow due to token scope issues. OAuth is disabled by default (MCP_OAUTH_ENABLED=false).
Full documentation (team config): See Section 4.2
3.6 OpenMemory MCP
Repo: github.com/mem0ai/mem0 | Dashboard: http://localhost:3000
User-owned, local-first, private memory layer. Standardized 4-tool interface:
add_memoriessearch_memorylist_memoriesdelete_all_memories
Works across Claude Desktop, Cursor, Windsurf, and Cline. The design goal: a single portable personal memory layer across all AI tools. If you use multiple AI assistants, OpenMemory MCP provides shared persistence without per-tool setup.
The 4-tool surface is the correct architectural answer to the "53-tool memory MCP" problem (see agentmemory). Every tool schema loads into context each turn; a minimal surface costs minimal overhead.
3.7 File-Based Experience Playbooks (ORF, DiffMem)
The tools above store memory in a database (SQLite, vectors, a graph). A separate track keeps everything in plain files committed to Git, with no server and no embedding API. It trades semantic-vector recall for zero infrastructure and version-controllable memory. Two projects define this track, and they made opposite retrieval choices. That contrast is the most useful lesson in this whole section.
Open Reasoning Format (ORF), by Guillaume Laforge (Google Cloud DevRel, Apache Groovy co-founder). When an agent resolves a tricky problem, it writes a "playbook" as a Markdown file with YAML frontmatter under ./experiences/. A later session facing a similar task reloads that playbook and skips the dead ends already paid for once. Three parts: experiences/INDEX.md (a catalog the helper script auto-appends to, so it never drifts from the files), experiences/<domain>/EXP-<date>-<seq>.md (one playbook per file, five sections: Objective, The Trap, Abstracted Insight, Validated Path, Verification Checklist), and a manage-experience/ Agent Skill backed by a reference Python CLI.
Two hard constraints define ORF. First, zero server: no vector DB, no embedding call, just files that commit to version control. Second, on-demand loading via three-tier progressive disclosure: read the small index (~200 tokens), inspect the frontmatter descriptions of playbooks in the relevant category (~500 tokens), then load only the matching playbook (~800 tokens). This is the SKILL.md progressive-disclosure idea (the same three-layer pattern as §3.1 claude-mem) applied to a memory index. The schema's split between Abstracted Insight (the reusable principle) and Validated Path (the concrete fix that worked here) is deliberate: it is the mechanism meant to fight over-specific playbooks that never re-trigger.
ORF is inspired by Google's ReasoningBank (arXiv 2509.25140, "Scaling Agent Self-Evolving with Reasoning Memory"), which distills strategies from both successful and failed trajectories into structured memory items. The key divergence is the whole bet: ReasoningBank retrieves items by embedding similarity, ORF drops embeddings and retrieves by filename plus one-line frontmatter descriptions read by the LLM. The cost is retrieval quality. An LLM scanning short descriptions misses matches a vector index would catch, which Laforge flags himself as an open question. Maturity: a well-designed proof of concept, self-reported as not yet used in production, with benchmarks too small to mean anything (SWE-bench "66.7% to 100%" is three tasks, one flipped). See the full evaluation.
DiffMem, by Growth Kinetics: a git-native file memory that powers the "Annabelle" companion product. Same substrate as ORF (Markdown in a Git repo), opposite retrieval choice. DiffMem built a BM25 index, then deleted it (commit c4fe4a3) in favor of an LLM that shells the repo directly. One tool, run(command=...), behind a base-command whitelist (grep, git log/diff/blame/show), with output truncated and a short timeout. Instead of an index, the agent greps and blames the repo to answer "when was this last true." Storage isolates each user on an orphan Git branch mounted via git worktree, so multi-tenant isolation is a real Git guarantee rather than a folder convention. It is a case study, not a recommended tool: bus factor one (one author under seven aliases is 78% of commits), no LICENSE file, and the retrieval core is untested and being rewritten. If you borrow the shell-tool idea, one caveat: DiffMem validates only the base command before subprocess.run(shell=True), so $(...) inside an argument is an injection risk against untrusted input. See the full evaluation.
A fourth data point, private rather than shared. Executor (MIT, an integration governance layer, evaluated separately) runs three plain-file memory conventions in its own repository: MISTAKES.md, DESIRES.md, LEARNINGS.md, one per contributor-facing category. Same substrate as ORF and DiffMem, Markdown committed to a working tree, and the same three-part split ORF uses (a mistake, a missing capability, an environment discovery) collapsed into three files instead of one directory of playbooks. The one design choice that departs from both: all three are gitignored. ORF's playbooks, DiffMem's memory branch, and this guide's own /retex entries are all committed and shared across a team; Executor's three files are private working memory, visible only to the session or contributor that wrote them, never merged into the shared history. That is a real, deliberate trade-off between two things memory systems usually conflate: a durable record everyone can search, versus a low-friction scratchpad nobody has to curate for other readers. This is the fourth data point on the file-based track, and the only example here that chose the opposite default.
The lesson: match retrieval to query shape
DiffMem built BM25 and abandoned it. That reads at first like evidence against BM25. It is the opposite. DiffMem's queries are natural-language questions about people and events (a companion recalling "what did the user say about their sister in March"). That is a semantic query shape, where keyword ranking underperforms and an LLM reasoning over git blame wins. A coding-agent memory has the inverse query shape: error strings, stack traces, and code symbols, where term overlap is high and lexical ranking (BM25) is not just sufficient, it often beats embeddings while costing a fraction of an LLM loop. Same files, same Git, opposite retrieval, because the queries differ. Do not copy a tool's retrieval choice without first checking that your queries look like theirs.
Practitioner pattern: /retex + BM25 routing (this guide's own setup)
This repository runs the file-based playbook pattern in production, without ORF's CLI. A /retex slash command writes a structured lesson (What happened, Root cause, Prevention rule, severity, tags) to .claude/memories/retex-*.md, and a .claude/rules/retex-review.md rule surfaces the three most recent at session start plus warns inline when a work pattern matches a known prevention rule. It is the same station ORF formalized, with more operational plumbing (session-start surfacing, severity, a 50-entry cap, interactive capture) and one fewer disclosure tier.
The retrieval side is where the query-shape lesson pays off. A separate BM25 engine already powers a UserPromptSubmit skill-routing hook in a sibling project (the "smart-suggest-routing" pattern, documented at cc.bruniaux.com/guide/workflows/smart-suggest-routing), using BM25-plus with per-skill calibrated thresholds and zero external dependencies. Because retex queries are lexical (the error you just hit), the same engine pointed at a retex corpus is a stronger retrieval base than either ORF's LLM-reads-frontmatter or a vector index. The pragmatic hybrid: BM25 or a frontmatter-tag filter as the cheap default, and an LLM-agentic git-shell pass (DiffMem's idea) only when the lexical match misses.
3.8 Other Notable Tools
| Tool | Stars | Key feature | Limitation |
|---|---|---|---|
| claude-memory-compiler | ~1.1K | Human-readable daily logs + concept KB | PostSession only, no real-time |
| mcp-memory (Puliczek) | - | Cloudflare D1 + Vectorize, cross-device | Network latency per retrieval |
| Claude Continuity | - | Zero-config, full-state fidelity (not compression) | [UNVERIFIED: repo handle not confirmed] |
| MemPalace | ~52.6K [UNVERIFIED] | Wings/rooms/drawers hierarchical index | 96.6% R@5 claim [UNVERIFIED] |
| Memori | 15.7K (2026-07-27) | Memory neighborhoods, team design goal | CC adapter (memori-mcp) at 2 stars |
| codebase-memory-mcp | 2.5K | AST tree-sitter graph, 155 languages, structural | Code structure only, not episodic |
| Pieces for Developers | - | 9-month rolling capture, IDE + browser + terminal | Individual-only, commercial |
| claude-session-continuity-mcp | - | 24 tools, auto error-to-solution pipeline | [UNVERIFIED: not confirmed by internal sources] |
| Supermemory | [UNVERIFIED] | Free no-login MCP + self-hosted MIT binary; paid CC plugin | Self-host is single-tenant only; benchmarks self-reported |
Memori (MemoriLabs) deserves special attention: 15,671 stars (2026-07-27, up from 14,730 in May), LLM-agnostic, converts execution history into structured persistent state via a graph + vector hybrid. Team-scoped "memory neighborhoods" are a design goal, not an afterthought. The gap is the CC adapter, memori-mcp is a separate repo with 2 stars and sparse documentation. Worth tracking.
codebase-memory-mcp (DeusData) solves a different problem: not "what did we discuss" but "what is the structure of this codebase." Claims sub-millisecond queries. Can index the Linux kernel (~28M lines, 75K files) in ~3 minutes. Zero config Claude Code integration via MCP. The "99% fewer tokens" claim needs independent verification; the structural approach is sound.
Supermemory (supermemoryai) ships three distinct surfaces that are easy to conflate: the generic mcp.supermemory.ai/mcp MCP server is free and requires no login; the claude-supermemory Claude Code plugin (commands super-search, super-save, tools memory/recall/context) requires a Supermemory Pro plan starting at $19/month; and the self-hosted "Supermemory local" binary (MIT license) runs the same engine offline with a local embedding model. The company raised $29M in seed funding in October 2025, which explains why readers will ask about it. The self-hosted binary is explicitly single-tenant, one API key, no built-in multi-user (see §4.7). Benchmark claims are addressed in §9.
3.9 Master Comparison Table
| Tool | Storage | Search | Auto hooks | Team | Token cost/yr |
|---|---|---|---|---|---|
| claude-mem | SQLite + Chroma (opt) | Semantic | Yes (auto-register) | No | ~$60-180 |
| agentmemory | SQLite + iii engine | BM25+Vec+Graph RRF | Yes (12, auto-wired) | Shared server | ~$10 |
| ICM | SQLite | Vector + BM25 | Ships unwired | No (local only) | 20-50 t/call |
| Kairn | Knowledge graph | Full-text + semantic | No | No | Low |
| doobidoo | SQLite-vec / CF D1 | Semantic | No | CF backend required | Low |
| OpenMemory MCP | Local SQLite | Vector | No | No | Minimal |
| Supermemory | Cloud API / self-host binary | Semantic (vector) | No (MCP tool calls only) | Container tags, cloud-only, no self-host multi-user | Free (MCP) or $19/mo+ (CC plugin) |
| Memori | Graph + Vec hybrid | Graph + Vec | No | Design goal | - |
| codebase-memory-mcp | AST graph | Structural | No | Filesystem share | Minimal |
| Pieces | Local proprietary | ML | No | No (privacy-first) | Daemon overhead |
| ORF | Markdown + Git files | LLM reads frontmatter | Via SKILL.md | Git commit | Retrieval-only, no server |
| DiffMem | Markdown + Git (orphan branch) | LLM greps/blames repo | No | Orphan branch per user | LLM per read/write |