What Is an LLM Wiki? Karpathy's Pattern and How to Build One

Think of it as a private Wikipedia for one topic that an AI agent writes and keeps current. You drop in sources; the agent reads each one once, updates every page it affects and keeps the links in order, so your questions are answered from an organized wiki rather than from raw files. Below: where Andrej Karpathy's idea came from, how it differs from RAG and a second brain, and a seven-step setup with prompts for Claude Code or Codex.

Where the Idea Comes From

On April 2, 2026, Andrej Karpathy, a co-founder of OpenAI and former head of AI at Tesla, wrote on X that more and more of his AI use went into maintaining knowledge rather than writing code. He collected sources for a research topic in a raw/ folder and had an LLM compile them into a wiki of Markdown pages. That wiki had grown to about 100 articles and 400,000 words, and the agent kept its own index files and summaries well enough that he didn't need a RAG pipeline at that size.

Two days later, on April 4, he published the pattern as a gist called llm-wiki.md. It isn't a tool or a repo. It's an idea file, written to be pasted into your own agent (Claude Code, Codex, OpenCode and the like), which then works out a concrete setup with you. The one-line pitch from the gist: "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase." You choose the sources and ask the questions; the LLM does the writing, filing and cross-referencing.

Where it stands in October 2026. The gist is still the single version from April 4. It shows 5,000+ stars and 5,000+ forks, and people are still adding comments: the latest are from late October. Most of the growth happened around it: desktop apps, Obsidian plugins and installable agent skills built on the idea (see ready-made implementations below).

LLM Wiki vs RAG: Compile Once vs Retrieve Every Time

Most AI-plus-documents products work as RAG (retrieval-augmented generation): you upload files, and at question time the model fetches relevant chunks and improvises an answer. It works, but every question starts from zero. Nothing accumulates between questions.

An LLM wiki inverts this. When a new source arrives, the LLM reads it right away, extracts what matters and integrates it into existing pages: it updates entity pages, revises summaries and flags claims that contradict earlier material. Knowledge is compiled once and then kept current, so each answer starts from an already-synthesized picture rather than raw fragments.

RAG still has its place. The wiki's index file works at the scale Karpathy describes: about 100 sources and a few hundred pages. Past that, the agent can no longer read the whole index for every question, and you add search. The gist suggests qmd, a local search engine for Markdown files that combines keyword and vector search and that an agent can call from the command line or through MCP. A large document archive that many people query and nobody curates is still a job for classic RAG.

How It Works: Three Layers and Three Operations

The architecture in the gist is deliberately minimal:

1. Raw sources: articles, papers, transcripts, data files. They are immutable: the LLM reads them but never edits them.
2. The wiki: LLM-generated, interlinked pages, such as summaries, entity pages, concept pages and comparisons. The LLM owns this layer entirely; you read it.
3. The schema: a conventions file (CLAUDE.md for Claude Code, AGENTS.md for Codex) that tells the agent how the wiki is structured and what to do when ingesting, answering and maintaining. This is what turns a generic chatbot into a disciplined librarian.

Two files keep the wiki navigable as it grows. index.md is a catalog: every page with a link and a one-line summary, updated on every ingest. The agent reads it first when it answers a question. log.md is an append-only history of ingests, questions and checks. If every entry starts the same way, for example ## [2026-10-27] ingest | Pricing study, one grep lists the latest entries.

Day to day, the wiki runs on three operations: ingest (drop in a source and the LLM integrates it; a single article can touch 10–15 pages), query (ask questions; good answers are filed back as new pages) and lint (a periodic health check for contradictions, stale claims and orphan pages with no inbound links).

How to Build an LLM Wiki: 7 Steps with Prompts

The steps below use Claude Code; with Codex, name the rules file AGENTS.md instead of CLAUDE.md. Any agent that can read and write files in a folder will do. Treat the prompts as starting points: the gist leaves the details to you and your agent on purpose, and your schema will change as you learn what works.

1. Pick one topic and create the folder

