MemoryAtlas

Claude-Mem deep dive: what 87k stars of Claude Code memory actually costs you

Published Jun 30 · Updated Jul 15, 2026

Claude-Mem is a hook-based memory-compression layer for Claude Code and other agent CLIs: it captures what an agent does mid-session, compresses the result with an LLM, and re-injects the relevant slice into future sessions over a local SQLite and Chroma store. It is the most-starred tool in this catalog — 85,000-plus GitHub stars and over 68,000 npm downloads in the last month alone, with real GitHub-trending velocity behind the number rather than an inflated fork count. The thing worth knowing before you run the install command on a real project: the same lifecycle hooks that make capture effortless also write API keys, credentials, and proprietary source straight into a local store whose read and write API ships, by the maintainer's explicit choice, with no authentication at all.

How Claude-Mem turns a coding session into searchable memory

Five lifecycle hooks do the capturing: SessionStart injects prior context at the top of a new session, UserPromptSubmit and PostToolUse record what the agent does as it does it, and Summary and SessionEnd close the loop. None of this requires you to remember to save anything — that is the whole appeal. Behind the hooks sits a worker service, managed by Bun, where an AI pass (an "observer" agent, running on whatever LLM provider you configure) compresses raw activity into discrete observations — bugfix, discovery, decision, refactor, and so on — before writing them to a local SQLite database for structured storage and a Chroma vector database for semantic search, with FTS5 keyword search as a fallback when Chroma is unavailable. That compression step is the true cost to run: it is a separate, metered LLM call on its own provider account, on top of whatever model is driving your actual coding session, so a chatty session means real compression spend, not just a one-time infrastructure cost.

Retrieval is where the token-efficiency pitch lives. Rather than replaying full history, the mem-search skill exposes three progressively deeper tools — a compact search index running at roughly 50 to 100 tokens per result, a chronological timeline, and a get_observations call for full detail on IDs you have already filtered down to — which the vendor claims saves roughly 10x the tokens of naive replay. That figure is self-reported, not independently reproduced, so treat it as a vendor estimate rather than a measured benchmark.

