codebase-memory-mcp: 127 % mehr Tokens, nicht 99 % weniger

codebase-memory-mcp von DeusData ging diese Woche auf TikTok viral. Es ist ein einzelnes statisches Binary, das ein Repository in einen Knowledge-Graph indexiert — 158 Sprachen, der Linux-Kernel in drei Minuten indexiert — und ihn Claude Code als MCP-Server zur Verfügung stellt. Das Versprechen ist aggressiv: Die GitHub-Beschreibung sagt „99 % weniger Tokens", die README sagt „120x weniger Tokens – 5 strukturelle Queries: ~3.400 Tokens vs. ~412.000", und ihr arXiv-Preprint (arXiv:2603.27277) berichtet „10× weniger Tokens, 83 % Antwortqualität" gemittelt über 31 Repos.

Jedes Tool, das wir katalogisieren, läuft bei uns durch einen kontrollierten A/B-Test, bevor wir es bewerten. Also haben wir heute (2026-07-11) einen 8-Aufgaben-Struktur-Benchmark gebaut, Fragen und Ground Truth vorregistriert, bevor einer der beiden Arme lief, und sowohl einen reinen-grep-Sonnet-Agenten als auch einen MCP-ausgestatteten Sonnet-Agenten auf dasselbe Repo angesetzt. Die Korrektheit kam gleichauf heraus, 8/8 in beiden. Die Flaggschiff-Token-Behauptung kehrte sich um: Der MCP-Arm verbrauchte 172.319 Tokens gegenüber den 75.817 der Baseline — 127 % mehr, nicht 99 % weniger.

Das ist nicht die ganze Geschichte, und wir finden auch nicht, dass sie es sein sollte. Das Engineering dahinter ist wirklich gut. Hier ist, was wir gefunden haben und warum sich die Zahl so bewegt hat, wie sie es tat.

Was das Tool gut macht

codebase-memory-mcp installiert sich als einzelnes, per Homebrew installierbares Binary, indexiert mit einem einzigen Befehl und lieferte beim ersten Versuch sauberes JSON. Zwei unserer acht Aufgaben waren klare Siege für den Graphen:

• T5 (Call-Chain-Trace) — das Tracing von einem POST-Handler bis zu einem privaten Helper drei Hops tief, über zwei mögliche Pfade. trace_path(direction=outbound) lieferte den exakten DAG in einem einzigen Aufruf, exakt übereinstimmend mit der manuellen Verifikation.
• T7 (Definitionssuche) — „Wo ist formatDate definiert." get_code_snippet lieferte die Datei und die genaue Start-/End-Zeile in einem einzigen Aufruf, ohne Mehrdeutigkeit.

Beide sind genau die Art von Query, bei der ein Graph dominieren sollte: reines TypeScript, statische Struktur, keine Framework-Grenze im Weg. Wenn dein Repo reines TS/JS ist und deine Fragen so aussehen, ist das Tool schnell und präzise.

Wo es versagte

Unsere Testumgebung war unser eigenes Repo: 157 Dateien, Astro + TypeScript — eine Mixed-Framework-Codebase, die für einen Graph-Indexer, der primär um ein CALLS/IMPORTS-Kantenmodell herum gebaut ist, nahe an einem Worst Case liegt. Vier der acht Aufgaben legten echte blinde Flecken offen:

• T1 (wer ruft getSession auf) — trace_path(inbound) fand nur 5 von 7 Aufrufern. Der CALLS-Graph erfasst keine Aufrufe aus .astro-Frontmatter, sodass zwei legitime Aufrufer (admin.astro, account.astro) für ihn unsichtbar waren.
• T2 (Imports von purchases.ts) — der IMPORTS-Graph lieferte 2 von 3 Import-Statements. Das fehlende war ein typreiner Import (import type { APIContext } from 'astro') — als Kante nicht erfasst.
• T3 (den einen toten Export finden) — die eigene Dead-Code-Query des Tools (max_degree=0) lieferte vier bis fünf False Positives: Funktionen, die live sind, aufgerufen aus .astro-Frontmatter, das der Graph nicht sehen kann. Das is_exported-Flag des Graphen war zudem bei mehreren Funktionen falsch (b64url, hmac, devStore, nameToSlug — alle als exportiert markiert, obwohl keine davon im Quellcode tatsächlich ein export-Schlüsselwort hat). Um die richtige Antwort zu bekommen, mussten wir den vollständigen Quellcode aller vier Dateien ziehen und jede Deklaration manuell verifizieren.
• T8 (Auswirkung des Löschens von store.ts) — der IMPORTS-Graph fand die 4 statischen Importer sauber, verpasste aber alle 3 dynamischen import()-Aufrufstellen komplett: eine innerhalb eines devStore()-Helpers in auth.ts, eine innerhalb von submit.ts, eine innerhalb der account.astro-Frontmatter. Dynamische Imports werden schlicht nicht als Kanten modelliert.

