codebase-memory-mcp: 127% flere tokens, ikke 99% færre

codebase-memory-mcp, fra DeusData, gik viralt på TikTok i denne uge. Det er en enkelt statisk binary, der indekserer et repository til en knowledge graph — 158 sprog, Linux-kernen indekseret på tre minutter — og eksponerer det til Claude Code som en MCP-server. Salgstalen er aggressiv: GitHub-beskrivelsen siger "99% fewer tokens", README'en siger "120x fewer tokens — 5 structural queries: ~3,400 tokens vs ~412,000", og deres arXiv-preprint (arXiv:2603.27277) rapporterer "10× fewer tokens, 83% answer quality" i gennemsnit over 31 repos.

Vi kører hvert værktøj, vi katalogiserer, gennem en kontrolleret A/B, før vi scorer det. Så i dag (2026-07-11) byggede vi en 8-opgavers strukturel benchmark, forhåndsregistrerede spørgsmålene og facit, før nogen af siderne kørte, og satte både en plain-grep Sonnet-agent og en MCP-udstyret Sonnet-agent til samme repo. Korrektheden endte uafgjort, 8/8 begge. Den centrale token-påstand vendte om: MCP-siden brugte 172,319 tokens mod baselinens 75,817 — 127% flere, ikke 99% færre.

Det er ikke hele historien, og det synes vi heller ikke, det bør være. Ingeniørarbejdet under motorhjelmen er reelt godt. Her er, hvad vi fandt, og hvorfor tallet bevægede sig, som det gjorde.

Det, værktøjet gør godt

codebase-memory-mcp installeres som en enkelt Homebrew-installerbar binary, indekserer med én kommando og producerede ren JSON i første forsøg. To af vores otte opgaver var klare sejre for grafen:

• T5 (call-chain-sporing) — sporing fra en POST-handler ned til en privat hjælpefunktion tre hop nede, gennem to mulige stier. trace_path(direction=outbound) returnerede den nøjagtige DAG i ét kald, som matchede manuel verifikation præcist.
• T7 (definitionsopslag) — "hvor er formatDate defineret." get_code_snippet returnerede filen og de præcise start-/slutlinjer i ét kald, uden tvetydighed.

Begge dele er præcis den type forespørgsel, en graf burde dominere: ren TypeScript, statisk struktur, ingen framework-grænse i vejen. Hvis dit repo er ren TS/JS, og dine spørgsmål ligner disse, er værktøjet hurtigt og præcist.

Hvor det brød sammen

Vores testbed var vores eget repo: 157 filer, Astro + TypeScript — en blandet framework-kodebase, hvilket er tæt på et worst case for en grafindekserer bygget primært omkring en CALLS/IMPORTS-kant-model. Fire af de otte opgaver afslørede reelle blinde vinkler:

• T1 (hvem kalder getSession) — trace_path(inbound) fandt kun 5 ud af 7 kaldere. CALLS-grafen fanger ikke kald fra .astro-frontmatter, så to legitime kaldere (admin.astro, account.astro) var usynlige for den.
• T2 (imports af purchases.ts) — IMPORTS-grafen returnerede 2 ud af 3 import-statements. Den manglende var en type-only import (import type { APIContext } from 'astro') — ikke sporet som en kant.
• T3 (find den ene døde export) — værktøjets egen dead-code-forespørgsel (max_degree=0) returnerede fire til fem falske positiver: funktioner, der er levende, kaldt fra .astro-frontmatter, som grafen ikke kan se. Grafens is_exported-flag var også forkert på flere funktioner (b64url, hmac, devStore, nameToSlug — alle markeret som eksporterede, ingen af dem har reelt et export-nøgleord i kildekoden). At få det rigtige svar krævede at trække fuld kildekode for alle fire filer og manuelt verificere hver eneste deklaration.
• T8 (impact af at slette store.ts) — IMPORTS-grafen fandt rent de 4 statiske importører, men misforstod fuldstændig alle 3 dynamiske import()-kaldsteder: ét inde i en devStore()-hjælpefunktion i auth.ts, ét inde i submit.ts, ét inde i account.astro-frontmatter. Dynamiske imports er simpelthen ikke modelleret som kanter.