Setup is genuinely low-friction: one command auto-detects which agent CLIs you have installed — Claude Code, Codex, Antigravity CLI, OpenCode, Hermes, Copilot, and OpenClaw gateways are all supported — and registers the hooks for each, with Bun and uv auto-installed if missing (Antigravity CLI replaced the Gemini CLI host integration in v13.10.0, July 2026, after Google sunset Gemini CLI's free tier; the separate Gemini LLM provider is unaffected). The whole thing also ships as a Claude Code plugin through the official marketplace. What is easy to miss during that install: it also stands up a local HTTP API, on port 37777 by default, that backs a web viewer and the MCP search tools — and that worker is the subject of two sections below.

FrameworkFamilyPricingSelf-hostLicense
Claude-Mem

thedotmack

Library / SDKFree + paidSelf-host: moderateApache-2.0

Who Claude-Mem is built for

The clearest fit is a developer who already lives inside Claude Code, or a sibling CLI agent, and wants project continuity — conventions, past decisions, dead ends already explored — without standing up any infrastructure or remembering to write anything down themselves. Because the same install path auto-detects Codex, Antigravity CLI, Hermes, Copilot, OpenCode, and OpenClaw gateways, it also fits someone who routinely switches between two or three of those CLI tools and wants one memory layer behind all of them rather than a separate setup per tool. It is explicitly not built for GUI-based IDEs: Cursor and Windsurf do not expose the lifecycle-hook interface claude-mem captures through, so the CLI-first scope is by design, not an oversight.

What teams are actually doing with it

The clearest signal that adoption is real and not just starred-and-forgotten is the download number sitting behind the stars: over 68,000 npm installs in the past 30 days, alongside 92-plus contributors and a release cadence that shipped 25 bug fixes in a single late-April push. Independent coverage backs the core pitch — a February 2026 plugin review credited it with solving "context amnesia" and found the roughly 10x token-efficiency claim directionally real in day-to-day use, letting developers ask natural-language questions like "what did we decide about error handling" and get an answer pulled from session history rather than re-explaining it. The same review is also where an honest edge shows up that the marketing copy skips: the experimental Endless Mode beta added 60 to 90 seconds of latency per tool invocation. A separate April 2026 third-party writeup, published by a competing memory vendor, pegged the project at 46,100 stars at the time and used it as a case study in why hook-based capture beats a static CLAUDE.md file for keeping context current — useful corroboration of the adoption numbers, even though, coming from a competitor's blog, it is not a neutral source.

The cost of convenience: what Claude-Mem captures, and who can read it

This is the section the install instructions will not walk you through. Two independent security audits, in February and March 2026 — one automated, one a manual community review — rated claude-mem's worker API HIGH risk: the HTTP service exposed more than 30 endpoints with no authentication at all, including one that returned Anthropic, Gemini, and OpenRouter API keys in cleartext, plus a path-traversal flaw in the smart_unfold and smart_outline MCP tools that could read arbitrary files such as SSH keys. Given that the entire point of the tool is to capture everything that happens in a coding session — which routinely includes credentials, internal business logic, and proprietary source — an unauthenticated local API is not a cosmetic gap.

What happened next is the more telling part. The maintainer closed the audit issue in April 2026 as "not a bug or feature request." Two weeks earlier, a release had actually shipped bearer-token authentication for the worker API — and it was reverted days later, not because the fix was wrong, but because it broke session-start context injection for everyone; when the rest of that release's 25 fixes were re-landed, the bearer-auth piece was deliberately left out. The changelog is candid about why: the worker binds to localhost only and restricts CORS to localhost origins, and in the maintainer's judgment a token "added friction for every internal client... with no real security benefit for single-user local deployments." That is a defensible position for a genuinely single-user laptop setup — but the same configuration that controls the worker's bind address can be pointed at 0.0.0.0, at which point the unprotected API becomes reachable from anywhere on the network, which is exactly the scenario the original audits flagged. It is also a position increasingly out of step with where memory-security research has landed: the emerging consensus is that security has to be designed in at the write and store stages of a memory system's lifecycle, not retrofitted afterward — and claude-mem has been capturing and storing session data, unauthenticated by default, since before that consensus existed. Path traversal and the request body-size limit were fixed and kept from that same release; authentication is the one piece that was not.

The other caveat is more mundane: the headline roughly-10x token-savings and compression-ratio numbers are the vendor's own measurements, not independently reproduced, so read them as directional rather than exact.

When to reach for something else

If you want memory you can audit and redact yourself, with no background network service running at all, Basic Memory's filesystem-markdown model is the more conservative default: everything lives in plain, git-diffable markdown files on local disk, served only through MCP tool calls rather than a standing HTTP worker, so there is no equivalent unauthenticated port to worry about. Its own default install does reach out to an external telemetry endpoint, so "local-first" still needs a one-line opt-out — but the threat model is narrower than running a local web server with broad read access to captured session data.

If your team needs memory that is shared and versioned across people, not just persisted across your own sessions, ByteRover's Git-backed approach is closer to what you actually want: decisions land as commits you can review, not as an accumulating SQLite table, and it adds an aging and decay layer over time — a problem claude-mem's compression does not solve, since compression shrinks the token footprint of what is stored without resolving contradictions or expiring stale facts.

And if your stack is Cursor or Windsurf rather than a CLI agent, claude-mem is the wrong tool regardless of any of the above: it has no path into a GUI IDE that does not expose lifecycle hooks, full stop.

Further reading

Primary sources and recent material on Claude-Mem, newest first.

Install claude-mem if you live in Claude Code or a sibling CLI agent and want session continuity with zero ceremony — the adoption numbers and the independent reviews back up that it genuinely works. Before you point it at a repository that has live credentials or client code in context, though, make a deliberate call on the worker's exposure: keep it bound to localhost and accept the maintainer's no-auth-by-design stance, or pick Basic Memory or ByteRover if you would rather not run an unauthenticated network service on your machine at all.