Karpathy's LLM Wiki: an idea that quietly changes how we manage knowledge

Who is Andrej Karpathy

Before we get into the idea, a quick orientation on who Karpathy is.

• Stanford PhD. Founding member of OpenAI.
• Tesla AI Director from 2017 to 2024, leading FSD, Optimus, and Dojo.
• Now founder of Eureka Labs, an AI education company.
• Runs the YouTube series "Neural Networks: Zero to Hero", with around 7 million subscribers.

On April 4, 2026, he posted a short Twitter thread and a GitHub gist called llm-wiki.md. In three months it crossed 5,000 stars and 5,000 forks. The AI community treats it as the moment the conversation about personal knowledge shifted.

The problem with RAG

Karpathy's diagnosis is sharp:

Most of what we do with documents today looks like RAG: you upload files, the model retrieves chunks, generates an answer, forgets. Nothing is built up.

The picture is familiar. You drop a stack of PDFs into NotebookLM or a ChatGPT project. You ask a question. The model retrieves the most relevant chunks, writes an answer, and the conversation ends. Ask the same question tomorrow and it does the same dance again, with no memory of yesterday.

User: what is X?

RAG system:
  1. Retrieve top-K chunks
  2. LLM composes answer
  3. End — answer vanishes

Next time, same question:
  1. Retrieve again
  2. Compose again
  3. No accumulation

The thing to notice is the last line. RAG is stateless. It does not know what you read yesterday. It does not know your knowledge is compounding. Every conversation starts from zero.

The LLM Wiki solution

Karpathy's core insight:

The wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read.

The metaphor he uses is compilation. You do not recompile your source code every time you run a program. You compile it once and run the binary forever. Treat knowledge the same way.

Software:
  source code → compiler → binary → fast runs

Knowledge:
  raw sources → LLM compiles → wiki → fast queries

The wiki is a permanent, curated, cross-linked view of everything you have ingested. Every new source does not just sit in a vector index. The LLM reads it, extracts the key information, updates existing entity pages, revises summaries, flags contradictions, and strengthens cross-links. One source might touch ten to fifteen wiki pages.

Three layers

The architecture has three layers, each with a clear role.

Layer 1: raw sources

Your PDFs, papers, articles, podcast transcripts, your own notes. These are immutable. The LLM reads from them but never writes back. They are your source of truth.

Layer 2: the wiki

A directory of LLM-generated markdown files, with a structure like this:

wiki/
├── index.md                  # catalog of every page
├── 00 - Overview.md
├── 01 - Entities/            # people, projects, libraries
├── 02 - Concepts/            # ideas, methods
├── 03 - Sources/             # summaries of raw materials
├── 04 - Comparisons/         # side-by-side tables
└── 99 - Log.md               # append-only activity log

You rarely (or never) write these files. The LLM creates them, updates them, and maintains the cross-references. You read.

Layer 3: the schema

A configuration document that tells the LLM how to behave. In Claude Code, this is CLAUDE.md. In Codex or Pi, it is AGENTS.md. It defines page structure, naming conventions, frontmatter fields, wikilink rules, and the workflows for ingest, query, and lint. This is the file that turns a generic chatbot into a disciplined wiki maintainer.

Karpathy's own framing is the cleanest:

Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.

Three core operations

1. Ingest

You drop a new source into the raw collection. The LLM reads it, discusses three to five key takeaways with you, waits for confirmation, then creates or updates wiki pages and appends an entry to the log. One source might touch ten to fifteen wiki pages.

2. Query

You ask a question. The LLM reads the index, identifies relevant pages, reads them, and synthesizes an answer with [[wikilink]] citations. Good answers can be filed back as new wiki pages, so your own explorations compound into the knowledge base just like ingested sources do.

Outputs can be plain markdown, a comparison table, a Marp slide deck, a matplotlib chart, or anything else the schema allows.

3. Lint

Periodically ask the LLM to health-check the wiki. Look for contradictions between pages, orphan pages with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, and claims that newer sources have superseded. The LLM is also good at suggesting new questions to investigate and new sources to look for.

Four ways to actually build one

Way 1: pure markdown plus Claude Code

The fastest path. Ten minutes to a working wiki.

mkdir ~/my-llm-wiki
cd ~/my-llm-wiki
mkdir sources wiki
# write CLAUDE.md
# open Obsidian → Open vault
# run Claude Code: "ingest sources/first-source.pdf"

Good for personal use and small collections.

Way 2: wiki-llm (Python package)

