codebase-memory-mcp: 127% más tokens, no 99% menos

codebase-memory-mcp, de DeusData, se volvió viral en TikTok esta semana. Es un binario estático único que indexa un repositorio en un knowledge graph — 158 lenguajes, el kernel de Linux indexado en tres minutos — y lo expone a Claude Code como un servidor MCP. El argumento de venta es agresivo: la descripción de GitHub dice «99% menos tokens», el README dice «120x menos tokens — 5 consultas estructurales: ~3.400 tokens frente a ~412.000», y su preprint de arXiv (arXiv:2603.27277) reporta «10× menos tokens, 83% de calidad de respuesta» promediado sobre 31 repos.

Pasamos cada herramienta que catalogamos por una prueba A/B controlada antes de puntuarla. Así que hoy (2026-07-11) construimos un benchmark estructural de 8 tareas, pre-registramos las preguntas y la verdad de referencia antes de que corriera cualquiera de los dos brazos, y apuntamos tanto a un agente Sonnet con grep simple como a un agente Sonnet equipado con MCP contra el mismo repo. La corrección salió empatada, 8/8 en ambos. La afirmación estrella sobre tokens se invirtió: el brazo con MCP usó 172.319 tokens frente a los 75.817 de la línea base — 127% más, no 99% menos.

Esa no es toda la historia, y no creemos que deba serlo. La ingeniería subyacente es genuinamente buena. Esto es lo que encontramos y por qué el número se movió como lo hizo.

Lo que la herramienta hace bien

codebase-memory-mcp se instala como un único binario instalable con Homebrew, indexa con un solo comando, y produjo JSON limpio al primer intento. Dos de nuestras ocho tareas fueron victorias claras para el grafo:

• T5 (trazado de cadena de llamadas) — trazar desde un handler POST hasta un helper privado tres saltos más abajo, a través de dos rutas posibles. trace_path(direction=outbound) devolvió el DAG exacto en una sola llamada, coincidiendo exactamente con la verificación manual.
• T7 (búsqueda de definición) — «dónde está definido formatDate». get_code_snippet devolvió el archivo y la línea exacta de inicio/fin en una sola llamada, sin ambigüedad.

Ambas son exactamente el tipo de consulta en el que un grafo debería dominar: TypeScript puro, estructura estática, sin ningún límite de framework de por medio. Si tu repo es TS/JS puro y tus preguntas se parecen a estas, la herramienta es rápida y precisa.

Dónde falló

Nuestro banco de pruebas fue nuestro propio repo: 157 archivos, Astro + TypeScript — una base de código con frameworks mixtos, que se acerca a un caso pésimo para un indexador de grafos construido principalmente alrededor de un modelo de aristas CALLS/IMPORTS. Cuatro de las ocho tareas expusieron puntos ciegos reales:

• T1 (quién llama a getSession) — trace_path(inbound) encontró solo 5 de 7 llamadores. El grafo CALLS no captura llamadas hechas desde el frontmatter de .astro, así que dos llamadores legítimos (admin.astro, account.astro) eran invisibles para él.
• T2 (imports de purchases.ts) — el grafo IMPORTS devolvió 2 de 3 declaraciones de import. La que faltaba era un import de solo tipo (import type { APIContext } from 'astro') — no rastreado como arista.
• T3 (encontrar el único export muerto) — la propia consulta de código muerto de la herramienta (max_degree=0) devolvió de cuatro a cinco falsos positivos: funciones que están vivas, llamadas desde el frontmatter de .astro que el grafo no puede ver. La bandera is_exported del grafo también era incorrecta en varias funciones (b64url, hmac, devStore, nameToSlug — todas marcadas como exportadas, ninguna de ellas tiene realmente la palabra clave export en el código fuente). Llegar a la respuesta correcta requirió extraer el código fuente completo de los cuatro archivos y verificar manualmente cada declaración.
• T8 (impacto de eliminar store.ts) — el grafo IMPORTS encontró limpiamente los 4 importadores estáticos, pero se perdió por completo los 3 sitios de llamada import() dinámicos: uno dentro de un helper devStore() en auth.ts, uno dentro de submit.ts, uno dentro del frontmatter de account.astro. Los imports dinámicos simplemente no se modelan como aristas.

