codebase-memory-mcp: 127% víc tokenů, ne 99% míň

codebase-memory-mcp od DeusData tento týden zvirálnil na TikToku. Je to jeden statický binární soubor, který naindexuje repozitář do knowledge grafu — 158 jazyků, jádro Linuxu naindexované za tři minuty — a zpřístupní ho Claude Code jako MCP server. Nabídka je agresivní: popis na GitHubu tvrdí „o 99% méně tokenů“, README říká „120x méně tokenů — 5 strukturálních dotazů: ~3,400 tokenů vs ~412,000“ a jejich arXiv preprint (arXiv:2603.27277) uvádí „10× méně tokenů, 83% kvalita odpovědi“ v průměru přes 31 repozitářů.

Každý nástroj, který katalogizujeme, provedeme řízeným A/B testem předtím, než ho ohodnotíme. Dnes (2026-07-11) jsme proto postavili 8úlohový strukturální benchmark, otázky i referenční (ground truth) odpovědi jsme zaregistrovali předem, než běžela kterákoli větev, a na stejný repozitář jsme nasadili jak Sonnet agenta s obyčejným grepem, tak Sonnet agenta vybaveného MCP. Správnost vyšla vyrovnaně, 8/8 v obou. Vlajkové tvrzení o tokenech se obrátilo: MCP větev použila 172,319 tokenů oproti 75,817 u baseline — o 127% víc, ne o 99% míň.

To není celý příběh a ani by neměl být. Inženýrská práce pod kapotou je opravdu dobrá. Tohle jsme zjistili a proč se to číslo takhle pohnulo.

Co nástroj dělá dobře

codebase-memory-mcp se instaluje jako jeden binární soubor instalovatelný přes Homebrew, indexuje na jeden příkaz a už napoprvé vyprodukoval čistý JSON. Dvě z našich osmi úloh byly pro graf jasnou výhrou:

• T5 (trasování řetězce volání) — trasování z handleru POST až k privátní pomocné funkci tři kroky do hloubky, přes dvě možné cesty. trace_path(direction=outbound) vrátil přesný DAG na jedno volání, přesně odpovídající ruční verifikaci.
• T7 (vyhledání definice) — „kde je definovaná formatDate.“ get_code_snippet vrátil soubor a přesný počáteční/koncový řádek na jedno volání, bez nejednoznačnosti.

Oba případy jsou přesně ten typ dotazu, ve kterém by měl graf jednoznačně vyhrávat: čistý TypeScript, statická struktura, žádná hranice frameworku v cestě. Pokud je váš repozitář čistý TS/JS a vaše otázky vypadají takhle, nástroj je rychlý a přesný.

Kde to selhalo

Naším testovacím prostředím byl náš vlastní repozitář: 157 souborů, Astro + TypeScript — codebase se smíšeným frameworkem, což se blíží nejhoršímu případu pro grafový indexer postavený primárně na modelu hran CALLS/IMPORTS. Čtyři z osmi úloh odhalily skutečná slepá místa:

• T1 (kdo volá getSession) — trace_path(inbound) našel jen 5 ze 7 volajících. Graf CALLS nezachycuje volání z .astro frontmatteru, takže dva legitimní volající (admin.astro, account.astro) pro něj byli neviditelní.
• T2 (importy purchases.ts) — graf IMPORTS vrátil 2 ze 3 importních příkazů. Chybějící byl type-only import (import type { APIContext } from 'astro') — jako hrana nezaznamenaný.
• T3 (najít ten jeden mrtvý export) — vlastní dotaz nástroje na mrtvý kód (max_degree=0) vrátil čtyři až pět falešně pozitivních výsledků: funkce, které jsou živé, volané z .astro frontmatteru, který graf nevidí. Příznak is_exported byl u grafu navíc chybný u několika funkcí (b64url, hmac, devStore, nameToSlug — všechny označené jako exportované, přitom žádná z nich ve zdrojovém kódu skutečně nemá klíčové slovo export). Získání správné odpovědi vyžadovalo stáhnout celý zdrojový kód všech čtyř souborů a ručně ověřit každou deklaraci.
• T8 (dopad smazání store.ts) — graf IMPORTS čistě našel 4 statické importéry, ale úplně minul všechna 3 místa s dynamickým import(): jedno uvnitř pomocné funkce devStore() v auth.ts, jedno uvnitř submit.ts, jedno uvnitř account.astro frontmatteru. Dynamické importy prostě nejsou modelované jako hrany.

