claude-mem vs repowise: what do they actually do?

They do not replace each other. The useful question is not "which one" but "does my agent forget what we did, or does it not understand where it is treading?"

Capture. Five lifecycle hooks do the work with no intervention: SessionStart queries the database and injects compressed context; UserPromptSubmit logs the session; PostToolUse fires after every tool call and sends the raw output to a compression worker, around 8 ms per call; Stop produces session-level summaries; SessionEnd closes it out.

What gets stored. Every observation is typed — decision, bugfix, feature, refactor, discovery, change — with a searchable title, roughly 50-token discrete facts, a 155–500 token narrative, and semantic tags (how-it-works, gotcha, trade-off…). All of it in a local SQLite database at ~/.claude-mem/claude-mem.db. For scale, the author reports 6,814 observations across 259 sessions occupying 39 MB, 61% of them "discovery" — what the model learned about the codebase.

Retrieval. Three tiers, designed not to flood the context: layer 1 (search) returns IDs and titles for 50–100 tokens; layer 2 (timeline) places them chronologically for 100–200; layer 3 (get_observations) fetches full records in batches, 500–1,000 tokens. A telling detail: an MCP tool named __IMPORTANT exists solely to remind the model to start with the cheap layers, which it otherwise skips.

Documented installation trap: running npm install -g claude-mem installs only the SDK library without registering the hooks — the tool looks installed and captures nothing. The correct route is through the plugin marketplace.

What it computes. Five families in one pass. A health score of 1–10 per file from 21 deterministic signals with no LLM call. A dependency graph from tree-sitter ASTs across 16 languages, resolved into import, call and inheritance edges, then ranked by PageRank and betweenness centrality. Git intelligence: hotspots (churn vs complexity), co-change partners, ownership from blame, bus factor. Architectural decisions mined from PRs, inline markers and READMEs, with the files each one governs and a flag when they go stale. And reachability-aware CVE triage — knowing whether the vulnerable code is actually called.

What comes out. A local dashboard (port 7337) with force-directed graphs and community detection, hotspot tables with owner attribution, auto-generated wiki pages verified against the live AST (flagged when stale), and a decisions index. Plus a generated CLAUDE.md to orient the agent: stack, entry points, hotspots, ownership, decisions.

The PR bot. A GitHub App posting deterministic, zero-LLM comments: contracts changed by the PR and all their external callers, co-change partners, tests the PR should have touched and did not, and Check Runs that can gate merges. The same diff always produces the same review — so it is auditable. Free and uncapped on public repositories.

Correction to an earlier version of this article: we had repeated "49 detectors" and "18 languages" from the repository README. The product figures are 21 signals for the health score and 16 languages in the graph, 9 of them at full depth (Python, TypeScript, JavaScript, Java, Kotlin, Go, Rust, C++, C#).

This is not a reason to ban the tool; it is a reason to decide where it runs. On an isolated development machine with no client data, the risk is manageable. On a machine that touches client files, health data or trade secrets, a database of everything the agent has seen, readable without authentication, does not pass a security review.

Documented robustness issues sit alongside it: orphaned ChromaDB processes (one user recorded 184 processes in 19 hours, around 16 GB of RAM), cold starts on Apple Silicon exceeding a hardcoded 5-second timeout, and context-window saturation during the first week on a new project while the model maps the codebase.

The guardrail exists — <private> tags exclude their contents from storage — but it is opt-in: you have to remember every time. For regulated data, a protection that depends on user vigilance is not a protection. Same reasoning as our guide to AI agent scope and permissions.

repowise takes the opposite approach: self-hosting advertised with zero telemetry, fully offline with Ollama or your own key, and deterministic scoring with no model call. The trade-off is its AGPL-3.0 licence, whose obligations extend to software reachable over a network — and you use it by starting a server. Local use is one thing; exposing it to a team is another, which is why the vendor sells a commercial licence to escape it.

claude-mem is free and Apache-2.0. The hidden cost is elsewhere: every tool call triggers a model-based compression, so consumption is continuous.

repowise is free self-hosted (CLI, plus two public repos on the SaaS, and an explore mode with no sign-up). The hosted offering starts at $15/month with LLM credits and private repositories; Teams at $20/seat/month from three seats, with a shared index and portfolio health dashboards; Enterprise for on-prem or air-gapped, with SAML/OIDC SSO, a commercial licence and IP indemnification.

The practical reading for an SME: both are testable at zero cost. Budget only becomes a question when you share a team index or need out of the AGPL.

• "My agent forgets what we decided last week" → claude-mem. Exactly its purpose, provided you deal with port 37777 first.
• "My agent doesn't know which files are risky or who owns them" → repowise. Health score, hotspots, ownership and co-change are precisely that.
• "I want to block a PR that breaks a contract" → repowise, via the deterministic bot and Check Runs. claude-mem does no CI.
• "My code must not leave" → repowise, self-hosted and offline. claude-mem compresses through a model and its privacy tags are opt-in.
• "My agent gets my business wrong" → neither: that is a missing-information problem, covered in context is the ceiling of your agent.