codebase-memory-mcp: 127% meer tokens, geen 99% minder

codebase-memory-mcp, van DeusData, ging deze week viraal op TikTok. Het is een enkele statische binary die een repository indexeert tot een knowledge graph — 158 talen, de Linux-kernel geïndexeerd in drie minuten — en die aan Claude Code blootstelt als MCP-server. De pitch is agressief: de GitHub-beschrijving zegt "99% fewer tokens," de README zegt "120x fewer tokens — 5 structural queries: ~3.400 tokens vs ~412.000," en hun arXiv-preprint (arXiv:2603.27277) rapporteert "10× fewer tokens, 83% answer quality" gemiddeld over 31 repo's.

Wij laten elke tool die we catalogiseren door een gecontroleerde A/B-test lopen voordat we hem scoren. Dus vandaag (2026-07-11) bouwden we een structurele benchmark van 8 taken, registreerden we de vragen en de ground truth vooraf voordat een van beide varianten draaide, en zetten we zowel een kale-grep-Sonnet-agent als een MCP-uitgeruste Sonnet-agent op dezelfde repo. De correctheid kwam gelijk uit, 8/8 in beide gevallen. De vlaggenschipclaim over tokens keerde om: de MCP-variant gebruikte 172.319 tokens tegenover de 75.817 van de baseline — 127% meer, geen 99% minder.

Dat is niet het hele verhaal, en dat vinden we ook niet dat het zou moeten zijn. De engineering eronder is echt goed. Dit is wat we vonden en waarom het cijfer bewoog zoals het bewoog.

Wat de tool goed doet

codebase-memory-mcp installeert als één Homebrew-baar binary, indexeert met één commando, en leverde bij de eerste poging schone JSON op. Twee van onze acht taken waren duidelijke overwinningen voor de graph:

• T5 (call-chain trace) — tracen van een POST-handler naar een private helper drie hops diep, via twee mogelijke paden. trace_path(direction=outbound) gaf in één call precies de juiste DAG terug, overeenkomend met handmatige verificatie.
• T7 (definitielookup) — "waar is formatDate gedefinieerd." get_code_snippet gaf in één call het bestand en het exacte begin-/eindregelnummer terug, zonder onduidelijkheid.

Beide zijn precies het type query waar een graph in zou moeten domineren: pure TypeScript, statische structuur, geen framework-grens die in de weg zit. Is jouw repo puur TS/JS en zien jouw vragen er zo uit, dan is de tool snel en precies.

Waar het misging

Onze testbed was onze eigen repo: 157 bestanden, Astro + TypeScript — een codebase met gemengde frameworks, wat dicht bij een worst case ligt voor een graph-indexeerder die primair gebouwd is rond een CALLS/IMPORTS-edge-model. Vier van de acht taken legden echte blinde vlekken bloot:

• T1 (wie roept getSession aan) — trace_path(inbound) vond slechts 5 van de 7 aanroepers. De CALLS-graph vangt geen calls vanuit .astro-frontmatter, waardoor twee legitieme aanroepers (admin.astro, account.astro) onzichtbaar voor hem waren.
• T2 (imports van purchases.ts) — de IMPORTS-graph gaf 2 van de 3 import-statements terug. De ontbrekende was een type-only import (import type { APIContext } from 'astro') — niet als edge bijgehouden.
• T3 (vind de ene dode export) — de eigen dead-code-query van de tool (max_degree=0) gaf vier tot vijf false positives terug: functies die wel degelijk leven, aangeroepen vanuit .astro-frontmatter die de graph niet kan zien. De is_exported-vlag van de graph klopte ook niet bij verschillende functies (b64url, hmac, devStore, nameToSlug — allemaal gemarkeerd als exported, terwijl geen van alle daadwerkelijk een export-keyword in de broncode heeft). Het juiste antwoord vereiste het volledig ophalen van de broncode van alle vier bestanden en het handmatig verifiëren van elke declaratie.
• T8 (impact van het verwijderen van store.ts) — de IMPORTS-graph vond de 4 statische importeurs netjes, maar miste alle 3 dynamische import()-callsites volledig: één binnen een devStore()-helper in auth.ts, één in submit.ts, één in account.astro-frontmatter. Dynamische imports worden simpelweg niet als edges gemodelleerd.

