Codebase-Memory
Definition
Codebase-Memory (paper arXiv 2603.27277; implementation codebase-memory-mcp by DeusData) replaces LLM agents’ repeated file-reading and grep-searching with a persistent, Tree-Sitter-based knowledge graph served over MCP. It contains no LLM — the agent is the intelligence layer; the tool provides structural analysis.^[raw/external/arxiv-org-2603-27277-af87911a.md]
Key Points
- Paper (2603.27277): multi-phase pipeline with parallel worker pools, call-graph traversal, impact analysis, community discovery; 66 languages; 31 real-world repos; 83% answer quality vs 92% for a file-exploration agent at ~10× fewer tokens and 2.1× fewer tool calls; graph-native queries match/exceed the explorer on 19 of 31 repos.
- Implementation (codebase-memory-mcp): 158 languages via vendored tree-sitter grammars; two-pass pipeline (syntactic extraction + “hybrid LSP” embedded C type-resolution inspired by tsserver/pyright/gopls/Roslyn/rust-analyzer); RAM-first indexing (LZ4, in-memory SQLite); single static binary, zero runtime deps, 100% local.
- Scale claims: average repo indexed in milliseconds; sub-ms structural queries; Linux kernel (28M LOC, 75K files → 4.81M nodes, 7.72M edges) in 3 minutes; Django (~49K nodes) in ~6s; 99.2% token reduction (~3,400 vs ~412,000 tokens for file-by-file grep).
- 15 MCP tools: indexing (index_repository, list_projects, delete_project, index_status) + querying (search_graph, trace_path, detect_changes, query_graph with openCypher subset, get_code_snippet, get_architecture, search_code, manage_adr, ingest_traces).
- Graph model: Project/Package/File/Class/Function/Route nodes; CALLS, IMPORTS, HTTP_CALLS, DATA_FLOWS, SIMILAR_TO edges; Louvain community detection; semantic search (nomic-embed-code) + BM25 FTS5; dead-code detection; IaC indexing (Docker/K8s/Kustomize); cross-repo CROSS_* edges; optional 3D graph UI; team-shared zstd artifact (
.codebase-memory/graph.db.zst).
Implications
Codebase-Memory is a structural answer to the token problem: instead of compressing file reads, it eliminates them via graph queries (“One graph query replaces dozens of grep/read cycles”). The paper/repo discrepancy is notable: paper reports “~10× fewer tokens” (≈90% reduction) while the repo claims 99.2% — the repo counts a different baseline (full file-by-file grep vs the paper’s explorer agent). Token claims should be read with that baseline caveat, consistent with the paper on token metrics.
Open Questions
- Whether the 99.2% vs 10× token claims are reconcilable (different baselines) or one is marketing.
- Whether graph-query results preserve evidence recoverability as well as contextsniper’s packets.
Related
contextsniper — alternative code-memory approach with comparable token wins token-reduction-is-not-cost-reduction — why token % claims need baseline scrutiny token-usage-reduction — structural levers (code-intelligence plugins) this extends rtk-rust-token-killer — compression proxy; contrast in mechanism claude-code-system-prompt — agent that consumes the MCP graph
Sources
- raw/external/arxiv-org-2603-27277-af87911a.md
- raw/external/github-com-codebase-memory-mcp-f33fbe15.md