Skóre po jednotlivých úlohách

Úloha	Otázka	BASE	MCP	Co se stalo
T1	kdo volá getSession	1.0	1.0	MCP graf našel 5/7; 2 volající z .astro získal zpět díky vlastnímu fallbacku na textové vyhledávání
T2	importy purchases.ts	1.0	1.0	MCP graf našel 2/3; minul type-only import
T3	jeden mrtvý export v src/lib/	1.0	1.0	MCP dotaz na mrtvý kód vrátil 4–5 falešně pozitivních výsledků; bylo potřeba plné ruční ověření zdrojového kódu
T4	počet exportovaných funkcí	1.0	1.0	MCP počítal ze surového zdrojového kódu, protože metadata is_exported byla nespolehlivá
T5	řetězec volání, POST → b64url	1.0	1.0	Čistá výhra pro graf — čisté .ts, žádná hranice frameworku
T6	soubor s nejvíc importními příkazy	1.0	1.0	Počet hran u MCP zaměňoval počet za symbol s počtem za příkaz; bylo potřeba křížové ověření regexem
T7	kde je definovaná formatDate	1.0	1.0	Čistá výhra — přesné číslo řádku na jedno volání
T8	dopad smazání store.ts	1.0	1.0	MCP graf našel 4/7; minul všechna 3 místa s dynamickým import()
Celkem		8/8	8/8	MCP se u 4 z 8 úloh spolehl na vlastní textové vyhledávání

Obě větve došly na každou otázku ke shodné, správné odpovědi. Ale tahle shoda musí hodně makat, aby působila uklidňujícím dojmem: MCP agent narazil u poloviny úloh na chybnou nebo neúplnou odpověď grafu, musel si toho všimnout a pak uniknout do search_code — vestavěného ekvivalentu grepu — aby správnou odpověď znovu odvodil ze zdrojového kódu. Agent, který by první odpovědi grafu důvěřoval bez téhle sebeopravy, by skóroval zhruba 4/8, chybně nebo nepodloženě u T1, T3, T4 a T8.

Matematika tokenů

Větev	Celkem tokenů	vs. tvrzení
BASE (obyčejné Read/Grep)	75,817	—
MCP (codebase-memory-mcp)	172,319	+127% víc, ne 99% míň

measured_savings = 1 − 172,319 / 75,817 = −127.3%. Mechanismus je vidět v rozpisu podle úloh výše: agent zaplatil za dotaz na graf, zjistil, že je chybný nebo neúplný, a pak zaplatil znovu za fallback na ekvivalent grepu, aby získal skutečnou odpověď. Graf plus grep stojí víc než samotný grep, pokaždé když je potřeba graf opravit — a na tomhle repozitáři to bylo potřeba u poloviny úloh.

Stojí za to se u toho zastavit: vlastní marketing nástroje uvádí „~500 tokenů vs ~80K za grep“ na jeden dotaz. Náš celý běh na 8 úloh jen s grepem stál 75,817 tokenů — méně, než kolik jejich materiály uvádí jako cenu jednoho grep dotazu. Jednorázová indexace (sekundy, provedená jen jednou při nastavení) je z výše uvedeného MCP součtu vyloučená, což je vůči nástroji velkorysé.

Není to ten memory skill, na který myslíte

Pokud vám „codebase-memory-mcp“ a skilly jako memory-management nebo claude-mem znějí, že řeší stejný problém, neřeší. Skilly pro paměť relace uchovávají fakta a rozhodnutí napříč konverzacemi — co jste Claudovi řekli minulý týden, kontext projektu, který by jinak mezi sezeními zmizel. codebase-memory-mcp indexuje strukturu kódu uvnitř repozitáře — grafy volání, importní hrany, definice — v rámci jedné relace. Oběma se říká „memory“. Jedno je kontinuita konverzace, druhé je statická analýza. Neinstalujte si tohle v očekávání, že si bude pamatovat vaše poslední sezení.

Omezení, na rovinu

Radši vám hranice vymezíme sami, než abyste na ně museli přijít tvrdým způsobem:

• n=8 úloh, jeden repozitář. 157 souborů, Astro/TypeScript — nastavení se smíšeným frameworkem blízké nejhoršímu případu pro model CALLS/IMPORTS, který musí uvažovat o frontmatteru šablon vedle skriptových souborů.
• Jejich arXiv preprint testoval 31 repozitářů, my jeden. Je docela dobře možné, že jejich průměr obstojí líp napříč širším, čistěji TS/JS vzorkem, než jaký představuje náš jediný repozitář se smíšeným frameworkem.
• Velké čistě TS/JS monorepozitáře by mohly vypadat jinak. Tam, kde naivní grep opravdu vrací obrovský výstup a graf má k dispozici čisté hrany (žádný .astro frontmatter, žádné dynamické importy), by matematika tokenů mohla klidně vyjít ve prospěch grafu. T5 a T7 — čistý TypeScript, strukturálně jednoduché — jsou přesně tenhle případ a graf tam čistě vyhrává taky.
• Čas indexace je z celkového MCP součtu vyloučený, což je ve prospěch nástroje, ne baseline.

Poznámka k reprodukovatelnosti: 8 úloh bylo napsáno a uzamčeno předtím, než běžela kterákoli větev. Referenční odpověď (ground truth) pro každou otázku byla nezávisle ověřená grepem proti repozitáři, ne odvozená z výstupu žádné z větví. Obě větve běžely na stejném modelu Sonnet, na stejném checkoutu repozitáře, pokaždé s čerstvým kontextem.

Instalujte s otevřenýma očima

Používejte ho jako doplňkový trasovač na čistě TS/JS repozitářích, kde potřebujete rychlé trasování řetězců volání nebo vyhledávání definic a vaše codebase nespoléhá na dynamický import(), type-only importy nebo šablonovací vrstvu, kterou graf neumí parsovat. T5 a T7 přesně ukazují, v čem je dobrý.

Neberte jeho graf jako zdroj pravdy u codebase se smíšeným frameworkem. Pokud váš repozitář mixuje Astro, Vue, Svelte nebo podobný šablonovací systém s TypeScriptem, nebo spoléhá na dynamické importy, počítejte s tím, že nástroj se bude mýlit konkrétně u dotazů „kdo tohle volá“ a „co je mrtvý kód“ — a počítejte i s nákladem na tokeny za fallback grep, který bude potřebovat, aby se sám opravil.

Časté otázky

Je ten nástroj špatný? Ne. Instalace je čistá, indexace rychlá a trasování řetězců volání spolu s vyhledáváním definic v čistém TypeScriptu jsou opravdu skvělé. Problém je užší, než „nástroj je špatný“: vlajkové tvrzení o úspoře tokenů neplatí na repozitáři se smíšeným frameworkem, protože slepá místa grafu nutí agenta platit za graf i za grep zároveň.

Proč se vaše čísla liší od arXiv paperu? Jiný vzorek. Jejich preprint zprůměrovává 31 repozitářů; my jsme testovali jeden repozitář s 157 soubory Astro/TypeScript, blízko nejhoršímu případu pro jejich model hran (volání z frontmatteru, dynamické importy, type-only importy — to všechno spadá mimo CALLS/IMPORTS). Oba výsledky mohou platit zároveň — jejich je širší průměr, náš konkrétní, reprodukovatelný datový bod nejhoršího případu, který by měl zvážit každý na repozitáři se smíšeným frameworkem předtím, než uvěří hlavnímu číslu.

Mám ho odinstalovat? Ne nutně. Pokud pracujete hlavně v čistém TypeScriptu nebo JavaScriptu bez velkého množství dynamických importů, naše data z T5/T7 říkají, že je to solidní trasovač. Pokud váš repozitář mixuje frameworky tak jako ten náš, nechte si ho nainstalovaný, ale nenechte ho nahradit grep — berte jeho odpovědi jako hypotézu k ověření, tak jak to nakonec náš MCP agent u poloviny úloh stejně dělal.

Co velmi velké repozitáře? Žádný jsme netestovali a je to skutečná díra v našich datech. Teoretický argument pro nástroj je právě tady nejsilnější: jeden grep napříč obrovským monorepozitářem může vrátit obrovský výsledek, zatímco grafový dotaz zůstává malý bez ohledu na velikost repozitáře. Pokud provozujete velký čistě TS/JS monorepozitář, je pro vás relevantnější průměr z 31 repozitářů z arXiv paperu než náš jediný výsledek z malého repozitáře — ale než slepě uvěříte kterémukoli číslu, spusťte si vlastní A/B test.