codebase-memory-mcp: 127% więcej tokenów, nie 99% mniej

codebase-memory-mcp od DeusData zrobiło furorę na TikToku w tym tygodniu. To pojedynczy statyczny binarny plik, który indeksuje repozytorium w graf wiedzy — 158 języków, jądro Linuksa zaindeksowane w trzy minuty — i udostępnia go Claude Code jako serwer MCP. Przekaz jest agresywny: opis na GitHubie mówi „99% fewer tokens”, README mówi „120x fewer tokens — 5 structural queries: ~3,400 tokens vs ~412,000”, a ich preprint na arXiv (arXiv:2603.27277) raportuje „10× fewer tokens, 83% answer quality” uśrednione po 31 repozytoriach.

Każde narzędzie, które katalogujemy, przepuszczamy przez kontrolowany test A/B, zanim je ocenimy. Więc dziś (2026-07-11) zbudowaliśmy 8-zadaniowy benchmark strukturalny, zarejestrowaliśmy z góry pytania i ground truth, zanim ruszyła którakolwiek ręka, i skierowaliśmy zarówno agenta Sonnet na zwykłym grepie, jak i agenta Sonnet wyposażonego w MCP na to samo repo. Poprawność wyszła remisowo, 8/8 w obu. Flagowa obietnica oszczędności tokenów odwróciła się: ręka z MCP zużyła 172,319 tokenów wobec 75,817 w baseline'ie — 127% więcej, nie 99% mniej.

To nie cała historia i uważamy, że nie powinna nią być. Inżynieria pod spodem jest naprawdę dobra. Oto, co znaleźliśmy i dlaczego ta liczba poszła w taką, a nie inną stronę.

Co narzędzie robi dobrze

codebase-memory-mcp instaluje się jako pojedynczy binarny plik do zainstalowania przez Homebrew, indeksuje jedną komendą i za pierwszym razem dał czysty JSON. Dwa z naszych ośmiu zadań to jasne wygrane dla grafu:

• T5 (śledzenie łańcucha wywołań) — śledzenie od handlera POST w dół do prywatnego helpera trzy skoki głębiej, przez dwie możliwe ścieżki. trace_path(direction=outbound) zwrócił dokładny DAG za jednym wywołaniem, idealnie zgodny z ręczną weryfikacją.
• T7 (wyszukiwanie definicji) — „gdzie jest zdefiniowane formatDate”. get_code_snippet zwrócił plik oraz dokładny wiersz początku/końca za jednym wywołaniem, bez żadnej dwuznaczności.

Oba te przypadki to dokładnie ten kształt zapytania, w którym graf powinien dominować: czysty TypeScript, statyczna struktura, żadnej granicy frameworka na drodze. Jeśli twoje repo to czysty TS/JS, a twoje pytania wyglądają podobnie, narzędzie jest szybkie i precyzyjne.

Gdzie to się posypało

Naszym poligonem było własne repo: 157 plików, Astro + TypeScript — codebase mieszający frameworki, czyli coś bliskiego najgorszemu przypadkowi dla indeksera grafowego zbudowanego głównie wokół modelu krawędzi CALLS/IMPORTS. Cztery z ośmiu zadań ujawniły realne martwe pola:

• T1 (kto woła getSession) — trace_path(inbound) znalazł tylko 5 z 7 wołających. Graf CALLS nie wychwytuje wywołań z frontmatteru .astro, więc dwóch prawowitych wołających (admin.astro, account.astro) było dla niego niewidocznych.
• T2 (importy purchases.ts) — graf IMPORTS zwrócił 2 z 3 instrukcji importu. Brakujący był import tylko-typowy (import type { APIContext } from 'astro') — nieśledzony jako krawędź.
• T3 (znajdź jeden martwy eksport) — własne zapytanie narzędzia o martwy kod (max_degree=0) zwróciło cztery do pięciu fałszywych trafień: funkcje, które są żywe, wołane z frontmatteru .astro, którego graf nie widzi. Flaga is_exported grafu też była błędna przy kilku funkcjach (b64url, hmac, devStore, nameToSlug — wszystkie oznaczone jako exportowane, choć żadna z nich faktycznie nie ma słowa kluczowego export w źródle). Dotarcie do właściwej odpowiedzi wymagało wyciągnięcia pełnego źródła dla wszystkich czterech plików i ręcznej weryfikacji każdej deklaracji.
• T8 (wpływ usunięcia store.ts) — graf IMPORTS czysto znalazł 4 statycznych importerów, ale całkowicie przegapił wszystkie 3 miejsca dynamicznego import(): jedno wewnątrz helpera devStore() w auth.ts, jedno wewnątrz submit.ts, jedno wewnątrz frontmatteru account.astro. Dynamiczne importy po prostu nie są modelowane jako krawędzie.

