codebase-memory-mcp: 127% fler tokens, inte 99% färre

codebase-memory-mcp, från DeusData, gick viralt på TikTok den här veckan. Det är en enda statisk binär som indexerar ett repo till en knowledge graph — 158 språk, Linux-kärnan indexerad på tre minuter — och exponerar den för Claude Code som en MCP-server. Löftet är aggressivt: GitHub-beskrivningen säger "99% fewer tokens," README:n säger "120x fewer tokens — 5 structural queries: ~3,400 tokens vs ~412,000," och deras arXiv-preprint (arXiv:2603.27277) rapporterar "10× fewer tokens, 83% answer quality" i genomsnitt över 31 repon.

Vi kör varje verktyg vi katalogiserar genom en kontrollerad A/B-test innan vi poängsätter det. Så idag (2026-07-11) byggde vi en strukturell benchmark med 8 uppgifter, förregistrerade frågorna och facit innan någon av armarna kördes, och riktade både en Sonnet-agent med ren grep och en MCP-utrustad Sonnet-agent mot samma repo. Korrektheten blev oavgjord, 8/8 båda. Flaggskeppspåståendet om tokens vändes: MCP-armen använde 172 319 tokens mot baslinjens 75 817 — 127% mer, inte 99% färre.

Det är inte hela historien, och vi tycker inte att det borde vara det. Ingenjörskonsten under ytan är genuint bra. Det här är vad vi hittade och varför siffran rörde sig som den gjorde.

Vad verktyget gör bra

codebase-memory-mcp installeras som en enda Homebrew-installerbar binär, indexerar med ett kommando, och producerade ren JSON på första försöket. Två av våra åtta uppgifter var tydliga vinster för grafen:

• T5 (call-chain-spårning) — spårning från en POST-hanterare ner till en privat hjälpfunktion tre hopp djupt, genom två möjliga vägar. trace_path(direction=outbound) returnerade exakt DAG i ett anrop, i exakt överensstämmelse med manuell verifiering.
• T7 (definitionsuppslag) — "var är formatDate definierad." get_code_snippet returnerade filen och den exakta start-/slutraden i ett anrop, utan tvetydighet.

Båda dessa är exakt den typ av fråga en graf borde dominera på: ren TypeScript, statisk struktur, ingen ramverksgräns i vägen. Om ditt repo är rent TS/JS och dina frågor ser ut så här är verktyget snabbt och precist.

Var det brast

Vår testmiljö var vårt eget repo: 157 filer, Astro + TypeScript — en kodbas med blandade ramverk, vilket ligger nära ett värsta scenario för en grafindexerare byggd primärt kring en CALLS/IMPORTS-kantmodell. Fyra av de åtta uppgifterna avslöjade verkliga blinda fläckar:

• T1 (vem anropar getSession) — trace_path(inbound) hittade bara 5 av 7 anropare. CALLS-grafen fångar inte anrop gjorda från .astro-frontmatter, så två legitima anropare (admin.astro, account.astro) var osynliga för den.
• T2 (imports av purchases.ts) — IMPORTS-grafen returnerade 2 av 3 importsatser. Den saknade var en type-only-import (import type { APIContext } from 'astro') — inte spårad som en kant.
• T3 (hitta den enda döda exporten) — verktygets egen dead-code-fråga (max_degree=0) returnerade fyra till fem falska positiva: funktioner som lever, anropade från .astro-frontmatter som grafen inte kan se. Grafens is_exported-flagga var också fel på flera funktioner (b64url, hmac, devStore, nameToSlug — alla flaggade som exporterade, ingen av dem har faktiskt ett export-nyckelord i källkoden). Att få rätt svar krävde att hämta fullständig källkod för alla fyra filer och manuellt verifiera varje deklaration.
• T8 (konsekvens av att ta bort store.ts) — IMPORTS-grafen hittade de 4 statiska importörerna rent, men missade alla 3 dynamiska import()-anropsställen helt: ett inuti en devStore()-hjälpfunktion i auth.ts, ett inuti submit.ts, ett inuti account.astro-frontmatter. Dynamiska imports modelleras helt enkelt inte som kanter.