Start narrow: one research question, one book, one client or one course. A wiki about everything has no clear page types and no way to tell whether it's any good. Make the folder a git repository, so you can review and undo every change the agent makes.

mkdir pricing-wiki && cd pricing-wiki
git init
mkdir raw wiki
touch index.md log.md

After the next step, the folder looks like this:

pricing-wiki/
├── raw/        # sources: clipped articles, PDFs, transcripts (never edited)
├── wiki/       # pages the agent writes and maintains
├── index.md    # catalog: every page with a one-line summary
├── log.md      # append-only history of ingests, queries and checks
└── CLAUDE.md   # the schema: rules for the agent (AGENTS.md for Codex)

2. Let the agent draft the schema

Don't write the rules file from scratch. Open Claude Code in the folder, give it Karpathy's gist and let it interview you first:

Read Karpathy's LLM wiki idea file:
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

We're building an LLM wiki about [topic] in this folder.
Before writing anything, ask me up to five questions about my goals and sources.
Then draft CLAUDE.md with:
- folder rules: raw/ is read-only; you write only in wiki/, index.md and log.md
- page types: source summary, entity, concept, comparison, open question
- page format: YAML frontmatter (type, sources, updated), a one-line summary, [[links]]
- step-by-step workflows for ingest, query and lint
- log entries that start with "## [YYYY-MM-DD] operation | title"
Show me the draft before you save it.

3. Ingest your first source

