How code-memory scores vs raw ripgrep
Full tables + methodology in Benchmarks.
Semantic retrieval (Angular sample app, 2.6k files, 30 hand-crafted queries — Benchmark 1)
| code-memory | ripgrep |
|---|
| Recall@10 | 0.967 | 0.367 |
| MRR | 0.798 | 0.169 |
| nDCG@10 | 0.840 | 0.218 |
| p50 latency (ms) | 86 | 176 |
Topology queries (this repo, 111 Python files, symbol FalkorStore — Benchmark 3
| code-memory | ripgrep |
|---|
| "Who imports module M?" | 6 true positives | 7 (1 false positive) |
| "Who calls / references X?" | 7 typed edges | 14 lexical hits |
| Definitions of X | {file, start, end, kind} JSON | 1 grep line |
| Output for the agent to read back | 5-30× smaller | full file dump |
The pitch in one line: Recall@10 +164% vs rg, and topology results small enough that the agent reads them back without re-grepping. code-memory is 0.5-0.8 s per topology query vs rg's 30 ms — slower per call but 5-30× less context to feed back, which is what actually costs agent tokens.
Ingest once, sync everywhere — full semantic + graph, no quality tradeoff:
- Snapshot publish/sync: ingest once on a fast machine (CI / power dev box),
code-memory snapshot publish to a git branch, every other machine runs code-memory sync after git pull and gets the full state — vectors, graph, episodic — in seconds, no embedder run. Tested end-to-end: cold ingest → publish → wipe → sync restores retrieve / callers / definitions / importers exactly. With HEAD ahead of the snapshot, sync auto-applies the snapshot + runs the incremental delta.
- Persistent content-hash embedding cache makes any re-ingest on the same machine a SQLite scan: 55.7 s → 2.9 s = 19× faster when nothing changed. Full Recall@10, default
bge-m3.
- Linux + NVIDIA unlock for the cold-once-in-CI build:
EMBED_BACKEND=tei for 5-10× cold ingest vs Ollama, same bge-m3 weights, identical retrieval quality.
retrieve / callers / definitions / importers all stay on, all return the same answers they did before any of these speedups. See Performance & scale.
[!NOTE]
Using this with a coding agent? My personal Claude Code / OpenCode harness — hooks, agents, MCP wiring, and the code-memory integration — lives at dev/settings-opencode. Drop-in reference for plugging this memory layer into a real agent setup.
What is this?
code-memory gives a coding agent (Claude Code, OpenCode, Cursor, your own harness) a memory it can actually use:
- Structural memory — a symbol graph of every file, function, import, and call (FalkorDB).
- Semantic memory — dense embeddings of every symbol (Qdrant + Ollama-served
bge-m3), with an opt-in dense+sparse hybrid path for symbol-heavy corpora.
- Episodic memory — a task log of past prompts, plans, patches, and outcomes (SQLite + embedded recall).
It runs entirely on your machine. No OpenAI calls. No cloud. No vendor lock-in. Designed to be boring infrastructure you can wire into any harness via CLI, hooks, or MCP.
Why it doesn't blow up your context window
Naive "give the LLM your whole repo" approaches die fast: context windows are
finite, attention degrades with size, and tokens cost money. code-memory
sidesteps that by keeping the bulk of the knowledge outside the prompt and
injecting only a small, query-relevant slice when the agent actually needs it.
