cmem vs claude-mem : deux approches pour donner de la mémoire à Claude Code

ai
claude
claude-code
mcp
comparatif
devops
Author

Sylvain Pham

Published

February 8, 2026

Claude Code oublie tout entre deux sessions. C’est son plus gros défaut. Deux projets open-source tentent d’y remédier : cmem (Colby McHenry) et claude-mem (Alex Newman / thedotmack). Même objectif, architectures très différentes. J’ai creusé les deux pour comprendre lequel mérite une place dans mon workflow.

Cet article complète mon guide pratique sur claude-mem publié le 7 février.

Le problème commun

Chaque session Claude Code démarre de zéro. Pas de souvenir des fichiers lus, des choix d’architecture, des bugs corrigés. On se retrouve à ré-expliquer le projet à chaque fois, ou pire, à refaire les mêmes erreurs parce qu’on a oublié qu’on les avait déjà rencontrées.

Les deux outils capturent automatiquement le contexte des sessions, le stockent dans SQLite + base vectorielle, et le réinjectent via MCP quand c’est pertinent. Mais la façon dont ils s’y prennent est fondamentalement différente.

Architecture comparée

claude-mem : le plugin intégré

claude-mem vit dans l’écosystème plugin de Claude Code. Il s’installe via le marketplace et se greffe sur le cycle de vie de Claude Code grâce à 5 lifecycle hooks :

SessionStart → UserPromptSubmit → PostToolUse → Summary → SessionEnd

Ce qu’il capture : les appels d’outils (tool usage observations), pas les conversations brutes. Chaque observation (1 000 à 10 000 tokens) est compressée en ~500 tokens via le Claude Agent SDK, catégorisée (decision, bugfix, feature, refactor, discovery) et stockée dans SQLite + ChromaDB.

L’architecture :

Claude Code → Plugin hooks → Worker Service (port 37777)
                                    ↓
                              SQLite + ChromaDB
                                    ↓
                        Web Viewer (React, port 37777)

Le worker service tourne en arrière-plan (géré par Bun depuis la v7.1.0, avant c’était PM2). La recherche passe par 5 outils MCP avec un workflow en 3 couches : index → identifie les IDs pertinents → récupère le détail. C’est ce qu’ils appellent “progressive disclosure”.

Points notables :

  • Système de tags <private> pour exclure du contenu sensible de la mémoire
  • Beta channel avec “Endless Mode” (architecture de mémoire biomimétique pour les longues sessions)
  • Génération automatique de fichiers CLAUDE.md par dossier avec la timeline d’activité (v9.0.0+)
  • Support Gemini comme provider alternatif (v8.2.0+)
  • Site de documentation dédié : docs.claude-mem.ai
  • 24.8k étoiles GitHub, communauté très active

cmem : l’outil système indépendant

cmem est un outil Node.js autonome, installé globalement sur la machine. Il ne dépend pas du système de plugins de Claude Code.

npx @colbymchenry/cmem

L’installeur interactif fait tout : installation globale, téléchargement du modèle d’embedding (~130 Mo), configuration MCP, et optionnellement l’auto-sync au login (macOS).

Ce qu’il capture : les sessions complètes de Claude Code. Un daemon (cmem watch) surveille les sessions en temps réel, parse les conversations, et les indexe.

L’architecture :

Claude Code sessions → cmem daemon → SQLite + Vector DB (local)
                                           ↓
                         Claude Code ← MCP Server ← Sub-agent Haiku

La différence clé : le pattern sub-agent. Quand Claude a besoin de contexte passé, cmem ne l’injecte pas directement dans la fenêtre de contexte. Il spawne une instance Claude légère (Haiku par défaut) qui lit les sessions pertinentes et ne renvoie qu’une réponse synthétisée. Le contexte principal reste propre.

Points notables :

  • Embeddings 100% locaux via transformers.js + nomic-embed-text-v1.5 (768 dimensions)
  • Zéro API externe requise pour l’indexation (seul le sub-agent Haiku nécessite une clé API)
  • TUI terminal (basé sur Ink/React) pour naviguer, filtrer, renommer et reprendre des sessions
  • Flag --local pour filtrer les sessions du répertoire courant uniquement
  • Base de données dans ~/.cmem/sessions.db
  • L’auteur est aussi le créateur de CodeGraph (graph sémantique de codebase)

Tableau comparatif détaillé

Critère claude-mem (thedotmack) cmem (Colby McHenry)
Type Plugin marketplace Claude Code Outil système Node.js global
Installation /plugin marketplace add + /plugin install npx @colbymchenry/cmem
Ce qui est capturé Tool usage observations Sessions complètes
Compression Agent SDK Claude (~500 tokens/obs) Sub-agent Haiku (synthèse à la demande)
Embeddings ChromaDB (via API) Local (nomic-embed-text, ~130 Mo)
Stockage ~/.claude-mem/claude-mem.db ~/.cmem/sessions.db
Interface Web UI React (port 37777) TUI terminal (Ink/React)
Recherche 5 outils MCP + progressive disclosure search_and_summarize + 4 autres outils MCP
Privacy Tags <private> / <redact> Tout local, aucune donnée ne quitte la machine
Gestion contexte Injection directe + fichiers CLAUDE.md auto Sub-agent pattern (hors contexte principal)
Reprise session Via historique d’observations Browse + resume directement depuis le TUI
Dépendances externes Bun, API Anthropic (ou Gemini) Node.js 18+, modèle local
Providers IA Claude Agent SDK, Gemini Haiku (sub-agent)
Licence AGPL-3.0 MIT
Maturité v9.0.11+, 24.8k ★, changelog dense Plus récent, moins de métriques publiques