By @LeoBR84p on GitHub. An eight-stage pipeline: Loader → Extractor → Planner → Writer → Evaluator → Editor → Lint → Repair. Pydantic contracts between stages, multi-backend LLM via instructor, BM25 chat without a vector store. Production-grade for teams.

Way 3: agentmemory / LLM Wiki v2

By rohitg00 on GitHub. agentmemory has 20K+ stars and is effectively the canonical implementation of Karpathy's pattern. The v2 gist adds confidence scoring, supersession, forgetting curves, knowledge graphs with typed edges, hybrid search (BM25 + vectors + graph), and event-driven automation.

Way 4: roll your own

For engineers who need full control. Combine LangChain or LangGraph with your preferred vector store and a custom lint pipeline.

Four deeper insights from Karpathy

1. The compilation analogy is the heart of it

Code is compiled once and run many times. Knowledge should be compiled once and queried many times. The wiki is your knowledge binary.

2. Obsidian as IDE is more than a metaphor

The Graph View, the wikilink resolver, the daily note, the Map of Content — these are real tools for navigating a real artifact. The LLM is the co-author. You are the curator.

3. The schema is not a prompt, it is a constraint

Without a schema, the LLM is a general chatbot. With a schema, it is a disciplined wiki maintainer. The schema is the small file that does the most work.

4. The wiki is an artifact, not a transcript

Chat history evaporates. Wikis compound. This is the philosophical inversion that makes the whole idea work.

Where this actually fits

Karpathy listed five application areas in the original gist.

• Personal: goals, health, psychology, self-improvement, journal entries, podcast notes.
• Research: going deep on a topic over weeks or months, building an evolving thesis.
• Reading: each chapter becomes a wiki pass, building out characters, themes, plot threads. The endpoint looks like Tolkien Gateway, built by one person.
• Business and team: internal wikis fed by Slack, meeting transcripts, project documents, customer calls.
• Anything accumulating: competitive analysis, due diligence, trip planning, course notes.

Six traps to avoid

1. Vague schema. "Be helpful" is not a schema. Specify word counts, format rules, wikilink conventions.
2. Full autopilot. Start with zero sources, let the LLM write a hundred pages, ship it. This produces garbage. Work one source at a time.
3. Too many sources. Curate ruthlessly. Only ingest what you actually want to accumulate.
4. No lint. Without regular Lint the wiki rots. Schedule it.
5. Too big. Five thousand pages will not query well. Keep the wiki under five hundred pages.
6. Broken markdown. LLMs produce plausible-looking but structurally broken markdown. Either constrain the schema tightly or use a tool like markdown-hero to type-check the output.

Why this is a paradigm shift

Traditional RAG answers the question: how do I find the right document?

LLM Wiki answers a different question: how do I make my knowledge compound?

Dimension	RAG	LLM Wiki
Problem solved	Cannot find	Does not accumulate
Retrieval target	Raw sources	Compiled wiki
Long-term value	One-shot	Compounding
Human-readable	No	Yes

Today's wiki is more valuable than yesterday's. Next week's is more refined than this week's. Three months in, it is a personal asset. RAG is a subset. LLM Wiki is the future.

Why this matters to me, personally

I already use RAG heavily — the Obsidian vault is the substrate, Hermes is the query layer. But every conversation is a fresh retrieval. Karpathy's framing turned that into a bug I could see clearly. The next move is obvious: stand up a real LLM Wiki on top of the vault, with a CLAUDE.md, and let Claude Code handle the bookkeeping while I handle the questions and the sourcing.

If you use Obsidian, you can do the same. If you do not, the cost of entry is about thirty minutes and one source.

Three takeaways

• RAG does not accumulate. LLM Wiki does. That is the entire difference.
• The core analogy is compilation: your raw sources are source code, your wiki is the binary.
• You can have one in thirty minutes. The earlier you start, the larger the compounding benefit.

Sources

Andrej Karpathy, llm-wiki, GitHub gist, April 4, 2026. Andrej Karpathy, Twitter thread, April 4, 2026. Rohitg00, LLM Wiki v2, GitHub gist. Rohitg00, agentmemory, GitHub repository, 20K+ stars. LeoBR84p, wiki-llm, GitHub repository. Leandro Bernardo, I Built Karpathy's LLM Wiki Twice, Towards AI, May 17, 2026. Urvil Joshi, Andrej Karpathy's LLM Wiki: Create your own knowledge base, Medium, April 20, 2026.