Die Punktetabelle pro Aufgabe

Aufgabe	Frage	BASE	MCP	Was passiert ist
T1	wer ruft getSession auf	1,0	1,0	MCP-Graph fand 5/7; hat 2 .astro-Aufrufer über den eigenen Textsuche-Fallback nachgeholt
T2	Imports von purchases.ts	1,0	1,0	MCP-Graph fand 2/3; verpasste den typreinen Import
T3	ein toter Export in src/lib/	1,0	1,0	MCPs Dead-Code-Query lieferte 4–5 False Positives; brauchte vollständige manuelle Quellcode-Verifikation
T4	Anzahl exportierter Funktionen	1,0	1,0	MCP zählte aus dem Rohquellcode, weil die is_exported-Metadaten unzuverlässig waren
T5	Call-Chain, POST → b64url	1,0	1,0	Klarer Sieg für den Graphen — reines .ts, keine Framework-Grenze
T6	Datei mit den meisten Import-Statements	1,0	1,0	MCPs Kantenzählung vermischte pro Symbol mit pro Statement; brauchte einen Regex-Gegencheck
T7	wo ist formatDate definiert	1,0	1,0	Klarer Sieg — exakte Zeilennummer in einem Aufruf
T8	Auswirkung des Löschens von store.ts	1,0	1,0	MCP-Graph fand 4/7; verpasste alle 3 dynamischen import()-Stellen
Gesamt		8/8	8/8	MCP griff bei 4 von 8 Aufgaben auf die eigene Textsuche zurück

Beide Arme landeten bei jeder Frage auf identischen, korrekten Antworten. Aber diese Parität leistet eine Menge Arbeit, um beruhigend zu wirken: Der MCP-Agent stieß bei der Hälfte der Aufgaben auf eine falsche oder unvollständige Graph-Antwort, musste das bemerken und dann in search_code ausweichen — das eingebaute grep-Äquivalent des Tools —, um die korrekte Antwort erneut aus dem Quellcode herzuleiten. Ein Agent, der der ersten Antwort des Graphen ohne diese Selbstkorrektur vertraut hätte, wäre auf etwa 4/8 gekommen, falsch oder unbelegt bei T1, T3, T4 und T8.

Die Token-Rechnung

Arm	Tokens gesamt	vs. Behauptung
BASE (reines Read/Grep)	75.817	—
MCP (codebase-memory-mcp)	172.319	+127 % mehr, nicht 99 % weniger

measured_savings = 1 − 172,319 / 75,817 = −127.3%. Der Mechanismus ist in der Aufschlüsselung pro Aufgabe oben sichtbar: Der Agent zahlte für die Graph-Query, stellte fest, dass sie falsch oder unvollständig war, und zahlte dann erneut für den grep-äquivalenten Fallback, um die echte Antwort zu bekommen. Graph plus grep kostet mehr als grep allein, jedes Mal, wenn der Graph korrigiert werden muss — und auf diesem Repo musste er bei der Hälfte der Aufgaben korrigiert werden.

Zum Nachdenken: Das eigene Marketing des Tools zitiert „~500 Tokens vs. ~80K für grep" pro Query. Unser gesamter reiner-grep-Lauf über 8 Aufgaben kostete 75.817 Tokens — weniger als die behaupteten Kosten einer einzigen grep-Query in ihren Materialien. Die einmalige Indexierung (Sekunden, einmalig beim Setup) ist aus der oben genannten MCP-Gesamtsumme ausgenommen, was großzügig gegenüber dem Tool ist.

Nicht der Memory-Skill, an den du denkst

Wenn sich „codebase-memory-mcp" und Skills wie memory-management oder claude-mem so anhören, als würden sie dasselbe Problem lösen — tun sie nicht. Session-Memory-Skills speichern Fakten und Entscheidungen über Unterhaltungen hinweg dauerhaft — was du Claude letzte Woche gesagt hast, Projektkontext, der sonst zwischen Sessions verloren ginge. codebase-memory-mcp indexiert Code-Struktur innerhalb eines Repos — Call-Graphen, Import-Kanten, Definitionen — innerhalb einer einzelnen Session. Beide werden „Memory" genannt. Das eine ist Gesprächskontinuität, das andere ist statische Analyse. Installier das hier nicht in der Erwartung, dass es sich an deine letzte Session erinnert.

Einschränkungen, unverblümt gesagt

Wir ziehen die Grenzen lieber selbst, als dass du sie auf die harte Tour findest:

• n=8 Aufgaben, ein Repo. 157 Dateien, Astro/TypeScript — ein Mixed-Framework-Setup nahe am Worst Case für ein CALLS/IMPORTS-Modell, das neben Skript-Dateien auch über Template-Frontmatter urteilen muss.
• Ihr arXiv-Preprint hat 31 Repos getestet, wir eines. Es ist durchaus plausibel, dass sich ihr Durchschnitt über eine breitere, stärker reine TS/JS-Stichprobe besser hält als das, was unser einzelnes Mixed-Framework-Repo repräsentiert.
• Große, rein TS/JS-basierte Monorepos könnten anders aussehen. Wo ein naives grep tatsächlich riesigen Output zurückgibt und der Graph mit sauberen Kanten arbeiten kann (keine .astro-Frontmatter, keine dynamischen Imports), könnte die Token-Rechnung plausibel zugunsten des Graphen ausfallen. T5 und T7 — reines TypeScript, strukturell simpel — sind genau diese Form, und dort gewinnt der Graph auch klar.
• Die Indexierungszeit ist aus der MCP-Gesamtsumme ausgenommen, was dem Tool zugutekommt, nicht der Baseline.

Hinweis zur Reproduzierbarkeit: Die 8 Aufgaben wurden geschrieben und fixiert, bevor einer der beiden Arme lief. Die Ground Truth für jede Antwort wurde unabhängig per grep gegen das Repo verifiziert, nicht aus dem Output eines der Arme abgeleitet. Beide Arme liefen auf demselben Sonnet-Modell, demselben Repo-Checkout, jedes Mal mit frischem Kontext.

Installieren, mit offenen Augen

Nutz es als ergänzenden Tracer auf reinen TS/JS-Repos, wo du schnelles Call-Chain-Tracing oder Definitionssuche brauchst und deine Codebase sich nicht auf dynamische import(), typreine Imports oder eine Templating-Schicht stützt, die der Graph nicht parsen kann. T5 und T7 zeigen genau, worin es gut ist.

Behandle seinen Graphen auf Mixed-Framework-Codebases nicht als Quelle der Wahrheit. Wenn dein Repo Astro, Vue, Svelte oder ähnliches Templating mit TypeScript mischt oder sich auf dynamische Imports stützt, plane damit, dass das Tool speziell bei „wer ruft das auf"- und „was ist toter Code"-Queries falschliegt — und plane die Token-Kosten des Fallback-grep ein, das es zur Selbstkorrektur brauchen wird.

FAQ

Ist das Tool schlecht? Nein. Die Installation ist sauber, die Indexierung schnell, und Call-Chain-Tracing plus Definitionssuche in reinem TypeScript sind wirklich exzellent. Das Problem ist enger gefasst als „das Tool ist schlecht": Die Flaggschiff-Behauptung zu Token-Einsparungen hält auf einem Mixed-Framework-Repo nicht, weil blinde Flecken im Graphen den Agenten zwingen, sowohl für den Graphen als auch für grep zu zahlen.

Warum weichen eure Zahlen vom arXiv-Paper ab? Andere Stichprobe. Ihr Preprint mittelt über 31 Repos; wir haben ein einzelnes 157-Datei-Astro/TypeScript-Repo getestet, nahe an einem Worst Case für ihr Kantenmodell (Frontmatter-Aufrufe, dynamische Imports, typreine Imports fallen alle außerhalb von CALLS/IMPORTS). Beide Ergebnisse können gleichzeitig stimmen — ihrs ein breiterer Durchschnitt, unseres ein spezifischer, reproduzierbarer Worst-Case-Datenpunkt, den jeder auf einem Mixed-Framework-Repo gegen die Schlagzeilen-Zahl abwägen sollte.

Sollte ich es deinstallieren? Nicht unbedingt. Wenn du primär in reinem TypeScript oder JavaScript arbeitest, ohne massiv dynamische Imports, sagen unsere T5/T7-Daten, dass es ein solider Tracer ist. Wenn dein Repo Frameworks mischt wie unseres, behalt es installiert, aber lass es grep nicht ersetzen — behandle seine Antworten als zu verifizierende Hypothese, so wie unser MCP-Agent es bei der Hälfte der Aufgaben ohnehin am Ende getan hat.

Was ist mit sehr großen Repos? Haben wir nicht getestet, und das ist eine echte Lücke in unseren Daten. Das theoretische Argument für das Tool ist genau dort am stärksten: Ein einzelnes grep über ein riesiges Monorepo kann eine enorme Ergebnismenge zurückgeben, während eine Graph-Query unabhängig von der Repo-Größe klein bleibt. Wenn du ein großes, rein TS/JS-basiertes Monorepo betreibst, ist der 31-Repo-Durchschnitt des arXiv-Papers relevanter für dich als unser einzelnes Ergebnis an einem kleinen Repo — aber führ deinen eigenen A/B-Test durch, bevor du einer der beiden Zahlen blind vertraust.