Ce que j’en retiens

claude-mem excelle sur…

La granularité de capture. En interceptant chaque appel d’outil individuellement, claude-mem crée des observations catégorisées et étiquetées. Tu peux chercher spécifiquement un bugfix ou une décision d’architecture. C’est plus fin qu’un dump de session.

L’écosystème. Site de documentation, Web UI, beta channel, support multi-provider (Gemini), génération automatique de CLAUDE.md par dossier. Le projet a une communauté massive (24.8k étoiles) et évolue très vite (v9 en quelques mois).

L’intégration native. En tant que plugin, il se met à jour automatiquement via le marketplace. Pas de daemon à gérer manuellement.

cmem excelle sur…

La confidentialité. Les embeddings sont calculés localement. Aucune conversation ne quitte ta machine pour l’indexation. C’est un argument massif pour les projets sensibles (infra, certificats, code propriétaire).

La propreté du contexte. Le pattern sub-agent est architecturalement supérieur : le travail de synthèse se fait hors de ta fenêtre de contexte principale. Tu ne “pollues” pas ta session avec du contexte historique brut.

Le contrôle. C’est un binaire que tu gères toi-même : start, stop, update, script, intégration dans ton tooling. Si tu es DevOps, c’est plus naturel qu’un plugin marketplace.

La navigation. Le TUI terminal avec filtrage par dossier, renommage de sessions, et reprise directe est un vrai plus pour le workflow quotidien.

Les limites des deux

claude-mem dépend du système de plugins de Claude Code. Si Anthropic change l’API plugin (ce qui est arrivé avec CC 2.1.0), ça peut casser. Le projet a d’ailleurs connu des épisodes de zombies de processus et de sessions “observer” qui polluaient la liste de resume (corrigés depuis). L’AGPL-3.0 peut aussi être un frein pour certains usages commerciaux.

cmem est plus jeune avec moins de métriques publiques. Le sub-agent Haiku consomme des tokens API à chaque recherche (contrairement à claude-mem qui compresse en amont). Et le fait qu’il surveille les fichiers de session de Claude Code signifie qu’un changement de format de session côté Anthropic pourrait aussi le casser.

Peut-on utiliser les deux en même temps ?

Sur deux projets différents : oui. Chacun a sa propre base de données et son propre process.

Sur le même projet : non recommandé. Conflit potentiel de serveurs MCP, double capture des sessions, injection de contexte en double. C’est chercher les ennuis.

L’approche la plus propre : tester chacun pendant 2-3 semaines sur des projets distincts, puis garder celui qui colle le mieux à ton workflow.

Et la mémoire native de Claude Code ?

Il faut mentionner que Claude Code a aussi ses propres mécanismes de mémoire :

  • Fichiers CLAUDE.md : manuels, versionnés avec Git, chargés au démarrage. Simples mais efficaces.
  • Auto Memory (récent) : Claude Code peut maintenant sauvegarder automatiquement des infos dans des fichiers mémoire. Activable via CLAUDE_CODE_DISABLE_AUTO_MEMORY=0.
  • /resume : reprise d’une session précédente (limité, pas de recherche sémantique).

Les deux outils se positionnent au-dessus de ces mécanismes natifs pour offrir une mémoire plus riche et recherchable. Claude-mem va même jusqu’à générer des CLAUDE.md automatiques par dossier, ce qui crée un pont intéressant entre mémoire avancée et mémoire native.

Mon choix pour un setup VPS

Dans le contexte d’un VPS Hetzner avec Tailscale (mon setup actuel), cmem a un avantage naturel :

  • Tout reste dans le réseau privé
  • Pas de dépendance à des API externes pour l’indexation
  • Le TUI est parfait pour un usage SSH/tmux
  • Contrôle total sur le cycle de vie du daemon

Mais je garde un œil sur claude-mem pour sa granularité de capture et son écosystème. Si le projet mature encore (et que les problèmes de stabilité sont résolus), il pourrait devenir le choix par défaut sur des projets moins sensibles.

Installation rapide

claude-mem

# Dans Claude Code :
/plugin marketplace add thedotmack/claude-mem-marketplace
/plugin install claude-mem@claude-mem-marketplace

# Vérifier : relancer une session, le worker démarre automatiquement
# Un message "SessionStart:startup hook succeeded" confirme l'installation

Le worker tourne en arrière-plan sur le port 37777. L’interface web est accessible à http://localhost:37777.

cmem

# Installation interactive (installe globalement + modèle d'embedding ~130 Mo)
npx @colbymchenry/cmem

# Lancer le daemon — indexe toutes les sessions automatiquement
cmem watch

C’est tout. cmem watch tourne en arrière-plan et alimente Claude Code via MCP. Les sessions passées sont retrouvées automatiquement quand c’est pertinent.

Liens

Testé en février 2026. Les deux projets évoluent vite ; vérifier les versions actuelles avant installation.