Fonctionnement et intégration

jevmem s’installe en une minute avec

npm install -g jevmem
puis se configure via jevmem init --tool claude. La commande crée JEVMEM.md, un fichier de configuration jevmem.config.json et un répertoire .jevmem/ ignoré par Git. Deux hooks sont ajoutés automatiquement dans .claude/settings.local.json : le Stop hook, déclenché à chaque fin de tour, et le UserPromptSubmit hook, déclenché à chaque saisie utilisateur. Le même principe s’applique aux agents Codex, Cursor et Claude Desktop, avec des règles spécifiques (.cursor/rules/jevmem.mdc ou appels MCP add_memory). Le stockage principal repose sur PostgreSQL 16, choisi parce que SQLite montre des blocages sous charge, comme indiqué dans le README.

Mécanisme de capture et de filtrage

À chaque tour, jevmem applique d’abord un scrubbing qui élimine les formes de secrets (adresses e‑mail, numéros de carte, etc.) avant que les données ne quittent la machine. Ensuite, le petit modèle Jev de TypeSafe AI classe le texte en fonction de cinq probabilités : décision, règle, bug, petite conversation ou tentative d’injection. Les seuils de décision sont stockés dans jevmem.config.json, ce qui évite d’utiliser un prompt LLM à chaque appel. Si la probabilité dépasse le seuil, le système génère une ligne de moins de 200 caractères, écrite soit par un LLM (coût optionnel) soit par une extraction déterministe. Les lignes précédemment enregistrées sont marquées [superseded] lorsqu’une nouvelle information les remplace, conservant ainsi l’historique complet.

Évaluation de performance

Le benchmark interne porte sur 66 tours retenus, évalués avec sept déciders LLM (GPT‑6 Astra, GPT‑6 Luna, Claude Fable, Claude Opus, Gemini Flash, Grok et jevmem auto). Les métriques clés sont le taux de sauvegarde/ignorance, la capacité à identifier le type de contenu (save+kind) et le temps médian (p50). Les LLM affichent des taux de sauvegarde compris entre 90,9 % et 98,5 % avec des latences de 2,8 à 4,3 s. jevmem auto atteint 98,5 % de sauvegarde, 95,5 % de classification correcte, un p50 de 300 ms et un coût de 0,000127 $ par décision. Le temps de décision de l’API Jev est de 0,30 s ; en incluant le hook Stop complet, le délai passe à 0,6 s, soit plus d’une dizaine de fois plus rapide que les LLM évalués. Cette rapidité provient du modèle léger et du traitement local, tandis que la précision reste comparable aux modèles de grande taille, ce qui confirme la pertinence d’une approche hybride entre extraction déterministe et LLM minimal.

Implications et limites

Le principal avantage de jevmem réside dans son intégration transparente aux flux de travail existants et son coût marginal. En revanche, la qualité de la mémorisation dépend de la capacité du petit modèle Jev à détecter correctement les intentions, ce qui peut varier selon le style de l’utilisateur. De plus, le stockage PostgreSQL impose une infrastructure supplémentaire pour les projets à grande échelle, alors que les petites équipes pourraient rester limitées par SQLite sous charge. Enfin, le benchmark repose sur un jeu de 66 tours, ce qui limite la généralisation des résultats à des projets plus complexes ou à des langues différentes.