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

codebase-memory-mcp, fra DeusData, gikk viralt på TikTok denne uken. Det er én enkelt statisk binærfil som indekserer et repository til en knowledge graph — 158 språk, Linux-kjernen indeksert på tre minutter — og eksponerer den til Claude Code som en MCP-server. Pitchen er aggressiv: GitHub-beskrivelsen sier «99% fewer tokens», README-en sier «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 snitt over 31 repoer.

Vi kjører hvert verktøy vi katalogiserer gjennom en kontrollert A/B før vi scorer det. Så i dag (2026-07-11) bygde vi en 8-oppgavers strukturell benchmark, forhåndsregistrerte spørsmålene og fasiten før noen av armene kjørte, og satte både en ren-grep Sonnet-agent og en MCP-utstyrt Sonnet-agent på samme repo. Korrektheten endte likt, 8/8 begge. Den fremste tokenpåstanden snudde: MCP-armen brukte 172,319 tokens mot baselinens 75,817 — 127% flere, ikke 99% færre.

Det er ikke hele historien, og vi mener den ikke bør være det heller. Ingeniørarbeidet under panseret er genuint bra. Dette er hva vi fant, og hvorfor tallet beveget seg slik det gjorde.

Hva verktøyet gjør bra

codebase-memory-mcp installeres som én enkelt Homebrew-installerbar binærfil, indekserer med én kommando, og produserte ren JSON på første forsøk. To av våre åtte oppgaver var klare seire for grafen:

• T5 (call-chain-sporing) — sporing fra en POST-handler ned til en privat hjelpefunksjon tre hopp dypt, gjennom to mulige stier. trace_path(direction=outbound) returnerte den eksakte DAG-en i ett kall, og matchet manuell verifisering nøyaktig.
• T7 (definisjonsoppslag) — «hvor er formatDate definert». get_code_snippet returnerte filen og den nøyaktige start-/sluttlinjen i ett kall, uten tvetydighet.

Begge disse er nøyaktig den typen spørring en graf burde dominere: ren TypeScript, statisk struktur, ingen rammeverksgrense i veien. Hvis repoet ditt er ren TS/JS og spørsmålene dine ligner disse, er verktøyet raskt og presist.

Hvor det brøt sammen

Testbenken vår var vårt eget repo: 157 filer, Astro + TypeScript — en kodebase med blandede rammeverk, som er nær et verste tilfelle for en grafindekserer bygget primært rundt en CALLS/IMPORTS-kant-modell. Fire av de åtte oppgavene avdekket reelle blindsoner:

• T1 (hvem kaller getSession) — trace_path(inbound) fant bare 5 av 7 kallere. CALLS-grafen fanger ikke opp kall gjort fra .astro-frontmatter, så to legitime kallere (admin.astro, account.astro) var usynlige for den.
• T2 (imports av purchases.ts) — IMPORTS-grafen returnerte 2 av 3 import-setninger. Den manglende var en type-only-import (import type { APIContext } from 'astro') — ikke sporet som en kant.
• T3 (finn den ene døde eksporten) — verktøyets egen dead-code-spørring (max_degree=0) returnerte fire til fem falske positiver: funksjoner som er i bruk, kalt fra .astro-frontmatter som grafen ikke kan se. Grafens is_exported-flagg var også feil på flere funksjoner (b64url, hmac, devStore, nameToSlug — alle flagget som eksportert, ingen av dem har faktisk et export-nøkkelord i kildekoden). Å finne riktig svar krevde å hente full kildekode for alle fire filene og manuelt verifisere hver deklarasjon.
• T8 (konsekvens av å slette store.ts) — IMPORTS-grafen fant de 4 statiske importørene rent, men bommet fullstendig på alle 3 dynamiske import()-kallsteder: ett inni en devStore()-hjelpefunksjon i auth.ts, ett inni submit.ts, ett inni account.astro-frontmatter. Dynamiske imports er rett og slett ikke modellert som kanter.