El marcador por tarea

Tarea	Pregunta	BASE	MCP	Qué pasó
T1	quién llama a getSession	1,0	1,0	El grafo de MCP encontró 5/7; recuperó 2 llamadores .astro mediante su propio repliegue a búsqueda de texto
T2	imports de purchases.ts	1,0	1,0	El grafo de MCP encontró 2/3; se perdió el import de solo tipo
T3	un export muerto en src/lib/	1,0	1,0	La consulta de código muerto de MCP devolvió 4–5 falsos positivos; se necesitó verificación manual completa del código fuente
T4	conteo de funciones exportadas	1,0	1,0	MCP contó desde el código fuente en bruto porque los metadatos de is_exported no eran fiables
T5	cadena de llamadas, POST → b64url	1,0	1,0	Victoria limpia para el grafo — .ts puro, sin límite de framework
T6	archivo con más declaraciones de import	1,0	1,0	El conteo de aristas de MCP confundió por-símbolo con por-declaración; se necesitó una verificación cruzada con regex
T7	dónde está definido formatDate	1,0	1,0	Victoria limpia — número de línea exacto en una sola llamada
T8	impacto de eliminar store.ts	1,0	1,0	El grafo de MCP encontró 4/7; se perdió los 3 sitios de import() dinámicos
Total		8/8	8/8	MCP recurrió a su propia búsqueda de texto en 4 de 8 tareas

Ambos brazos llegaron a respuestas idénticas y correctas para cada pregunta. Pero esa paridad hace mucho trabajo para parecer tranquilizadora: el agente con MCP tropezó con una respuesta del grafo incorrecta o incompleta en la mitad de las tareas y tuvo que notarlo, y luego escapar hacia search_code — el equivalente a grep integrado en la herramienta — para volver a derivar la respuesta correcta desde el código fuente. Un agente que confiara en la primera respuesta del grafo sin esa autocorrección habría puntuado aproximadamente 4/8, incorrecto o sin respaldo en T1, T3, T4 y T8.

Las matemáticas de los tokens

Brazo	Tokens totales	vs. afirmación
BASE (Read/Grep simple)	75.817	—
MCP (codebase-memory-mcp)	172.319	+127% más, no 99% menos

measured_savings = 1 − 172,319 / 75,817 = −127.3%. El mecanismo es visible en el desglose por tarea de arriba: el agente pagó por la consulta al grafo, descubrió que era incorrecta o incompleta, y luego volvió a pagar por el repliegue equivalente a grep para obtener la respuesta real. Grafo más grep cuesta más que grep solo, cada vez que el grafo necesita corrección — y en este repo necesitó corrección en la mitad de las tareas.

Vale la pena detenerse en esto: el propio marketing de la herramienta cita «~500 tokens frente a ~80K para grep» por consulta. Nuestra ejecución completa de 8 tareas solo con grep costó 75.817 tokens — menos que el coste reclamado de una sola consulta de grep en sus materiales. La indexación de una sola vez (segundos, hecha una vez en la configuración) queda excluida del total de MCP de arriba, lo cual es generoso con la herramienta.

No es la skill de memoria que estás pensando

Si «codebase-memory-mcp» y skills como memory-management o claude-mem suenan como si resolvieran el mismo problema, no es así. Las skills de memoria de sesión persisten hechos y decisiones entre conversaciones — lo que le dijiste a Claude la semana pasada, contexto de proyecto que de otro modo desaparecería entre sesiones. codebase-memory-mcp indexa la estructura del código dentro de un repo — grafos de llamadas, aristas de imports, definiciones — dentro de una sola sesión. A ambas se las llama «memoria». Una es continuidad de conversación, la otra es análisis estático. No instales esto esperando que recuerde tu última sesión.

Salvedades, dichas sin rodeos

Preferimos trazar nosotros los límites antes de que los descubras por las malas:

• n=8 tareas, un repo. 157 archivos, Astro/TypeScript — una configuración con frameworks mixtos cercana al peor caso para un modelo CALLS/IMPORTS que tiene que razonar sobre frontmatter de plantillas junto a archivos de script.
• Su preprint de arXiv probó 31 repos; nosotros probamos uno. Es del todo plausible que su promedio se sostenga mejor en una muestra más amplia y más de TS/JS puro de lo que representa nuestro único repo con frameworks mixtos.
• Los monorepos grandes de TS/JS puro podrían verse distintos. Donde un grep ingenuo realmente devuelve una salida enorme y el grafo tiene aristas limpias con las que trabajar (sin frontmatter de .astro, sin imports dinámicos), las matemáticas de tokens podrían plausiblemente favorecer al grafo. T5 y T7 — TypeScript puro, estructuralmente simples — son exactamente ese tipo de caso, y el grafo también gana ahí con claridad.
• El tiempo de indexación queda excluido del total de MCP, lo cual favorece a la herramienta, no a la línea base.

Nota de reproducibilidad: las 8 tareas se escribieron y se congelaron antes de que corriera cualquiera de los dos brazos. La verdad de referencia de cada respuesta se verificó de forma independiente con grep contra el repo, no se derivó de la salida de ninguno de los dos brazos. Ambos brazos corrieron sobre el mismo modelo Sonnet, el mismo checkout del repo, con contexto nuevo cada vez.

Instálalo con los ojos abiertos

Úsala como trazador complementario en repos TS/JS puros donde necesites trazado rápido de cadenas de llamadas o búsqueda de definiciones, y tu base de código no dependa de import() dinámicos, imports de solo tipo, o una capa de plantillas que el grafo no pueda analizar. T5 y T7 muestran exactamente en qué es buena.

No trates su grafo como fuente de verdad en bases de código con frameworks mixtos. Si tu repo mezcla Astro, Vue, Svelte o plantillas similares con TypeScript, o depende de imports dinámicos, cuenta con que la herramienta se equivoque específicamente en consultas de «quién llama a esto» y «qué es código muerto» — y presupuesta el coste en tokens del grep de repliegue que necesitará para autocorregirse.

Preguntas frecuentes

¿Es mala la herramienta? No. La instalación es limpia, la indexación es rápida, y el trazado de cadenas de llamadas más la búsqueda de definiciones en TypeScript puro son genuinamente excelentes. El problema es más acotado que «la herramienta es mala»: la afirmación estrella de ahorro de tokens no se sostiene en un repo con frameworks mixtos, porque los puntos ciegos del grafo obligan al agente a pagar tanto por el grafo como por el grep.

¿Por qué difieren tus números de los del paper de arXiv? Muestra distinta. Su preprint promedia sobre 31 repos; nosotros probamos un único repo de 157 archivos en Astro/TypeScript, cercano a un peor caso para su modelo de aristas (las llamadas en frontmatter, los imports dinámicos y los imports de solo tipo quedan fuera de CALLS/IMPORTS). Ambos resultados pueden ser ciertos a la vez — el suyo un promedio más amplio, el nuestro un dato de peor caso específico y reproducible que cualquiera con un repo de frameworks mixtos debería sopesar antes de confiar en el número titular.

¿Debería desinstalarla? No necesariamente. Si trabajas principalmente en TypeScript o JavaScript puro sin imports dinámicos pesados, nuestros datos de T5/T7 dicen que es un trazador sólido. Si tu repo mezcla frameworks como el nuestro, mantenla instalada pero no dejes que reemplace a grep — trata sus respuestas como una hipótesis que hay que verificar, tal como terminó haciendo nuestro agente con MCP en la mitad de las tareas de todos modos.

¿Qué pasa con los repos muy grandes? No probamos ninguno, y es un hueco real en nuestros datos. El argumento teórico a favor de la herramienta es más fuerte ahí: un solo grep en un monorepo enorme puede devolver un conjunto de resultados gigantesco, mientras que una consulta al grafo se mantiene pequeña sin importar el tamaño del repo. Si manejas un monorepo grande de TS/JS puro, el promedio de 31 repos del paper de arXiv es más relevante para ti que nuestro único resultado de repo pequeño — pero corre tu propia prueba A/B antes de confiar a ciegas en cualquiera de los dos números.