Karpathy's LLM wiki: how it works, and what a team needs to add

What is Karpathy's LLM wiki?

It is a pattern, which he calls an idea file: you paste it into Claude Code, Codex or another agent, and the agent builds the specifics with you. The contrast is with RAG, where the model rediscovers the same fragments on every query. Here the model files what it learns once, cross-links it, and keeps it current. In his words, “You never (or rarely) write the wiki yourself”. He keeps the agent open on one side and Obsidian on the other.

Three operations run it. Ingest: drop in a source and the agent summarizes it, updates the pages it touches (often 10 to 15) and logs it. Query: the agent answers from the wiki with citations, and a good answer is filed back as a new page. Lint: when you ask, it checks for contradictions, stale claims that newer sources superseded, orphan pages and missing links.

Two files hold it together. index.md lists every page with a one-line summary, and the agent reads it first on every query; he reports that this works at about 100 sources and hundreds of pages without embeddings, and suggests a local search engine such as qmd beyond that. log.md is an append-only record of ingests, queries and lint passes.

Which tools implement the LLM wiki?

Many, most within two weeks of the gist. The ones with the most use, as of 2026-10-06:

Look at the third column. Nearly everything built on the gist kept its first word: personal.

Does an LLM wiki actually work?

For synthesis, there is early evidence that it does, at a cost. A preregistered comparison, arXiv:2605.18490 (v3, 2026-10-02), had an LLM-compiled wiki and single-round vector RAG answer the same 13 questions over 24 papers. The wiki scored much better at connecting findings across papers, spent about 21 times more tokens per query, and showed no citation-support advantage on human labels.

The index is the weak assumption. In arXiv:2607.04576 (2026-07-06), run on a real 709-page LLM-maintained wiki, a pilot found that a capable tool-using agent never loaded the index; it guessed a page's path from the question and read it directly. Both are single studies on small corpora, not yet peer reviewed.

On Hacker News, the field reports were good for one person (one reader turned three books into 210 pages, and the wiki caught a real contradiction between two of them). The objections were about time: a point beyond which the agent cannot keep up, and a lint that compares every page with every other.

What breaks when a team shares an LLM wiki?

The gist gives teams one bullet: an internal wiki fed by Slack threads, meeting transcripts and project documents, “possibly with humans in the loop reviewing updates”. It also notes that git gives you collaboration for free. Git records who changed a line. It does not say whether the line is true.

When teams tried it, the failures had a pattern. In the Show HN thread for a wiki that agents maintain, one commenter warned that six months in, entries are “confidently wrong” and lint cannot tell which; another, that bad entries get cited by other agents; a third put it as “Everyone is writing. Nobody is reading.” Taktile, which runs one over Notion and Google Drive, found its sources are edited by people who do not know a wiki depends on them, and that errors in an index the LLM writes itself compound.

The measured version is in work on shared agent memory, which is not about wikis but has the same shape: many writers, one store, many readers. In arXiv:2609.30813, once an uncontested false belief was in the shared store, agents asserted it in 97 to 99 percent of probes. Gating what got in by the declared source type held false adoption to 6 to 9 percent, against 22 to 47 percent for the other policies tested.

What does a team version of the LLM wiki need?

Three things, and each replaces a habit one person can get away with.

Take one decision through it. In #eng-payments the team agrees that webhook handlers acknowledge with a 200 and enqueue, and never do the work inline. In a personal wiki, it gets in if the one person who ingests that thread notices it. In a team wiki without a gate, it gets in along with every half-decision from the same thread, and agents cite them all alike. With a gate, a date and a count, it is approved, dated to the day it was said, handed to the session editing a webhook handler, retired when the queue is replaced, and you can see how often it was used.

One caution from a builder of these tools: a read count is not a truth signal. “Frequently asked is not the same as true”, as the karpathy-llm-wiki README puts it. A count tells you what is used, so you can retire what is not. It does not tell you what is right.

Where Harbor fits

Harbor is that team version for one kind of page: the decisions an engineering team makes. It reads where the team decides: Slack threads, the first source Karpathy lists for a team wiki, plus pull request reviews and docs. A person approves what it finds, or a policy you set approves the routine ones. A rule that contradicts a live one always waits for a person. Each rule is dated by the message it came from and can carry an end date, and when one replaces another, the sessions that used the old one are told. Claude Code, Codex and Cursor get the rules that apply to the task at session start, and every rule shows how often it was served and how often an answer cited it. A cite is evidence that a rule was used, not proof that it was obeyed; the method is in served vs cited.

For a research wiki of your own papers or books, use the gist as written. It is very good at that.