Save one article into raw/ as Markdown (Obsidian's Web Clipper does it in one click) and ingest it. Go one source at a time at first: Karpathy himself prefers to stay involved, read the summaries and tell the agent what to emphasize.

Ingest raw/2026-10-pricing-study.md.
1. Tell me the 3–5 key takeaways before you write anything.
2. Write a summary page in wiki/sources/ that links to the raw file.
3. Create or update the entity and concept pages it affects, with [[links]] both ways.
4. If it contradicts an existing page, keep both claims, cite both sources and mark the conflict.
5. Update index.md and add one entry to log.md.
List every file you changed.

4. Review the changes, then commit

Commit the new source before the ingest and the result after it. Then every ingest is one change you can read and undo:

git add raw/ && git commit -m "source: pricing study"
# run the ingest prompt, then:
git status        # which pages changed or were added
git add -A && git commit -m "ingest: pricing study"

Before the second commit, check three things. The summary says what the source says. New links point to the right pages. Nothing outside wiki/, index.md and log.md was touched. If something is off, tell the agent what to fix and add the missing rule to CLAUDE.md, so it doesn't make the same mistake twice.

5. Ask questions and file good answers back

Questions are where the wiki pays off. Ask the agent to answer from the wiki rather than from its own memory, and to say what's missing. A good comparison or analysis shouldn't disappear into chat history: saved as a page, it becomes material for the next question.

Using only wiki/ (read index.md first), answer: [your question]
Cite the pages you used as [[links]] and say what the wiki doesn't cover yet.
If the answer is worth keeping, save it as a page in wiki/answers/,
link it from related pages, update index.md and log the query.

6. Run a lint pass every week

Lint is the maintenance nobody does by hand. Ask for a report first and fix things in a second step, so you see what the agent wants to change before it changes it.

Run a lint pass on wiki/. Don't change any pages yet.
Write a report to wiki/lint/[date].md that lists:
- contradictions between pages, with both sources
- claims that newer sources have replaced
- orphan pages with no inbound links, and broken [[links]]
- concepts mentioned on three or more pages that have no page of their own
- questions worth researching next and sources to look for

7. Turn the prompts into skills and add search as it grows

Once a prompt works the same way a few times, save it as a skill or a custom command, so you don't paste it again. In Claude Code, a skill is a folder with a SKILL.md file that the agent loads when a task matches it; ready-made LLM wiki skills exist too (see the list below). When index.md grows past what the agent can read in one go, add search such as qmd or split the wiki by topic.

LLM Wiki in Obsidian

Andrej Karpathy's own setup is the agent in a terminal on one side and Obsidian on the other. The agent edits; he reads the result as it changes, follows links and checks the graph view. Open the wiki folder as an Obsidian vault, and three tools help right away. Web Clipper saves articles into raw/ as Markdown. Graph view shows which pages became hubs and which are orphans. The Dataview plugin turns the agent's frontmatter into tables, such as every page that cites a given source.

Ready-made plugins exist as well: the Karpathy LLM Wiki plugin had about 65,000 downloads by late October 2026. Writing your own CLAUDE.md first still shows you exactly what the agent is told. The full Obsidian setup, with the vault layout, permissions, Obsidian CLI checks and a way to color agent-written notes in graph view, is in our guide to running an LLM wiki in Obsidian with Claude.

LLM Wiki in Notion or a Team Wiki

If your notes and databases already live in Notion, you don't need to move them to Markdown. Connect an agent through Notion's MCP server and let it read and write pages directly; databases give you page types and properties out of the box. We documented this setup end to end, with daily workflows, in LLM Wiki for Notion: Claude Second Brain + 3D Knowledge Graph.

For a team, the gist describes the same loop fed by Slack threads, meeting transcripts and project documents, with people reviewing the updates. The wiki stays current because the LLM does the maintenance nobody on the team wants to do.

LLM Wiki on GitHub: Ready-Made Implementations

Karpathy's gist is the reference. These implementations of it were the most visible ones in search on October 27, 2026:

Ready-made tools save setup time, but they decide the schema for you. Read their rules before you point them at private notes, and remember that everything you ingest is sent to the model you configured.

LLM Wiki vs Second Brain vs Knowledge Base

The terms overlap, and search results mix them up constantly. The clean way to separate them:

That last column is the whole story. People abandon wikis and second brains because the bookkeeping grows faster than the value: updating cross-references, reconciling old claims with new sources. The LLM doesn't get bored, which is why this pattern sticks where manual systems quietly die, and why Karpathy's setup is often called an AI second brain.

One more term causes confusion. An "LLM knowledge base" usually means company documents that a chatbot searches with RAG. An LLM wiki is narrower: pages that the model itself writes and maintains, so knowledge accumulates between questions.

For the second brain method on its own terms (CODE, PARA, the apps and what AI changes), see our guide to what a second brain is.

Limits and Common Mistakes

• Errors compound. A wrong summary becomes a source for later pages. Keep raw/ read-only, make every page cite its sources and review the changes, especially in the first weeks.
• Scale. The index file works for about 100 sources and a few hundred pages. Beyond that, add search or split the wiki by topic.
• Cost. One source can touch 10–15 pages, so an ingest uses far more tokens than a chat answer. Batch-ingest only once the schema is stable.
• Privacy. Everything the agent reads goes to the model provider. Keep private material out of the folder, or use a local model.
• Instructions hidden in sources. A clipped web page can contain text written for AI agents. Say in CLAUDE.md that sources are material, not instructions, and check what each ingest changed.
• Drift. Without regular lint passes, duplicate pages and stale claims creep in. A weekly lint keeps the wiki honest.

Where the Knowledge Graph Fits

A wiki is text, but its structure is a graph: pages are nodes and links are edges. Give the links a meaning, such as cites, contradicts or part of, and you're halfway to a knowledge graph. Karpathy's gist calls Obsidian's graph view the best way to see the shape of a wiki: what connects to what, which pages are hubs and which are orphans. The lint operation is a graph health check in all but name, and some implementations, such as nashsu/llm_wiki, ship their own graph view.

The graph matters even more when your LLM wiki lives in Notion, because Notion has no built-in graph view. IVGraph fills that gap: it shows your workspace, with every page, backlink and database relation, as an interactive 3D graph, so you can watch the wiki your agent is building take shape. It's free up to 500 nodes. IVGraph has no MCP server yet; agents can read the same graph through a read-only API with a key on the Pro and Max plans.

FAQ