Opgave-for-opgave-scoreboardet

Opgave	Spørgsmål	BASE	MCP	Hvad der skete
T1	hvem kalder getSession	1.0	1.0	MCP-grafen fandt 5/7; genfandt 2 .astro-kaldere via sin egen tekstsøgnings-fallback
T2	imports af purchases.ts	1.0	1.0	MCP-grafen fandt 2/3; misforstod den type-only import
T3	én død export i src/lib/	1.0	1.0	MCP's dead-code-forespørgsel returnerede 4–5 falske positiver; krævede fuld manuel kildekodeverifikation
T4	antal eksporterede funktioner	1.0	1.0	MCP talte ud fra rå kildekode, fordi is_exported-metadata var upålidelig
T5	call-chain, POST → b64url	1.0	1.0	Klar sejr til grafen — ren .ts, ingen framework-grænse
T6	fil med flest import-statements	1.0	1.0	MCP's kant-optælling sammenblandede per-symbol med per-statement; krævede et regex-krydstjek
T7	hvor er formatDate defineret	1.0	1.0	Klar sejr — præcist linjenummer i ét kald
T8	impact af at slette store.ts	1.0	1.0	MCP-grafen fandt 4/7; misforstod alle 3 dynamiske import()-steder
Total		8/8	8/8	MCP faldt tilbage på sin egen tekstsøgning i 4 ud af 8 opgaver

Begge sider landede på identiske, korrekte svar på hvert spørgsmål. Men den paritet gør et stort arbejde for at virke betryggende: MCP-agenten ramte et forkert eller ufuldstændigt grafsvar på halvdelen af opgaverne og måtte opdage det, hvorefter den slap ud i search_code — værktøjets indbyggede grep-ækvivalent — for at genudlede det korrekte svar fra kildekoden. En agent, der stolede på grafens første svar uden den selvkorrektion, ville have scoret omkring 4/8, forkert eller uunderbygget på T1, T3, T4 og T8.

Token-matematikken

Side	Tokens i alt	vs. påstand
BASE (ren Read/Grep)	75,817	—
MCP (codebase-memory-mcp)	172,319	+127% flere, ikke 99% færre

measured_savings = 1 − 172,319 / 75,817 = −127.3%. Mekanismen er synlig i opgave-for-opgave-opdelingen ovenfor: agenten betalte for grafforespørgslen, opdagede, at den var forkert eller ufuldstændig, og betalte så igen for grep-ækvivalent-fallbacken for at få det rigtige svar. Graf plus grep koster mere end grep alene, hver gang grafen skal rettes — og på dette repo skulle den rettes i halvdelen af opgaverne.

Værd at hæfte sig ved: værktøjets egen markedsføring citerer "~500 tokens vs ~80K for grep" pr. forespørgsel. Hele vores 8-opgavers grep-only-kørsel kostede 75,817 tokens — mindre end den påståede omkostning for én grep-forespørgsel i deres materiale. Engangsindeksering (sekunder, udført én gang ved opsætning) er ekskluderet fra MCP-totalen ovenfor, hvilket er generøst over for værktøjet.

Ikke det memory-skill, du tænker på

Hvis "codebase-memory-mcp" og skills som memory-management eller claude-mem lyder, som om de løser det samme problem, gør de ikke. Session-memory-skills bevarer fakta og beslutninger på tværs af samtaler — det, du fortalte Claude i sidste uge, projektkontekst, der ellers ville forsvinde mellem sessioner. codebase-memory-mcp indekserer kodestruktur inden for et repo — call-graphs, import-kanter, definitioner — inden for én enkelt session. Begge kaldes "memory". Den ene er samtalekontinuitet, den anden er statisk analyse. Installer ikke dette i forventning om, at det husker din sidste session.

Forbehold, sagt ligeud

Vi vil hellere selv trække grænserne, end at du skal finde dem på den hårde måde:

