Karpathy's LLM Wiki vs. Synapse MCP: Why Code Needs a Graph, Not Prose

In April 2026, Andrej Karpathy published a gist describing an "LLM Wiki" — a persistent, structured knowledge base that an LLM reads instead of re-deriving context from scratch every session. His core insight: knowledge should compound. Build it once, keep it current, query it — don't grep raw files on every turn.

The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don't get bored. — Karpathy

He's right. And it's the same conclusion we'd been building toward since January — but for codebases specifically, and with one crucial difference. Karpathy's wiki is brilliant for unstructured knowledge: articles, notes, books. When you apply it to a codebase, several structural mismatches emerge. The deeper we dug, the clearer it became that code doesn't want prose summaries. It wants a graph.

We started in Python

As developers, we needed agents to be far more accurate than they are. Watching an agent re-grep the same files every session isn't just tedious — it's expensive in token usage. The idea was simple: a realtime-updated graph that teaches the LLM how all the code is structured, so agents are faster and more reliable when touching a codebase. Stop grepping. Start knowing.

We built it in Python first. The graph was correct, the queries were accurate, the structure was sound — but Python was too slow for a live in-memory graph. Concurrent indexing across multiple cores was fighting the GIL, and the graph was a static artifact, not a live one. So we rewrote it in Elixir on the BEAM.

What Elixir gives you that Python can't

Elixir's BEAM gives us three things Python fundamentally cannot:

• In-memory ETS tables. The entire graph lives in process memory with sub-millisecond reads. No file I/O on the query path, no deserialization, no cold start. The agent asks "who calls this function?" and gets an answer in microseconds, not seconds.
• Concurrent indexing. The BEAM runs one OS thread per core with preemptive scheduling. On a 74,000-file codebase like the Linux kernel, we discover all files in roughly two seconds and stream chunks into the graph across 24 concurrent workers — without blocking a single query. Python's GIL means one thread at a time for CPU work.
• The graph updates as files change on disk. Not as you type — through OS-level file watchers that stream change events to the indexer in milliseconds. The graph is never stale. When a file saves, the relevant chunks re-index in the background, and the agent always reads the current state of the codebase.

Code is already structured — a wiki de-structures it

Karpathy's insight is that the wiki is a persistent, compounding artefact. The problem: so is source code — it's called the source code itself. When you summarise a function into a markdown prose page, you lose the exact signatures, the arity, the clauses, and the precise call sites that tell you who depends on it. And that prose goes stale the moment the code changes.

We don't summarise code into prose. We build a code graph — chunks with exact line ranges, edges representing the real call relationships, embeddings of the actual functions. The source of truth is always the code, never a secondary document about the code.

Ingesting a wiki is a manual ceremony; code changes constantly

Karpathy's flow: drop a new source into the raw collection and tell the LLM to process it. For articles that's fine — you read one thing at a time. But in a codebase, every file you edit is a new source. You'd be ingesting continuously, forever.

So we watch the filesystem and re-index automatically on every change. No ceremony. Edit a function, the graph updates. The index is always current — which is exactly what an agent editing your code needs.

Impact analysis needs a graph, not prose summaries

Karpathy's lint operation asks: are there contradictions? Stale claims? Orphan pages? The coding equivalent is sharper and more consequential: if I change this function's signature, what breaks? Prose can't answer that. You need the actual caller graph.

Our explore-graph query hands the agent the precise blast radius — every call site, and which tests would fail — before a single line is touched. A wiki of summaries might note "this function is used in the pipeline," but it can't enumerate the evidence you need to make a safe edit.

The wiki index breaks at code scale

Karpathy acknowledges his approach works well at moderate scale — roughly a hundred sources and a few hundred pages. A serious codebase is orders of magnitude larger, and a central index collapses before you reach the relevant chunk, blowing the context window.

Synapse combines semantic embeddings, lexical search, and graph traversal with compact payloads, so the agent gets exactly the context it needs without reading everything. You stop paying to re-derive the codebase and start spending tokens on the actual work.

A wiki needs constant linting; a graph stays fresh

Because an LLM writes the wiki from code that keeps changing, the wiki drifts from reality. That's why Karpathy's flow leans on periodic health-checks — look for stale claims, orphan pages, missing cross-references. The maintenance burden is real, even when an LLM does the checking.

Synapse has no drift problem. There is no secondary representation to fall out of date. The graph is derived from the current file state, always.

The analogy Karpathy himself draws

He writes: "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase." For knowledge domains, that's exactly right. But for actual coding, the IDE already exists, the LLM already is the programmer, and the codebase already is the codebase. What was missing was a way for the LLM to hold a persistent, queryable, graph-aware understanding of that codebase across sessions — not a prose translation of it.

That's precisely what Synapse is.

Where we went further: read-write, not read-only

Karpathy's wiki is read-only. It describes what's in the codebase; it doesn't protect it. We built write safety into the graph itself.

When the agent wants to modify a file, the graph simulates the edit in memory, checks every caller that depends on the changed symbol, runs standard linters against the proposed content, and rolls back if anything would break — explaining to the LLM what will happen before it touches disk. And because the caller graph is precise, that check is fast: one or two queries gives the agent a full understanding of what's needed.

That's the difference between a knowledge tool and a safety tool. The graph tells you what the codebase looks like. Synapse tells you whether it's safe to change it.

We dogfood this every day

Every tool we build runs on top of Synapse. When we develop Synapse itself, we use Synapse to navigate its own codebase — the indexer indexes our Elixir source, the graph stores the call edges, the dead-code checker tells us which functions are safe to remove. When an agent refactors a module, it asks Synapse what calls the function it's about to change, gets the blast radius, and decides whether the edit is safe before writing a single line.

This isn't a demo. It's our daily workflow. The graph that teaches the LLM how our code is structured is the same graph that teaches it how not to break it.

The numbers

We benchmarked Synapse against grep-based agents on a 500k LOC monorepo security audit:

Same codebase, same model, same security audit. 60% fewer tokens, 2.2× faster, half the tool calls, same findings. That's what a persistent graph does: it stops the agent from re-reading files it already read.

On the Linux kernel (74,619 files): Synapse discovers all files in about two seconds, holds the graph in 877 MB of RAM, and answers live queries in 148 ms while the indexer is still running.

Getting better the more you use it

Knowledge compounding is real, and it's the one place a wiki-style layer adds value on top of a graph: when an agent answers a subtle cross-cutting question, that answer gets filed back and sharpens future queries. Our knowledge cache already approximates this, and it's the direction we're pushing hardest. The graph that compiles knowledge today is the same substrate that will let agents reason about code overnight, test their own assumptions, and come back sharper.

The TL;DR

Karpathy's wiki is the right tool when your raw material is prose and your output is synthesis. Synapse is the right tool when your raw material is code and your output is safe, precise, context-aware edits. They solve fundamentally different information problems.

What's next

Synapse is the precursor to something much bigger we're building — making agents dream, learn, and be better when they wake up. The free tier is the full product: 50+ languages, unlimited repos, no time limit, no credit card. Pro adds the safety layer for $19/month.

curl -fsSL https://downloads.synapse-mcp.dev/install.sh | sh