Poengtavlen per oppgave

Oppgave	Spørsmål	BASE	MCP	Hva skjedde
T1	hvem kaller getSession	1.0	1.0	MCP-grafen fant 5/7; hentet inn 2 .astro-kallere via sitt eget tekstsøk-fallback
T2	imports av purchases.ts	1.0	1.0	MCP-grafen fant 2/3; bommet på type-only-importen
T3	én død eksport i src/lib/	1.0	1.0	MCPs dead-code-spørring returnerte 4–5 falske positiver; krevde full manuell kildekodeverifisering
T4	antall eksporterte funksjoner	1.0	1.0	MCP telte fra rå kildekode fordi is_exported-metadataen var upålitelig
T5	kallkjede, POST → b64url	1.0	1.0	Ren seier for grafen — ren .ts, ingen rammeverksgrense
T6	filen med flest import-setninger	1.0	1.0	MCPs kanttelling blandet sammen per-symbol med per-setning; krevde en regex-kryssjekk
T7	hvor er formatDate definert	1.0	1.0	Ren seier — eksakt linjenummer i ett kall
T8	konsekvens av å slette store.ts	1.0	1.0	MCP-grafen fant 4/7; bommet på alle 3 dynamiske import()-steder
Totalt		8/8	8/8	MCP falt tilbake på sitt eget tekstsøk på 4 av 8 oppgaver

Begge armene landet på identiske, korrekte svar på hvert spørsmål. Men den parallelliteten gjør mye arbeid for å se betryggende ut: MCP-agenten traff et feil eller ufullstendig grafsvar på halvparten av oppgavene og måtte oppdage det, for deretter å rømme inn i search_code — verktøyets innebygde grep-ekvivalent — for å utlede det korrekte svaret på nytt fra kildekoden. En agent som stolte på grafens første svar uten den selvkorrigeringen, ville ha scoret rundt 4/8, feil eller ubegrunnet på T1, T3, T4 og T8.

Tokenregnestykket

Arm	Tokens totalt	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 oppgave-for-oppgave-nedbrytningen over: agenten betalte for grafspørringen, oppdaget at den var feil eller ufullstendig, og betalte deretter på nytt for grep-ekvivalent-fallbacken for å få det virkelige svaret. Graf pluss grep koster mer enn grep alene, hver gang grafen trenger korrigering — og på dette repoet trengte den korrigering på halvparten av oppgavene.

Verdt å dvele ved: verktøyets egen markedsføring siterer «~500 tokens vs ~80K for grep» per spørring. Hele vår 8-oppgavers rene grep-kjøring kostet 75,817 tokens — mindre enn den påståtte kostnaden for én enkelt grep-spørring i deres materiale. Engangs-indeksering (sekunder, gjort én gang ved oppsett) er ekskludert fra MCP-totalen over, noe som er sjenerøst overfor verktøyet.

Ikke minne-skillen du tenker på

Hvis «codebase-memory-mcp» og skills som memory-management eller claude-mem høres ut som de løser det samme problemet, gjør de ikke det. Sesjonsminne-skills bevarer fakta og beslutninger på tvers av samtaler — det du fortalte Claude forrige uke, prosjektkontekst som ellers ville forsvunnet mellom sesjoner. codebase-memory-mcp indekserer kodestruktur i et repo — kallgrafer, import-kanter, definisjoner — innenfor én enkelt sesjon. Begge kalles «minne». Den ene er samtalekontinuitet, den andre er statisk analyse. Ikke installer denne i forventning om at den skal huske forrige sesjon.

Forbehold, sagt rett ut

Vi vil heller trekke grensene selv enn å la deg finne dem på den harde måten:

• n=8 oppgaver, ett repo. 157 filer, Astro/TypeScript — et oppsett med blandede rammeverk nær verste tilfelle for en CALLS/IMPORTS-modell som må resonnere om template-frontmatter ved siden av skriptfiler.
• Deres arXiv-preprint testet 31 repoer; vi testet ett. Det er fullt mulig at deres gjennomsnitt holder seg bedre over et bredere, mer rent TS/JS-utvalg enn vårt ene blandede-rammeverk-repo representerer.
• Store, rent TS/JS-monorepoer kan se annerledes ut. Der en naiv grep genuint returnerer enorm output og grafen har rene kanter å jobbe med (ingen .astro-frontmatter, ingen dynamiske imports), kan tokenregnestykket plausibelt favorisere grafen. T5 og T7 — ren TypeScript, strukturelt enkelt — er nøyaktig den formen, og grafen vinner rent der også.
• Indekseringstid er ekskludert fra MCP-totalen, noe som favoriserer verktøyet, ikke baseline.

Reproduserbarhetsnotat: de 8 oppgavene ble skrevet og låst før noen av armene kjørte. Fasit for hvert svar ble uavhengig grep-verifisert mot repoet, ikke utledet fra noen av armenes output. Begge armene kjørte på samme Sonnet-modell, samme repo-checkout, med fersk kontekst hver gang.

Installer med øynene åpne

Bruk det som en supplerende sporer på rene TS/JS-repoer der du trenger rask call-chain-sporing eller definisjonsoppslag, og kodebasen din ikke lener seg på dynamisk import(), type-only-imports, eller et templating-lag grafen ikke kan parse. T5 og T7 viser nøyaktig hva den er god til.

Ikke behandle grafen dens som sannhetskilde på kodebaser med blandede rammeverk. Hvis repoet ditt blander Astro, Vue, Svelte, eller lignende templating med TypeScript, eller lener seg på dynamiske imports, må du budsjettere med at verktøyet tar feil spesifikt på «hvem kaller dette»- og «hva er død kode»-spørringer — og budsjettere med tokenkostnaden for fallback-grepen den vil trenge for å korrigere seg selv.

FAQ

Er verktøyet dårlig? Nei. Installasjonen er ren, indekseringen er rask, og call-chain-sporing pluss definisjonsoppslag i ren TypeScript er genuint utmerket. Problemet er smalere enn «verktøyet er dårlig»: den fremste token-besparelsespåstanden holder ikke på et repo med blandede rammeverk, fordi grafens blindsoner tvinger agenten til å betale for både grafen og grepen.

Hvorfor er tallene deres forskjellige fra arXiv-artikkelen? Forskjellig utvalg. Deres preprint tar gjennomsnitt over 31 repoer; vi testet ett 157-fils Astro/TypeScript-repo, nær et verste tilfelle for kant-modellen deres (frontmatter-kall, dynamiske imports, type-only-imports faller alle utenfor CALLS/IMPORTS). Begge resultatene kan være sanne samtidig — deres er et bredere gjennomsnitt, vårt er et spesifikt, reproduserbart verste-tilfelle-datapunkt som alle på et repo med blandede rammeverk bør veie før de stoler på hovedtallet.

Bør jeg avinstallere det? Ikke nødvendigvis. Hvis du hovedsakelig jobber i ren TypeScript eller JavaScript uten tunge dynamiske imports, sier vår T5/T7-data at det er en solid sporer. Hvis repoet ditt blander rammeverk slik vårt gjør, behold det installert, men ikke la det erstatte grep — behandle svarene som en hypotese å verifisere, slik vår MCP-agent endte opp med å gjøre på halvparten av oppgavene uansett.

Hva med veldig store repoer? Vi testet ikke ett, og det er et reelt hull i dataene våre. Det teoretiske argumentet for verktøyet er sterkest der: én enkelt grep over et enormt monorepo kan returnere et enormt resultatsett, mens en grafspørring holder seg liten uansett repostørrelse. Hvis du drifter et stort, rent TS/JS-monorepo, er arXiv-artikkelens 31-repo-gjennomsnitt mer relevant for deg enn vårt ene lille-repo-resultat — men kjør din egen A/B før du stoler blindt på noen av tallene.