Karpathy's LLM Wiki: How It Works and How to Build One

An LLM Wiki is a knowledge base whose pages are written and maintained by an agent. You supply source documents; the agent reads them and compiles a wiki of .md files. The result is a set of interlinked pages holding summaries of everything in the source folder, concept articles, and backlinks between them ([evidence ev-202]). The agent owns the writing. You own the sources and the judgment calls.

Karpathy separates the system into three layers, and the separation is what keeps it stable ([evidence ev-201]).

The schema file is the layer people skip. It tells the agent where sources live, how pages are named, and what to update after every ingest. Without it, each session starts from zero and the wiki drifts.

Day to day, the pattern runs on three operations ([evidence ev-201]).

Each operation is a conversation, not a button. Ingest keeps a human in the loop: you read the source, talk through the takeaways, and then the agent writes the summary page and updates the index, the relevant entity and concept pages, and the log ([evidence ev-201]). A single source can touch ten to fifteen wiki pages ([evidence ev-201]). That number is the point. A source is not filed into one folder; it is woven into the pages it relates to, so its claims strengthen or challenge what is already written. Reviewing after each ingest is how you catch the moments where the agent misreads a source. Batching defeats this: the agent produces pages faster than you can check them, and errors compound quietly.

The economics are simple. A static knowledge base is worth what you put into it. A maintained wiki is worth what you put into it plus every connection drawn between the pieces ([evidence ev-201]). Each new source does not just add a page; it links into pages that already exist, and those links make later sources easier to place. This is the same dynamic behind Compounding Knowledge: the value lives in the edges, not only in the nodes.

Karpathy uses Obsidian as the interface for the wiki, and Obsidian Web Clipper to turn web articles into markdown before they enter the source folder ([evidence ev-202], [evidence ev-210]). The choice matters less than the underlying format. Obsidian stores notes as local markdown files in a plain folder that other tools can read and edit ([evidence ev-210]), which is exactly what an agent needs. Nothing is locked in a database, and the wiki stays portable. This is also why the pattern fits Personal Knowledge Management: the same plain-text, link-first habit, with an agent doing the filing.

Two files tie the wiki together. index.md is the content catalog, the map of what exists, so the agent can find the right pages before it starts writing ([evidence ev-201]). log.md is the chronological record, kept greppable so a human or an agent can reconstruct what happened and when ([evidence ev-201]). The Index File answers "what do I have?" The Changelog answers "what changed?" Both are cheap to maintain and expensive to rebuild after the fact.

At roughly a hundred sources the index is enough, and the agent can read it and navigate. Beyond that scale it stops being a useful map, and Karpathy points to an optional command-line tool, qmd, which adds local hybrid BM25 and vector search with LLM re-ranking, exposed both as a CLI and as an MCP server ([evidence ev-201], [evidence ev-207]). The Model Context Protocol server is what makes qmd fit the pattern: the agent calls the search tool the same way it calls any other. Search is an addition, not a replacement for the compiled pages. For how retrieval fits, see LLM wiki vs RAG and add embeddings to a knowledge base.

Here is the grounded method, with no hidden infrastructure.

1. Pick one topic narrow enough that a few dozen sources can cover it.
2. Create two directories: raw/ for sources and wiki/ for the compiled pages.
3. Add a schema file (AGENTS.md or CLAUDE.md) describing your conventions and the three workflows: ingest, query, and lint.
4. Collect five sources on the same topic and save them into raw/ as Markdown.
5. Ingest one source at a time. Ask the agent for a summary, review it against the source, and correct it before moving on.
6. After each ingest, have the agent update index.md and append a dated entry to log.md.
7. Query the wiki and make the agent cite the pages it used. If an answer is worth keeping, file it back as a new page.
8. Run a lint pass periodically and resolve what it finds.
9. When the wiki outgrows the index, add qmd for hybrid search.

Start with five sources, not fifty. The pattern teaches itself at small scale, and mistakes are cheaper to find when the wiki is small.

The pattern has an ancestor. In 1945, Vannevar Bush described the Memex, a personal store of a person's books and records, with associative trails between them ([evidence ev-208]). The Memex was never built at scale, and the reason was maintenance: keeping the trails current by hand was too much work. That is the part the LLM absorbs. The agent does the filing, the linking, and the health checks that made the original idea impractical ([evidence ev-208]).

Three clarifications keep expectations honest. It is not Retrieval-Augmented Generation with a folder in front: RAG fetches passages at question time, while a wiki compiles them ahead of time into durable pages. It is not a general Agent Memory store, because the output is a readable, editable artifact rather than opaque internal state. And it is not a one-time export. A wiki that stops being maintained decays into a static archive, and the compounding stops with it.

• Dumping many sources in at once and reviewing none of them.
• Letting the agent edit files in raw/, which breaks the immutable-source rule.
• Skipping the schema file, so every session reinvents the conventions.
• Treating lint as optional, which lets contradictions and orphan pages accumulate.
• Letting the wiki grow past the index without adding search.
• Filing each source into one page instead of weaving it into related pages.

What is Karpathy's LLM Wiki?

It is a pattern, not a product: an agent incrementally compiles source documents into a wiki of markdown pages with summaries, concept articles, and backlinks ([evidence ev-201], [evidence ev-202]).

Is the gist a program I install?

No. It is an idea file meant to be pasted into an LLM agent, which then sets up the pattern using its own tools ([evidence ev-201]).

Do I need Obsidian to build one?

No, but Obsidian is the interface Karpathy uses, and its local markdown storage is convenient because any tool can read and edit the files ([evidence ev-202], [evidence ev-210]).

How many wiki pages does one source touch?

It varies, but a single source can touch ten to fifteen wiki pages ([evidence ev-201]).

When do I need search instead of just an index?

At roughly a hundred sources the index is enough; beyond that, an optional CLI such as qmd adds hybrid search with an MCP server ([evidence ev-201], [evidence ev-207]).

Building and maintaining an LLM wiki is a real project: sources to collect, a schema to write, pages to review, and lint passes to run. The XKnow Knowledge Base is the shortcut. It is a pre-compiled LLM wiki you own, built on the same pattern and compiled around SEO and SaaS, delivered as markdown so your agent can query it, extend it, and keep it under your control. You skip the build and start from a wiki that already has its links in place.

• What is an LLM wiki
• LLM wiki vs RAG
• add embeddings to a knowledge base