codebase-memory-mcp : 127 % de tokens de plus, pas 99 %

codebase-memory-mcp, de DeusData, est devenu viral sur TikTok cette semaine. C'est un binaire statique unique qui indexe un repository dans un knowledge graph — 158 langages, le noyau Linux indexé en trois minutes — et l'expose à Claude Code comme serveur MCP. L'argumentaire est agressif : la description GitHub dit « 99 % de tokens en moins », le README dit « 120x moins de tokens — 5 requêtes structurelles : ~3 400 tokens contre ~412 000 », et leur prépublication arXiv (arXiv:2603.27277) rapporte « 10× moins de tokens, 83 % de qualité de réponse » en moyenne sur 31 repos.

Nous faisons passer chaque outil de notre catalogue par un A/B contrôlé avant de le noter. Aujourd'hui (2026-07-11), nous avons donc construit un benchmark structurel à 8 tâches, préenregistré les questions et la vérité terrain avant que l'un ou l'autre bras ne tourne, puis pointé à la fois un agent Sonnet en grep pur et un agent Sonnet équipé du MCP sur le même repo. Les résultats de correction sont ressortis à égalité, 8/8 des deux côtés. L'argument phare sur les tokens s'est inversé : le bras MCP a utilisé 172 319 tokens contre 75 817 pour la baseline — 127 % en plus, pas 99 % en moins.

Ça ne raconte pas toute l'histoire, et nous ne pensons pas que ça le devrait. L'ingénierie derrière est vraiment bonne. Voici ce que nous avons trouvé, et pourquoi le chiffre a bougé de cette façon.

Ce que l'outil fait bien

codebase-memory-mcp s'installe comme un binaire unique installable via Homebrew, s'indexe en une commande, et a produit du JSON propre du premier coup. Deux de nos huit tâches étaient des victoires nettes pour le graphe :