• n=8 opgaver, ét repo. 157 filer, Astro/TypeScript — en blandet framework-opsætning tæt på worst case for en CALLS/IMPORTS-model, der skal ræsonnere om template-frontmatter sammen med script-filer.
• Deres arXiv-preprint testede 31 repos; vi testede ét. Det er fuldt ud plausibelt, at deres gennemsnit holder bedre på tværs af et bredere, mere rent TS/JS-udsnit, end vores ene blandede framework-repo repræsenterer.
• Store, rene TS/JS-monorepos kunne se anderledes ud. Hvor en naiv grep reelt returnerer et enormt output, og grafen har rene kanter at arbejde med (ingen .astro-frontmatter, ingen dynamiske imports), kunne token-matematikken plausibelt favorisere grafen. T5 og T7 — ren TypeScript, strukturelt simpelt — er præcis den type, og grafen vinder rent der også.
• Indekseringstid er ekskluderet fra MCP-totalen, hvilket favoriserer værktøjet, ikke baseline.

Reproducerbarhedsnote: de 8 opgaver blev skrevet og låst, før nogen af siderne kørte. Facit for hvert svar blev uafhængigt grep-verificeret mod repoet, ikke udledt af nogen af siders output. Begge sider kørte på samme Sonnet-model, samme repo-checkout, frisk kontekst hver gang.

Installer med åbne øjne

Brug det som en supplerende tracer på rene TS/JS-repos, hvor du har brug for hurtig call-chain-sporing eller definitionsopslag, og din kodebase ikke læner sig op ad dynamisk import(), type-only imports eller et templating-lag, grafen ikke kan parse. T5 og T7 viser præcis, hvad det er godt til.

Behandl ikke grafen som sandhedskilde på blandede framework-kodebaser. Hvis dit repo blander Astro, Vue, Svelte eller lignende templating med TypeScript, eller læner sig op ad dynamiske imports, så budgetter med, at værktøjet tager fejl specifikt på "hvem kalder dette" og "hvad er dead code"-forespørgsler — og budgetter med token-omkostningen for den fallback-grep, det får brug for til at rette sig selv.

FAQ

Er værktøjet dårligt? Nej. Installationen er ren, indekseringen er hurtig, og call-chain-sporing plus definitionsopslag i ren TypeScript er reelt fremragende. Problemet er snævrere end "værktøjet er dårligt": den centrale token-besparelsespåstand holder ikke på et blandet framework-repo, fordi grafens blinde vinkler tvinger agenten til at betale for både grafen og grep'en.

Hvorfor afviger jeres tal fra arXiv-papiret? Forskellig stikprøve. Deres preprint gennemsnitter over 31 repos; vi testede ét 157-fil Astro/TypeScript-repo, tæt på et worst case for deres kant-model (frontmatter-kald, dynamiske imports, type-only imports falder alle uden for CALLS/IMPORTS). Begge resultater kan være sande på samme tid — deres et bredere gennemsnit, vores et specifikt, reproducerbart worst-case-datapunkt, som alle på et blandet framework-repo bør veje, før de stoler på topmålet.

Skal jeg afinstallere det? Ikke nødvendigvis. Hvis du primært arbejder i ren TypeScript eller JavaScript uden tunge dynamiske imports, siger vores T5/T7-data, at det er en solid tracer. Hvis dit repo blander frameworks, som vores gør, så behold det installeret, men lad det ikke erstatte grep — behandl dets svar som en hypotese, der skal verificeres, ligesom vores MCP-agent endte med at gøre på halvdelen af opgaverne alligevel.

Hvad med meget store repos? Det testede vi ikke, og det er et reelt hul i vores data. Det teoretiske argument for værktøjet er stærkest der: én grep på tværs af et kæmpe monorepo kan returnere et enormt resultatsæt, mens en grafforespørgsel forbliver lille uanset repo-størrelse. Hvis du kører et stort, rent TS/JS-monorepo, er arXiv-papirets gennemsnit over 31 repos mere relevant for dig end vores ene lille-repo-resultat — men kør din egen A/B, før du stoler blindt på nogen af tallene.