Het scorebord per taak

Taak	Vraag	BASE	MCP	Wat er gebeurde
T1	wie roept getSession aan	1,0	1,0	MCP-graph vond 5/7; herstelde 2 .astro-aanroepers via zijn eigen text-search-fallback
T2	imports van purchases.ts	1,0	1,0	MCP-graph vond 2/3; miste de type-only import
T3	één dode export in src/lib/	1,0	1,0	MCP's dead-code-query gaf 4–5 false positives terug; vereiste volledige handmatige broncodeverificatie
T4	aantal exported functies	1,0	1,0	MCP telde vanuit ruwe broncode omdat de is_exported-metadata onbetrouwbaar was
T5	call chain, POST → b64url	1,0	1,0	Duidelijke winst voor de graph — pure .ts, geen framework-grens
T6	bestand met de meeste import-statements	1,0	1,0	MCP's edge-count vermengde per-symbool met per-statement; vereiste een regex-kruiscontrole
T7	waar is formatDate gedefinieerd	1,0	1,0	Duidelijke winst — exact regelnummer in één call
T8	impact van het verwijderen van store.ts	1,0	1,0	MCP-graph vond 4/7; miste alle 3 dynamische import()-sites
Totaal		8/8	8/8	MCP viel bij 4 van de 8 taken terug op zijn eigen text search

Beide varianten kwamen op identieke, correcte antwoorden op elke vraag uit. Maar die pariteit doet veel werk om geruststellend te lijken: de MCP-agent kreeg bij de helft van de taken een verkeerd of onvolledig graph-antwoord en moest dat opmerken, om vervolgens naar search_code te ontsnappen — het ingebouwde grep-equivalent van de tool — om het correcte antwoord opnieuw uit de broncode af te leiden. Een agent die het eerste antwoord van de graph zonder die zelfcorrectie had vertrouwd, zou ongeveer 4/8 hebben gescoord, fout of ongefundeerd op T1, T3, T4 en T8.

De tokenrekensom

Variant	Totaal tokens	vs. claim
BASE (kaal Read/Grep)	75.817	—
MCP (codebase-memory-mcp)	172.319	+127% meer, geen 99% minder

measured_savings = 1 − 172.319 / 75.817 = −127,3%. Het mechanisme is zichtbaar in de taak-per-taak-uitsplitsing hierboven: de agent betaalde voor de graph-query, ontdekte dat die fout of onvolledig was, en betaalde vervolgens opnieuw voor de grep-equivalente fallback om het echte antwoord te krijgen. Graph plus grep kost meer dan grep alleen, elke keer dat de graph gecorrigeerd moet worden — en op deze repo moest dat bij de helft van de taken.

Om even bij stil te staan: de eigen marketing van de tool citeert "~500 tokens vs ~80K for grep" per query. Onze volledige run van 8 taken met alleen grep kostte 75.817 tokens — minder dan de geclaimde kosten van één grep-query in hun materiaal. Eenmalige indexering (seconden, één keer bij setup) is uitgesloten van het MCP-totaal hierboven, wat gunstig is voor de tool.

Niet de memory-skill waar je aan denkt

Als "codebase-memory-mcp" en skills zoals memory-management of claude-mem klinken alsof ze hetzelfde probleem oplossen, dan is dat niet zo. Sessiegeheugen-skills onthouden feiten en beslissingen over gesprekken heen — wat je Claude vorige week vertelde, projectcontext die anders tussen sessies zou verdwijnen. codebase-memory-mcp indexeert codestructuur binnen een repo — call graphs, import-edges, definities — binnen één sessie. Beide worden "memory" genoemd. De ene is gespreks-continuïteit, de andere is statische analyse. Installeer dit niet in de verwachting dat het jouw laatste sessie onthoudt.

Kanttekeningen, ronduit gesteld

We tekenen de grenzen liever zelf dan dat je ze op de harde manier ontdekt:

• n=8 taken, één repo. 157 bestanden, Astro/TypeScript — een setup met gemengde frameworks die dicht bij het worst case ligt voor een CALLS/IMPORTS-model dat moet redeneren over templatefrontmatter naast scriptbestanden.
• Hun arXiv-preprint testte 31 repo's; wij testten er één. Het is heel goed mogelijk dat hun gemiddelde beter standhoudt over een bredere, meer pure-TS/JS-steekproef dan onze enkele codebase met gemengde frameworks.
• Grote, pure TS/JS-monorepo's zouden er anders uit kunnen zien. Waar een naïeve grep echt een enorme output teruggeeft en de graph schone edges heeft om mee te werken (geen .astro-frontmatter, geen dynamische imports), zou de tokenrekensom mogelijk in het voordeel van de graph kunnen uitvallen. T5 en T7 — pure TypeScript, structureel eenvoudig — zijn precies dat type, en de graph wint daar ook duidelijk.
• Indexeertijd is uitgesloten van het MCP-totaal, wat de tool bevoordeelt, niet de baseline.

Reproduceerbaarheidsnotitie: de 8 taken werden geschreven en vastgelegd voordat een van beide varianten draaide. Ground truth voor elk antwoord werd onafhankelijk grep-geverifieerd tegen de repo, niet afgeleid uit de output van een van beide varianten. Beide varianten draaiden op hetzelfde Sonnet-model, dezelfde repo-checkout, telkens verse context.

Installeer met je ogen open

Gebruik hem als aanvullende tracer op pure TS/JS-repo's waar je snelle call-chain tracing of definitielookups nodig hebt en jouw codebase niet leunt op dynamische import(), type-only imports, of een templatinglaag die de graph niet kan parsen. T5 en T7 laten precies zien waar hij goed in is.

Behandel zijn graph niet als bron van waarheid op codebases met gemengde frameworks. Als jouw repo Astro, Vue, Svelte, of vergelijkbare templating mengt met TypeScript, of leunt op dynamische imports, houd er dan rekening mee dat de tool fout kan zitten bij specifiek "wie roept dit aan"- en "wat is dode code"-queries — en reken op de tokenkosten van de grep-fallback die hij nodig heeft om zichzelf te corrigeren.

FAQ

Is de tool slecht? Nee. De installatie is schoon, indexeren is snel, en call-chain tracing plus definitielookup in pure TypeScript zijn echt uitstekend. Het probleem is smaller dan "de tool is slecht": de vlaggenschipclaim over tokenbesparing houdt geen stand op een repo met gemengde frameworks, omdat blinde vlekken in de graph de agent dwingen om zowel voor de graph als voor de grep te betalen.

Waarom verschillen jullie cijfers van het arXiv-paper? Andere steekproef. Hun preprint middelt over 31 repo's; wij testten één repo van 157 bestanden, Astro/TypeScript, dicht bij een worst case voor hun edge-model (frontmattercalls, dynamische imports, type-only imports vallen allemaal buiten CALLS/IMPORTS). Beide resultaten kunnen tegelijk waar zijn: het hunne een breder gemiddelde, het onze een specifiek, reproduceerbaar worst-case-datapunt dat iedereen met een codebase met gemengde frameworks zou moeten meewegen voordat hij het krantenkopcijfer vertrouwt.

Moet ik hem verwijderen? Niet per se. Werk je vooral in pure TypeScript of JavaScript zonder zware dynamische imports, dan zegt onze T5/T7-data dat hij een solide tracer is. Mengt jouw repo frameworks zoals de onze, houd hem dan geïnstalleerd maar laat hem grep niet vervangen — behandel zijn antwoorden als een hypothese die je verifieert, zoals onze MCP-agent uiteindelijk toch bij de helft van de taken deed.

Hoe zit het met heel grote repo's? Dat hebben we niet getest, en dat is een echt gat in onze data. De theoretische case voor de tool is daar het sterkst: een enkele grep over een enorme monorepo kan een gigantische resultatenset teruggeven, terwijl een graph-query klein blijft ongeacht de repogrootte. Draai je een grote, pure TS/JS-monorepo, dan is het gemiddelde over 31 repo's uit het arXiv-paper relevanter voor jou dan ons enkele kleine-repo-resultaat — maar draai je eigen A/B-test voordat je een van beide cijfers blind vertrouwt.