Poängställning per uppgift

Uppgift	Fråga	BASE	MCP	Vad som hände
T1	vem anropar getSession	1.0	1.0	MCP-grafen hittade 5/7; återfann 2 .astro-anropare via sin egen textsöknings-fallback
T2	imports av purchases.ts	1.0	1.0	MCP-grafen hittade 2/3; missade type-only-importen
T3	en död export i src/lib/	1.0	1.0	MCP:s dead-code-fråga returnerade 4–5 falska positiva; krävde fullständig manuell källkodsverifiering
T4	antal exporterade funktioner	1.0	1.0	MCP räknade från rå källkod eftersom is_exported-metadata var opålitlig
T5	call chain, POST → b64url	1.0	1.0	Ren vinst för grafen — ren .ts, ingen ramverksgräns
T6	fil med flest importsatser	1.0	1.0	MCP:s kanträkning blandade ihop per-symbol med per-statement; krävde en regex-korskontroll
T7	var är formatDate definierad	1.0	1.0	Ren vinst — exakt radnummer i ett anrop
T8	konsekvens av att ta bort store.ts	1.0	1.0	MCP-grafen hittade 4/7; missade alla 3 dynamiska import()-ställen
Totalt		8/8	8/8	MCP föll tillbaka på sin egen textsökning i 4 av 8 uppgifter

Båda armarna landade på identiska, korrekta svar på varje fråga. Men den pariteten gör mycket jobb för att se betryggande ut: MCP-agenten fick ett felaktigt eller ofullständigt grafsvar på hälften av uppgifterna och var tvungen att märka det, och sedan fly in i search_code — verktygets inbyggda grep-motsvarighet — för att åter härleda det korrekta svaret från källkoden. En agent som litat på grafens första svar utan den självkorrigeringen skulle ha fått ungefär 4/8, fel eller ostött på T1, T3, T4 och T8.

Tokenmatematiken

Arm	Totalt antal tokens	jämfört med påstående
BASE (ren Read/Grep)	75 817	—
MCP (codebase-memory-mcp)	172 319	+127% mer, inte 99% färre

measured_savings = 1 − 172,319 / 75,817 = −127.3%. Mekanismen syns i uppdelningen per uppgift ovan: agenten betalade för grafsökningen, upptäckte att den var fel eller ofullständig, och betalade sedan igen för grep-motsvarighetens fallback för att få det verkliga svaret. Graf plus grep kostar mer än grep ensamt, varje gång grafen behöver korrigeras — och i det här repot behövde den korrigeras i hälften av uppgifterna.

Värt att stanna vid: verktygets egen marknadsföring anger "~500 tokens vs ~80K for grep" per fråga. Hela vår 8-uppgifters körning med enbart grep kostade 75 817 tokens — mindre än den påstådda kostnaden för en enda grep-fråga i deras material. Engångsindexeringen (sekunder, görs en gång vid uppsättning) är exkluderad från MCP-totalen ovan, vilket är generöst mot verktyget.

Inte minnesskillen du tänker på

Om "codebase-memory-mcp" och skills som memory-management eller claude-mem låter som att de löser samma problem, gör de inte det. Sessionsminnesskills bevarar fakta och beslut mellan konversationer — vad du sa till Claude förra veckan, projektkontext som annars skulle försvinna mellan sessioner. codebase-memory-mcp indexerar kodstruktur inom ett repo — anropsgrafer, importkanter, definitioner — inom en enda session. Båda kallas "minne." Den ena är konversationskontinuitet, den andra är statisk analys. Installera inte det här i förväntan att det ska minnas din senaste session.

Förbehåll, uttryckta rakt på sak

Vi föredrar att dra gränserna själva än att du ska hitta dem på det svåra sättet:

• n=8 uppgifter, ett repo. 157 filer, Astro/TypeScript — en uppsättning med blandade ramverk nära värsta scenariot för en CALLS/IMPORTS-modell som måste resonera om mallars frontmatter vid sidan av skriptfiler.
• Deras arXiv-preprint testade 31 repon; vi testade ett. Det är fullt möjligt att deras genomsnitt håller bättre över ett bredare, mer rent TS/JS-urval än vårt enda repo med blandade ramverk representerar.
• Stora, rena TS/JS-monorepon skulle kunna se annorlunda ut. Där en naiv grep genuint returnerar enorm utdata och grafen har rena kanter att jobba med (ingen .astro-frontmatter, inga dynamiska imports) skulle tokenmatematiken rimligen kunna gynna grafen. T5 och T7 — ren TypeScript, strukturellt enkla — är exakt den formen, och grafen vinner rent även där.
• Indexeringstiden är exkluderad från MCP-totalen, vilket gynnar verktyget, inte baslinjen.

Reproducerbarhetsnotering: de 8 uppgifterna skrevs och låstes innan någon av armarna kördes. Facit för varje svar grep-verifierades oberoende mot repot, inte härlett från någon av armarnas utdata. Båda armarna kördes på samma Sonnet-modell, samma repo-checkout, färsk kontext varje gång.

Installera med öppna ögon

Använd det som en kompletterande spårare på rena TS/JS-repon där du behöver snabb call-chain-spårning eller definitionsuppslag och din kodbas inte lutar sig mot dynamiska import(), type-only-imports eller ett mallningslager grafen inte kan tolka. T5 och T7 visar exakt vad det är bra på.

Behandla inte dess graf som sanningskälla i kodbaser med blandade ramverk. Om ditt repo blandar Astro, Vue, Svelte eller liknande mallning med TypeScript, eller lutar sig mot dynamiska imports, räkna med att verktyget har fel specifikt på frågor om "vem anropar det här" och "vad är död kod" — och räkna med tokenkostnaden för den fallback-grep det kommer behöva för att korrigera sig själv.

FAQ

Är verktyget dåligt? Nej. Installationen är ren, indexeringen är snabb, och call-chain-spårning plus definitionsuppslag i ren TypeScript är genuint utmärkta. Problemet är smalare än "verktyget är dåligt": flaggskeppspåståendet om tokenbesparingar håller inte i ett repo med blandade ramverk, eftersom grafens blinda fläckar tvingar agenten att betala för både grafen och grepen.

Varför skiljer sig era siffror från arXiv-artikeln? Olika urval. Deras preprint är ett genomsnitt över 31 repon; vi testade ett repo med 157 filer, Astro/TypeScript, nära ett värsta scenario för deras kantmodell (frontmatter-anrop, dynamiska imports, type-only-imports faller alla utanför CALLS/IMPORTS). Båda resultaten kan vara sanna samtidigt — deras ett bredare genomsnitt, vårt en specifik, reproducerbar värsta-scenario-datapunkt som vem som helst med ett repo med blandade ramverk bör väga innan de litar på huvudsiffran.

Bör jag avinstallera det? Inte nödvändigtvis. Om du huvudsakligen jobbar i ren TypeScript eller JavaScript utan tunga dynamiska imports säger vår T5/T7-data att det är en solid spårare. Om ditt repo blandar ramverk på samma sätt som vårt, behåll installationen men låt det inte ersätta grep — behandla dess svar som en hypotes att verifiera, precis som vår MCP-agent ändå slutade göra på hälften av uppgifterna.

Hur är det med väldigt stora repon? Vi testade inte något, och det är en verklig lucka i vår data. Det teoretiska argumentet för verktyget är starkast där: en enda grep över ett enormt monorepo kan returnera en gigantisk resultatmängd, medan en graffråga förblir liten oavsett repostorlek. Om du kör ett stort, rent TS/JS-monorepo är arXiv-artikelns genomsnitt över 31 repon mer relevant för dig än vårt enda resultat från ett litet repo — men kör din egen A/B innan du litar blint på någon av siffrorna.