Wynik po zadaniach

Zadanie	Pytanie	BASE	MCP	Co się stało
T1	kto woła getSession	1.0	1.0	Graf MCP znalazł 5/7; odzyskał 2 wołających .astro przez własny fallback wyszukiwania tekstowego
T2	importy purchases.ts	1.0	1.0	Graf MCP znalazł 2/3; przegapił import tylko-typowy
T3	jeden martwy eksport w src/lib/	1.0	1.0	Zapytanie MCP o martwy kod zwróciło 4–5 fałszywych trafień; wymagało pełnej ręcznej weryfikacji źródła
T4	liczba funkcji exportowanych	1.0	1.0	MCP liczył z surowego źródła, bo metadane is_exported były niewiarygodne
T5	łańcuch wywołań, POST → b64url	1.0	1.0	Czysta wygrana dla grafu — czysty .ts, brak granicy frameworka
T6	plik z największą liczbą instrukcji importu	1.0	1.0	Liczba krawędzi MCP pomyliła per-symbol z per-statement; wymagała sprawdzenia krzyżowego regexem
T7	gdzie jest zdefiniowane formatDate	1.0	1.0	Czysta wygrana — dokładny numer wiersza za jednym wywołaniem
T8	wpływ usunięcia store.ts	1.0	1.0	Graf MCP znalazł 4/7; przegapił wszystkie 3 miejsca dynamicznego import()
Razem		8/8	8/8	MCP uciekał do własnego wyszukiwania tekstowego w 4 z 8 zadań

Obie ręce wylądowały na identycznych, poprawnych odpowiedziach na każde pytanie. Ale ten parytet ciężko pracuje, żeby wyglądać uspokajająco: agent MCP trafił na błędną albo niekompletną odpowiedź grafu w połowie zadań i musiał to zauważyć, a potem uciec do search_code — wbudowanego odpowiednika grepa w narzędziu — żeby na nowo wyprowadzić poprawną odpowiedź ze źródła. Agent, który zaufałby pierwszej odpowiedzi grafu bez tej autokorekty, wypadłby na jakieś 4/8, błędnie albo bez pokrycia w T1, T3, T4 i T8.

Matematyka tokenów

Ręka	Tokeny łącznie	vs. obietnica
BASE (zwykły Read/Grep)	75,817	—
MCP (codebase-memory-mcp)	172,319	+127% więcej, nie 99% mniej

measured_savings = 1 − 172,319 / 75,817 = −127.3%. Mechanizm widać w podziale na zadania powyżej: agent zapłacił za zapytanie do grafu, odkrył, że jest błędne albo niekompletne, a potem zapłacił jeszcze raz za fallback odpowiadający grepowi, żeby dostać prawdziwą odpowiedź. Graf plus grep kosztuje więcej niż sam grep, za każdym razem, gdy graf trzeba poprawiać — a w tym repo trzeba go było poprawiać w połowie zadań.

Warto się nad tym zatrzymać: marketing samego narzędzia cytuje „~500 tokens vs ~80K for grep” na zapytanie. Cały nasz przebieg 8 zadań na samym grepie kosztował 75,817 tokenów — mniej niż deklarowany koszt jednego zapytania grep w ich materiałach. Jednorazowe indeksowanie (sekundy, wykonane raz przy setupie) jest wyłączone z sumy MCP powyżej, co jest hojne wobec narzędzia.

To nie ten skill pamięciowy, o którym myślisz

Jeśli wydaje ci się, że „codebase-memory-mcp” i skille takie jak memory-management czy claude-mem rozwiązują ten sam problem, to nieprawda. Skille pamięci sesji zachowują fakty i decyzje między rozmowami — to, co powiedziałeś Claude'owi tydzień temu, kontekst projektu, który inaczej zniknąłby między sesjami. codebase-memory-mcp indeksuje strukturę kodu wewnątrz repo — grafy wywołań, krawędzie importów, definicje — w obrębie jednej sesji. Oba nazywa się „memory”. Jedno to ciągłość rozmowy, drugie to analiza statyczna. Nie instaluj tego, oczekując, że będzie pamiętać twoją ostatnią sesję.

Zastrzeżenia, powiedziane wprost

Wolimy sami wyznaczyć granice, niż żebyś odkrywał je na własnej skórze:

• n=8 zadań, jedno repo. 157 plików, Astro/TypeScript — setup mieszający frameworki, bliski najgorszemu przypadkowi dla modelu CALLS/IMPORTS, który musi rozumować o frontmatterze szablonów obok plików skryptowych.
• Ich preprint na arXiv testował 31 repozytoriów; my przetestowaliśmy jedno. Całkiem możliwe, że ich średnia trzyma się lepiej na szerszej, bardziej czysto-TS/JS próbce, niż reprezentuje nasze pojedyncze repo mieszające frameworki.
• Duże, czysto-TS/JS monorepo mogłyby wyglądać inaczej. Tam, gdzie naiwny grep naprawdę zwraca ogromny output, a graf ma czyste krawędzie do pracy (bez frontmatteru .astro, bez dynamicznych importów), matematyka tokenów mogłaby realnie faworyzować graf. T5 i T7 — czysty TypeScript, strukturalnie proste — mają dokładnie taki kształt i tam graf też wygrywa czysto.
• Czas indeksowania jest wyłączony z sumy MCP, co faworyzuje narzędzie, nie baseline.

Uwaga o odtwarzalności: 8 zadań zostało napisanych i zablokowanych, zanim ruszyła którakolwiek ręka. Ground truth dla każdej odpowiedzi zweryfikowano niezależnie grepem względem repo, nie wyprowadzono z outputu żadnej z rąk. Obie ręce działały na tym samym modelu Sonnet, na tym samym checkout repo, za każdym razem ze świeżym kontekstem.

Instaluj z otwartymi oczami

Używaj go jako uzupełniającego tracera na czysto-TS/JS repo tam, gdzie potrzebujesz szybkiego śledzenia łańcuchów wywołań albo wyszukiwania definicji, a twój codebase nie opiera się mocno na dynamicznym import(), importach tylko-typowych ani warstwie templatek, której graf nie potrafi sparsować. T5 i T7 pokazują dokładnie, w czym jest dobry.

Nie traktuj jego grafu jako źródła prawdy na codebase'ach mieszających frameworki. Jeśli twoje repo miesza Astro, Vue, Svelte albo podobny templating z TypeScript, albo opiera się na dynamicznych importach, zaplanuj, że narzędzie będzie się mylić konkretnie przy zapytaniach „kto to woła” i „co jest martwym kodem” — i zaplanuj koszt tokenów fallbackowego grepa, którego będzie potrzebować, żeby się poprawić.

FAQ

Czy to narzędzie jest złe? Nie. Instalacja jest czysta, indeksowanie szybkie, a śledzenie łańcuchów wywołań plus wyszukiwanie definicji w czystym TypeScript są naprawdę świetne. Problem jest węższy niż „narzędzie jest złe”: flagowa obietnica oszczędności tokenów nie trzyma się na repo mieszającym frameworki, bo martwe pola grafu zmuszają agenta do zapłacenia i za graf, i za grep.

Dlaczego twoje liczby różnią się od artykułu na arXiv? Inna próbka. Ich preprint uśrednia po 31 repozytoriach; my przetestowaliśmy jedno repo Astro/TypeScript na 157 plików, bliskie najgorszemu przypadkowi dla ich modelu krawędzi (wywołania z frontmatteru, dynamiczne importy, importy tylko-typowe — wszystko poza CALLS/IMPORTS). Oba wyniki mogą być prawdziwe jednocześnie — ich to szersza średnia, nasz to konkretny, odtwarzalny punkt danych z najgorszego przypadku, który powinien rozważyć każdy na repo mieszającym frameworki, zanim zaufa nagłówkowej liczbie.

Czy powinienem go odinstalować? Niekoniecznie. Jeśli pracujesz głównie w czystym TypeScript albo JavaScript bez ciężkich dynamicznych importów, nasze dane z T5/T7 mówią, że to solidny tracer. Jeśli twoje repo miesza frameworki tak jak nasze, zostaw go zainstalowanego, ale nie pozwól mu zastąpić grepa — traktuj jego odpowiedzi jak hipotezę do zweryfikowania, tak jak i tak zrobił nasz agent MCP w połowie zadań.

A co z bardzo dużymi repo? Nie testowaliśmy takiego i to realna luka w naszych danych. Teoretyczny argument za narzędziem jest tam najmocniejszy: pojedynczy grep w ogromnym monorepo może zwrócić gigantyczny zbiór wyników, podczas gdy zapytanie do grafu zostaje małe niezależnie od rozmiaru repo. Jeśli prowadzisz duże, czysto-TS/JS monorepo, średnia z 31 repozytoriów z artykułu na arXiv jest dla ciebie bardziej relewantna niż nasz pojedynczy wynik z małego repo — ale zanim ślepo zaufasz którejkolwiek liczbie, uruchom własny test A/B.