codebase-memory-mcp: 127% più token, non il 99% in meno

codebase-memory-mcp, di DeusData, è diventato virale su TikTok questa settimana. È un singolo binario statico che indicizza un repository in un knowledge graph — 158 linguaggi, il kernel Linux indicizzato in tre minuti — e lo espone a Claude Code come server MCP. Il pitch è aggressivo: la descrizione su GitHub dice "99% fewer tokens", il README dice "120x fewer tokens — 5 structural queries: ~3,400 tokens vs ~412,000", e il loro preprint su arXiv (arXiv:2603.27277) riporta "10× fewer tokens, 83% answer quality" in media su 31 repository.

Facciamo passare ogni strumento che cataloghiamo attraverso un A/B controllato prima di assegnargli un punteggio. Quindi oggi (2026-07-11) abbiamo costruito un benchmark strutturale a 8 task, pre-registrando le domande e il ground truth prima di far girare entrambi i bracci, e abbiamo puntato sia un agente Sonnet con grep puro sia un agente Sonnet dotato di MCP sullo stesso repo. La correttezza è uscita in parità, 8/8 per entrambi. La promessa di punta sui token si è ribaltata: il braccio MCP ha usato 172,319 token contro i 75,817 della baseline — 127% in più, non 99% in meno.

Questa non è tutta la storia, e non pensiamo che dovrebbe esserlo. L'ingegneria sotto il cofano è genuinamente buona. Ecco cosa abbiamo trovato e perché il numero si è mosso in quel modo.

Cosa fa bene lo strumento

codebase-memory-mcp si installa come un singolo binario installabile via Homebrew, indicizza con un solo comando e ha prodotto JSON pulito al primo tentativo. Due degli otto task sono state vittorie nette per il grafo:

• T5 (tracciamento della catena di chiamate) — tracciare da un handler POST fino a un helper privato a tre hop di distanza, attraverso due percorsi possibili. trace_path(direction=outbound) ha restituito il DAG esatto in un'unica chiamata, corrispondente esattamente alla verifica manuale.
• T7 (ricerca della definizione) — "dove è definita formatDate". get_code_snippet ha restituito il file e la riga esatta di inizio/fine in un'unica chiamata, senza ambiguità.

Entrambe sono esattamente il tipo di query su cui un grafo dovrebbe dominare: TypeScript puro, struttura statica, nessun confine di framework di mezzo. Se il tuo repo è TS/JS puro e le tue domande somigliano a queste, lo strumento è veloce e preciso.

Dove si è rotto

Il nostro testbed era il nostro stesso repo: 157 file, Astro + TypeScript — una codebase multi-framework, che è vicina al caso peggiore per un indicizzatore a grafo costruito principalmente attorno a un modello di edge CALLS/IMPORTS. Quattro degli otto task hanno rivelato punti ciechi reali:

• T1 (chi chiama getSession) — trace_path(inbound) ha trovato solo 5 chiamanti su 7. Il grafo CALLS non cattura le chiamate fatte dal frontmatter .astro, quindi due chiamanti legittimi (admin.astro, account.astro) gli erano invisibili.
• T2 (import di purchases.ts) — il grafo IMPORTS ha restituito 2 statement di import su 3. Quello mancante era un import di solo tipo (import type { APIContext } from 'astro') — non tracciato come edge.
• T3 (trovare l'unico export morto) — la query di codice morto integrata nello strumento (max_degree=0) ha restituito da quattro a cinque falsi positivi: funzioni vive, chiamate dal frontmatter .astro che il grafo non riesce a vedere. Anche il flag is_exported del grafo era sbagliato su diverse funzioni (b64url, hmac, devStore, nameToSlug — tutte segnalate come esportate, nessuna delle quali ha effettivamente la keyword export nel sorgente). Per arrivare alla risposta corretta è stato necessario recuperare il sorgente completo di tutti e quattro i file e verificare manualmente ogni dichiarazione.
• T8 (impatto della cancellazione di store.ts) — il grafo IMPORTS ha trovato con precisione i 4 importatori statici, ma si è perso completamente tutti e 3 i punti di chiamata import() dinamici: uno dentro un helper devStore() in auth.ts, uno dentro submit.ts, uno nel frontmatter di account.astro. Gli import dinamici semplicemente non sono modellati come edge.

Il punteggio per task

Task	Domanda	BASE	MCP	Cosa è successo
T1	chi chiama getSession	1.0	1.0	Il grafo MCP ne ha trovati 5/7; ha recuperato 2 chiamanti .astro tramite il proprio fallback di ricerca testuale
T2	import di purchases.ts	1.0	1.0	Il grafo MCP ne ha trovati 2/3; si è perso l'import di solo tipo
T3	un export morto in src/lib/	1.0	1.0	La query di codice morto di MCP ha restituito 4–5 falsi positivi; necessaria verifica manuale completa del sorgente
T4	conteggio delle funzioni esportate	1.0	1.0	MCP ha contato dal sorgente grezzo perché i metadati is_exported non erano affidabili
T5	catena di chiamate, POST → b64url	1.0	1.0	Vittoria netta per il grafo — .ts puro, nessun confine di framework
T6	file con più statement di import	1.0	1.0	Il conteggio degli edge di MCP confondeva il per-simbolo con il per-statement; necessario un controllo incrociato con regex
T7	dove è definita formatDate	1.0	1.0	Vittoria netta — numero di riga esatto in un'unica chiamata
T8	impatto della cancellazione di store.ts	1.0	1.0	Il grafo MCP ne ha trovati 4/7; si è perso tutti e 3 i punti import() dinamici
Totale		8/8	8/8	MCP è ricorso alla propria ricerca testuale su 4 task su 8

Entrambi i bracci sono arrivati a risposte identiche e corrette per ogni domanda. Ma quella parità sta lavorando parecchio per sembrare rassicurante: l'agente MCP ha incontrato una risposta del grafo sbagliata o incompleta in metà dei task e ha dovuto accorgersene, per poi ricorrere a search_code — l'equivalente grep integrato nello strumento — per ricavare di nuovo la risposta corretta dal sorgente. Un agente che si fosse fidato della prima risposta del grafo senza quell'autocorrezione avrebbe ottenuto circa 4/8, sbagliando o senza supporto su T1, T3, T4 e T8.

La matematica dei token

Braccio	Token totali	vs. promessa
BASE (Read/Grep puro)	75,817	—
MCP (codebase-memory-mcp)	172,319	+127% in più, non 99% in meno

measured_savings = 1 − 172,319 / 75,817 = −127.3%. Il meccanismo è visibile nel dettaglio per task sopra: l'agente ha pagato per la query al grafo, ha scoperto che era sbagliata o incompleta, poi ha pagato di nuovo per il fallback equivalente a grep per ottenere la risposta reale. Grafo più grep costa più di grep da solo, ogni volta che il grafo va corretto — e su questo repo andava corretto in metà dei task.

Vale la pena rifletterci: il marketing dello strumento stesso cita "~500 tokens vs ~80K for grep" per query. L'intera nostra run a 8 task solo-grep è costata 75,817 token — meno del costo dichiarato di una singola query grep nei loro materiali. L'indicizzazione una tantum (pochi secondi, fatta una volta sola in fase di setup) è esclusa dal totale MCP sopra, il che è generoso verso lo strumento.

Non è lo skill di memoria a cui stai pensando

Se "codebase-memory-mcp" e skill come memory-management o claude-mem ti sembrano risolvere lo stesso problema, non è così. Gli skill di memoria di sessione persistono fatti e decisioni tra conversazioni diverse — quello che hai detto a Claude la settimana scorsa, il contesto di progetto che altrimenti sparirebbe tra una sessione e l'altra. codebase-memory-mcp indicizza la struttura del codice all'interno di un repo — grafi di chiamate, edge di import, definizioni — dentro una singola sessione. Entrambi vengono chiamati "memory". Uno è continuità della conversazione, l'altro è analisi statica. Non installarlo aspettandoti che si ricordi della tua ultima sessione.

Limiti, detti chiaramente

Preferiamo tracciare noi i confini piuttosto che farteli scoprire nel modo difficile:

• n=8 task, un repo. 157 file, Astro/TypeScript — una configurazione multi-framework vicina al caso peggiore per un modello CALLS/IMPORTS che deve ragionare sul frontmatter dei template insieme ai file di script.
• Il loro preprint su arXiv ha testato 31 repo; noi ne abbiamo testato uno. È del tutto plausibile che la loro media regga meglio su un campione più ampio e più TS/JS puro di quanto rappresenti il nostro singolo repo multi-framework.
• I grandi monorepo TS/JS puri potrebbero comportarsi diversamente. Dove un grep ingenuo restituisce davvero un output enorme e il grafo ha edge puliti con cui lavorare (nessun frontmatter .astro, nessun import dinamico), la matematica dei token potrebbe plausibilmente favorire il grafo. T5 e T7 — TypeScript puro, strutturalmente semplici — sono esattamente di quella forma, e anche lì il grafo vince nettamente.
• Il tempo di indicizzazione è escluso dal totale MCP, il che favorisce lo strumento, non la baseline.

Nota sulla riproducibilità: gli 8 task sono stati scritti e bloccati prima che entrambi i bracci girassero. Il ground truth per ogni risposta è stato verificato in modo indipendente via grep sul repo, non derivato dall'output di nessuno dei due bracci. Entrambi i bracci hanno girato sullo stesso modello Sonnet, sullo stesso checkout del repo, con contesto pulito ogni volta.

Installalo a occhi aperti

Usalo come tracciatore supplementare su repo TS/JS puri dove serve un tracciamento veloce delle catene di chiamate o ricerche di definizioni, e la tua codebase non fa affidamento su import() dinamici, import di solo tipo o un layer di templating che il grafo non riesce a interpretare. T5 e T7 mostrano esattamente in cosa è bravo.

Non trattare il suo grafo come fonte di verità su codebase multi-framework. Se il tuo repo mescola Astro, Vue, Svelte o un templating simile con TypeScript, o fa affidamento su import dinamici, metti in conto che lo strumento sbagli in particolare sulle query "chi chiama questo" e "cos'è codice morto" — e metti in conto il costo in token del grep di fallback che servirà per autocorreggersi.

FAQ

Lo strumento è scadente? No. L'installazione è pulita, l'indicizzazione è veloce, e il tracciamento delle catene di chiamate più la ricerca delle definizioni in TypeScript puro sono genuinamente eccellenti. Il problema è più circoscritto di "lo strumento è scadente": la promessa di punta sul risparmio di token non regge su un repo multi-framework, perché i punti ciechi del grafo costringono l'agente a pagare sia il grafo sia il grep.

Perché i vostri numeri differiscono dal paper su arXiv? Campione diverso. Il loro preprint fa una media su 31 repo; noi ne abbiamo testato uno solo, 157 file, Astro/TypeScript, vicino a un caso peggiore per il loro modello di edge (chiamate nel frontmatter, import dinamici, import di solo tipo cadono tutti fuori da CALLS/IMPORTS). Entrambi i risultati possono essere veri contemporaneamente — il loro è una media più ampia, il nostro è un punto dato specifico e riproducibile del caso peggiore, che chiunque lavori su un repo multi-framework dovrebbe soppesare prima di fidarsi del numero da titolo.

Dovrei disinstallarlo? Non necessariamente. Se lavori principalmente in TypeScript o JavaScript puro senza import dinamici pesanti, i nostri dati T5/T7 dicono che è un tracciatore solido. Se il tuo repo mescola framework come il nostro, tienilo installato ma non lasciare che sostituisca grep — tratta le sue risposte come un'ipotesi da verificare, proprio come ha finito per fare il nostro agente MCP in metà dei task comunque.

E i repo molto grandi? Non ne abbiamo testato uno, ed è una lacuna reale nei nostri dati. È lì che l'argomento teorico a favore dello strumento è più forte: un singolo grep su un monorepo enorme può restituire un result set gigantesco, mentre una query al grafo resta piccola indipendentemente dalla dimensione del repo. Se gestisci un grande monorepo TS/JS puro, la media su 31 repo del paper arXiv è più rilevante per te del nostro singolo risultato su repo piccolo — ma fai il tuo A/B prima di fidarti ciecamente di uno dei due numeri.