• T5 (traçage de chaîne d'appels) — tracer depuis un handler POST jusqu'à un helper privé trois sauts plus loin, à travers deux chemins possibles. trace_path(direction=outbound) a renvoyé le DAG exact en un seul appel, correspondant exactement à la vérification manuelle.
• T7 (recherche de définition) — « où est défini formatDate ». get_code_snippet a renvoyé le fichier et la ligne de début/fin précise en un seul appel, sans ambiguïté.

Ces deux cas sont exactement le type de requête où un graphe devrait dominer : TypeScript pur, structure statique, aucune frontière de framework en travers du chemin. Si votre repo est en TS/JS pur et que vos questions ressemblent à celles-ci, l'outil est rapide et précis.

Là où ça a coincé

Notre banc de test était notre propre repo : 157 fichiers, Astro + TypeScript — une codebase multi-frameworks, ce qui se rapproche d'un pire cas pour un indexeur de graphe construit principalement autour d'un modèle d'arêtes CALLS/IMPORTS. Quatre des huit tâches ont révélé de vrais angles morts :

• T1 (qui appelle getSession) — trace_path(inbound) n'a trouvé que 5 des 7 appelants. Le graphe CALLS ne capture pas les appels faits depuis le frontmatter .astro, donc deux appelants légitimes (admin.astro, account.astro) lui étaient invisibles.
• T2 (imports de purchases.ts) — le graphe IMPORTS a renvoyé 2 des 3 instructions d'import. Celle qui manquait était un import type-only (import type { APIContext } from 'astro') — non suivi comme arête.
• T3 (trouver l'unique export mort) — la propre requête de code mort de l'outil (max_degree=0) a renvoyé quatre à cinq faux positifs : des fonctions bien vivantes, appelées depuis le frontmatter .astro que le graphe ne peut pas voir. Le flag is_exported du graphe était aussi faux sur plusieurs fonctions (b64url, hmac, devStore, nameToSlug — toutes marquées exportées, alors qu'aucune n'a réellement de mot-clé export dans le source). Obtenir la bonne réponse a exigé de récupérer le source complet des quatre fichiers et de vérifier manuellement chaque déclaration.
• T8 (impact de la suppression de store.ts) — le graphe IMPORTS a trouvé proprement les 4 importateurs statiques, mais a complètement raté les 3 sites d'appel import() dynamique : un dans un helper devStore() de auth.ts, un dans submit.ts, un dans le frontmatter de account.astro. Les imports dynamiques ne sont tout simplement pas modélisés comme des arêtes.

Le tableau de score par tâche

Tâche	Question	BASE	MCP	Ce qui s'est passé
T1	qui appelle getSession	1.0	1.0	Le graphe MCP en a trouvé 5/7 ; a récupéré 2 appelants .astro via son propre repli en recherche textuelle
T2	imports de purchases.ts	1.0	1.0	Le graphe MCP en a trouvé 2/3 ; a raté l'import type-only
T3	un export mort dans src/lib/	1.0	1.0	La requête de code mort du MCP a renvoyé 4 à 5 faux positifs ; a nécessité une vérification manuelle complète du source
T4	nombre de fonctions exportées	1.0	1.0	Le MCP a compté à partir du source brut car les métadonnées is_exported n'étaient pas fiables
T5	chaîne d'appels, POST → b64url	1.0	1.0	Victoire nette pour le graphe — .ts pur, aucune frontière de framework
T6	fichier avec le plus d'instructions d'import	1.0	1.0	Le comptage d'arêtes du MCP confondait par-symbole et par-instruction ; a nécessité une contre-vérification par regex
T7	où est défini formatDate	1.0	1.0	Victoire nette — numéro de ligne exact en un seul appel
T8	impact de la suppression de store.ts	1.0	1.0	Le graphe MCP en a trouvé 4/7 ; a raté les 3 sites import() dynamique
Total		8/8	8/8	Le MCP s'est replié sur sa propre recherche textuelle sur 4 des 8 tâches

Les deux bras sont arrivés à des réponses identiques et correctes à chaque question. Mais cette parité travaille dur pour paraître rassurante : l'agent MCP a obtenu une réponse de graphe fausse ou incomplète sur la moitié des tâches, a dû s'en apercevoir, puis s'échapper vers search_code — l'équivalent grep intégré de l'outil — pour re-dériver la bonne réponse depuis le source. Un agent qui aurait fait confiance à la première réponse du graphe sans cette auto-correction aurait obtenu un score d'environ 4/8, faux ou non étayé sur T1, T3, T4 et T8.

Le calcul des tokens

Bras	Total tokens	vs. l'annonce
BASE (Read/Grep simple)	75 817	—
MCP (codebase-memory-mcp)	172 319	+127 % en plus, pas 99 % en moins

measured_savings = 1 − 172,319 / 75,817 = −127.3%. Le mécanisme est visible dans le détail par tâche ci-dessus : l'agent a payé pour la requête de graphe, découvert qu'elle était fausse ou incomplète, puis payé à nouveau pour le repli équivalent-grep afin d'obtenir la vraie réponse. Graphe plus grep coûte plus cher que grep seul, à chaque fois que le graphe a besoin d'être corrigé — et sur ce repo, il avait besoin d'être corrigé sur la moitié des tâches.

Ça vaut la peine de s'y attarder : le marketing de l'outil lui-même cite « ~500 tokens contre ~80K pour grep » par requête. Notre run complet à 8 tâches en grep seul a coûté 75 817 tokens — moins que le coût annoncé d'une seule requête grep dans leur documentation. L'indexation ponctuelle (quelques secondes, faite une fois à l'installation) est exclue du total MCP ci-dessus, ce qui est généreux envers l'outil.

Pas le skill de mémoire auquel vous pensez

Si « codebase-memory-mcp » et des skills comme memory-management ou claude-mem semblent résoudre le même problème, ce n'est pas le cas. Les skills de mémoire de session font persister des faits et des décisions entre les conversations — ce que vous avez dit à Claude la semaine dernière, un contexte de projet qui disparaîtrait sinon entre les sessions. codebase-memory-mcp indexe la structure du code au sein d'un repo — graphes d'appels, arêtes d'import, définitions — au sein d'une seule session. Les deux sont appelés « mémoire ». L'un est de la continuité de conversation, l'autre de l'analyse statique. N'installez pas cet outil en vous attendant à ce qu'il se souvienne de votre dernière session.

Limites, dites franchement

Nous préférons tracer nous-mêmes les limites plutôt que vous les découvriez à vos dépens :

• n=8 tâches, un seul repo. 157 fichiers, Astro/TypeScript — une configuration multi-frameworks proche du pire cas pour un modèle CALLS/IMPORTS qui doit raisonner sur le frontmatter de template en plus des fichiers de script.
• Leur prépublication arXiv a testé 31 repos ; nous en avons testé un seul. Il est tout à fait plausible que leur moyenne tienne mieux sur un échantillon plus large et plus proche du TS/JS pur que ne le représente notre unique repo multi-frameworks.
• Les gros monorepos en TS/JS pur pourraient donner un tableau différent. Là où un grep naïf renvoie vraiment une sortie énorme et où le graphe dispose d'arêtes propres avec lesquelles travailler (pas de frontmatter .astro, pas d'imports dynamiques), le calcul de tokens pourrait plausiblement favoriser le graphe. T5 et T7 — TypeScript pur, structurellement simples — sont exactement de cette forme, et le graphe y gagne aussi nettement.
• Le temps d'indexation est exclu du total MCP, ce qui favorise l'outil, pas la baseline.

Note de reproductibilité : les 8 tâches ont été rédigées et figées avant que l'un ou l'autre bras ne tourne. La vérité terrain de chaque réponse a été vérifiée indépendamment par grep sur le repo, et non dérivée de la sortie de l'un des deux bras. Les deux bras ont tourné sur le même modèle Sonnet, le même checkout de repo, avec un contexte neuf à chaque fois.

Installez les yeux ouverts

Utilisez-le comme traceur complémentaire sur des repos en TS/JS pur où vous avez besoin d'un traçage rapide de chaînes d'appels ou de recherches de définitions, et où votre codebase ne repose pas sur des import() dynamiques, des imports type-only, ou une couche de templating que le graphe ne peut pas parser. T5 et T7 montrent exactement ce pour quoi il est bon.

Ne traitez pas son graphe comme une source de vérité sur des codebases multi-frameworks. Si votre repo mélange Astro, Vue, Svelte ou un templating similaire avec TypeScript, ou repose sur des imports dynamiques, prévoyez que l'outil se trompe spécifiquement sur les requêtes « qui appelle ceci » et « qu'est-ce qui est du code mort » — et budgétez le coût en tokens du grep de repli dont il aura besoin pour se corriger.

FAQ

L'outil est-il mauvais ? Non. L'installation est propre, l'indexation est rapide, et le traçage de chaînes d'appels ainsi que la recherche de définitions en TypeScript pur sont vraiment excellents. Le problème est plus étroit que « l'outil est mauvais » : l'argument phare d'économie de tokens ne tient pas sur un repo multi-frameworks, parce que les angles morts du graphe forcent l'agent à payer à la fois pour le graphe et pour le grep.

Pourquoi vos chiffres diffèrent-ils de ceux du papier arXiv ? Un échantillon différent. Leur prépublication fait une moyenne sur 31 repos ; nous avons testé un seul repo Astro/TypeScript de 157 fichiers, proche d'un pire cas pour leur modèle d'arêtes (les appels de frontmatter, les imports dynamiques, les imports type-only tombent tous en dehors de CALLS/IMPORTS). Les deux résultats peuvent être vrais en même temps — le leur est une moyenne plus large, le nôtre un point de données spécifique et reproductible de pire cas, que quiconque sur un repo multi-frameworks devrait peser avant de faire confiance au chiffre phare.

Dois-je le désinstaller ? Pas nécessairement. Si vous travaillez principalement en TypeScript ou JavaScript pur sans imports dynamiques massifs, nos données T5/T7 disent que c'est un bon traceur. Si votre repo mélange les frameworks comme le nôtre, gardez-le installé mais ne le laissez pas remplacer grep — traitez ses réponses comme une hypothèse à vérifier, de la même façon que notre agent MCP a fini par le faire sur la moitié des tâches de toute façon.

Qu'en est-il des très gros repos ? Nous n'en avons pas testé, et c'est une vraie lacune dans nos données. L'argument théorique en faveur de l'outil y est le plus fort : un simple grep sur un énorme monorepo peut renvoyer un ensemble de résultats gigantesque, tandis qu'une requête de graphe reste petite quel que soit la taille du repo. Si vous faites tourner un gros monorepo en TS/JS pur, la moyenne sur 31 repos du papier arXiv vous concerne davantage que notre résultat sur un seul petit repo — mais lancez votre propre A/B avant de faire confiance aveuglément à l'un ou l'autre chiffre.