memtrace-public

Local machine requirements — Memtrace indexes and embeds your code locally, so the first run is CPU/RAM intensive. Minimum: 4 CPU cores, 8 GB RAM, 5 GB free disk, Node.js 18+, and Git. Recommended for large monorepos: 8+ CPU cores, 16–32 GB RAM, and 10–20 GB free disk. No GPU required.

npm install -g memtrace    # binary + 12 skills + MCP server — one command
memtrace start             # launches the graph database and auto-indexes the current project

That's it. Run memtrace start from your project root — it spins up the graph database and kicks off indexing automatically. Claude and Cursor (v2.4+) pick up the skills and MCP tools automatically.

https://github.com/user-attachments/assets/e7d6a1e9-c912-4e65-a421-bd0256dffa5a

Built-in UI at localhost:3030 — explore your graph, trace dependencies, spot dead code, and visualize architecture at a glance

Why Memtrace Exists

Good code intelligence tools already exist. GitNexus and CodeGrapherContext build AST-based graphs with symbol relationships, and they work well for understanding what's in your codebase right now.

Memtrace is a bi-temporal episodic structural knowledge graph. It builds on that same AST foundation and adds two dimensions:

• Temporal memory — every symbol carries its full version history. Agents can reason about what changed, when it changed, and how the architecture evolved — not just what exists today. Six scoring algorithms (impact, novelty, recency, directional, compound, overview) let agents ask different temporal questions.
• Cross-service API topology — Memtrace maps HTTP call graphs between repositories, detecting which services call which endpoints across your architecture.

On top of that, the structural layer is comprehensive:

• Symbols are nodes — functions, classes, interfaces, types, endpoints
• Relationships are edges — CALLS, IMPLEMENTS, IMPORTS, EXPORTS, CONTAINS
• Community detection — Louvain algorithm identifies architectural modules automatically
• Hybrid search — Tantivy BM25 + vector embeddings + Reciprocal Rank Fusion, all on top of the graph
• Rust-native — compiled binary, no Python/JS runtime overhead, sub-8ms average query latency

The agent doesn't just search your code. It remembers it.

Benchmarks

Five sub-benches across three corpora (mempalace, Django, a 21-file scratch fixture). Every system runs on the same machine, against the same ground truth, using the same adapter contract. Ground truth comes from Python's stdlib ast, the pyright LSP, or deterministic edit scripts — never from any tool's own index — so no system gets a home-field advantage in the dataset itself.

Full reproduction instructions and per-bench numbers: benchmarks/README.md. The frozen exact-symbol harness is benchmarks/fair/; the extended harness covering all five benches is benchmarks/suite/.

Summary across the five benches (🟢 = Memtrace wins declared primary axis, 🟡 = Memtrace trails):

| # | Bench | Primary axis | Memtrace | Runner-up | Δ | |:-:|:------|:-------------|---------:|:----------|---:| | 0 | Exact-symbol lookup (1,000 queries, mempalace) | acc_at_1_pct | 96.7% 🟢 | ChromaDB 62.3% | 1.55× | | 1 | Token economy (same 1,000) | acc_at_1_per_kilo_token | 495.52 🟢 | GitNexus 126.90 | 3.90× | | 2 | Intent retrieval (100 NL PR titles, Django) | recall_at_10 | 58.6% 🟡 | ChromaDB 66.8% | −8.2 pp | | 3 | Graph queries (mempalace, pyright GT) | callers_of.recall | 0.851 🟢 | CGC 0.584 | 1.46× | | 3 | Graph queries (Django, pyright GT) | callers_of.recall | 0.816 🟢 | GitNexus 0.053 | 15.4× | | 4 | Incremental freshness (50 edits) | time_to_queryable_p95 | 42.5 ms 🟢 | CGC 613.7 ms | 14.4× faster |

Memtrace wins 5 of 6, trails on 1 (Bench #2 — ChromaDB is the expected winner on semantic NL queries). Bench #5 (agent-level) is skeleton-only and gated behind RUN_AGENT_BENCH=1.

Results (1,000 Python symbol-lookup queries on mempalace, v0.3.22 + ranking)

Numbers from isolated per-adapter processes — full methodology in BENCHMARKS-v0.3.22.md.

| Tool | Coverage | Acc@1 | Acc@10 | Prec@10 | Avg lat | RSS | Tokens | |:-----|---------:|------:|-------:|--------:|--------:|----:|-------:| | Memtrace (MemDB) | 100.0% | 96.6% | 99.7% | 0.967 | 0.07 ms | 26.2 MB | 383 | | GitNexus (eval-server) | 100.0% | 97.0% | 100% | 0.702 | 8.95 ms | 31.0 MB | 90 | | ChromaDB (all-MiniLM-L6-v2) | 100.0% | 62.4% | 87.8% | 0.188 | 54.6 ms | 1,060 MB | 1,937 | | CodeGrapherContext (CLI) | 100.0% | 7.9% | 99.9% | 0.521 | 2,020 ms | ~150 MB | 217 |

• Coverage = the tool returned any result for the query (separates "did you index it?" from "did you rank it well?")
• Acc@K = the correct file appeared in the top K ranked results
• Avg latency = wall-clock per query, including all protocol overhead (MCP JSON-RPC for Memtrace, HTTP for GitNexus, in-process for ChromaDB, subprocess spawn for CGC)
• Tokens = average response size in tokens (chars / 4)

What the numbers say, read fairly:

• Memtrace holds rank-1 on 96.6% of queries with 128× lower latency (0.07 ms vs GitNexus 8.95 ms), 1.18× tighter RSS (26 MB vs 31 MB), and 1.38× higher precision@10 (0.97 vs 0.70). It ranks results by structural relevance — the canonical implementation comes first in one round-trip with the full agent envelope.
• GitNexus wins by a 4-query margin on acc@1 because it ships raw enumeration order; memtrace re-orders by direct_callers_count so Model.delete precedes tests.fake_delete. Right tradeoff for agents, small benchm