What Is Andrej Karpathy's LLM Wiki? How to Build a Knowledge Base

An LLM wiki is a persistent, compounding knowledge base that an AI agent builds and maintains in structured markdown. Unlike a standard RAG (Retrieval-Augmented Generation) system that retrieves static chunks on every question, an LLM wiki compiles information once into living entity pages and summaries, then keeps them current. Popularized by Andrej Karpathy, the pattern treats your knowledge as a version-controlled codebase, and the model as a disciplined maintainer that cross-references new data into existing files rather than re-deriving context from scratch each time.

The approach leans on the expanded context windows of frontier models to give you a "second brain" that grows more valuable with every source. By keeping a human-readable directory of interlinked text files, you turn the LLM from a generic chatbot into a structured knowledge engine. Synthesis happens during ingestion, so queries become deterministic routing over a curated repository instead of a fresh scramble through raw documents.

What is an LLM wiki? The "stop retrieving, start compiling" idea

The LLM wiki is a shift from "rediscovering knowledge from scratch" to "incremental compilation." In a standard RAG setup, the model retrieves fragments of raw files every time you ask something, often missing broader context or failing to synthesize across documents. The wiki pattern treats the knowledge base as a codebase that is continuously compiled: every new source is a chance for the agent to update entity pages, revise topic summaries, and flag contradictions.

The result is a compounding artifact. Because synthesis already happened during ingestion, the wiki gets richer with every source you add. The agent establishes cross-references immediately and states the relationships between concepts explicitly in the text. Instead of the model piecing together fragments at query time, it navigates a pre-structured map of information it has already processed and filed.

The user–agent split is central. You act as director and curator, supplying high-quality sources and steering the focus of research. The model handles the grunt work of bookkeeping — summarizing, cross-referencing, and maintaining the index. That removes the main reason people abandon wikis: the maintenance burden. Using frontier models like Claude Opus 4.8, the agent works on a local directory of files, turning the filesystem into its working memory.

How is an LLM wiki different from RAG?

The differences come down to infrastructure complexity, retrieval reliability, and cost. RAG is a probabilistic system that relies on vector embeddings and cosine distance to find "similar" text; an LLM wiki is deterministic, relying on intent-based routing through structured navigation, which sidesteps the "retrieval misses" common to semantic search.

• Token efficiency. A naive RAG approach might load several full PDFs (say, 60,000 tokens) to answer one question. A curated markdown wiki covering the same ground often needs only 2,000–3,000 tokens. That 95% reduction happens because the agent is routed to a dense, pre-synthesized summary rather than raw context.
• Infrastructure. RAG needs a pipeline: embedding models, a vector database (Pinecone, Weaviate), and chunking logic. An LLM wiki needs only a folder of markdown files and a capable agent like Claude Code.
• Reliability. RAG systems suffer "silent failures" where similarity search returns irrelevant chunks. In an LLM wiki, the agent reads selectively: it consults a routing file, identifies the specific pages it needs, and reads only those in full.
• Auditability. Vector databases are black boxes. A markdown wiki is a plain-text directory you can version-control with Git, so you can track every change the agent makes and review how its knowledge evolved.

The three-layer architecture: raw, wiki, and schema

A functional LLM wiki is organized into three layers that define how the agent interacts with data.

1. Raw sources. An immutable source of truth: original articles, transcripts, PDFs, and images (stored in /raw/assets/). The model reads from these files but never modifies them.
2. The wiki. The LLM-owned directory of markdown files representing entities, concepts, and logs. This layer is heavily interlinked with [[wiki links]] to form a navigable graph of knowledge.
3. The schema. The configuration layer, defined in files like CLAUDE.md. It holds the naming conventions and workflow rules — the "disciplined maintainer" layer that stops the agent from acting as a generic chatbot and forces it to follow strict bookkeeping.

During a session these layers work as one system: the agent uses the schema to understand how to process a new file from the raw layer and how to integrate that information into the interlinked pages of the wiki.

The three core operations: ingest, query, lint

Maintenance is governed by three operations.

• Ingest. When a new source lands in /raw, the agent processes it. A single ingest may trigger updates across 10–15 interlinked pages, append a record to the log, and update the main index.
• Query. The agent uses index.md as a routing file. Asked a question, it consults the index to find relevant pages and synthesizes an answer with specific citations, avoiding "context-stuffing" by reading only the files it identified while routing.
• Lint. A health-check pass: the agent scans the wiki for contradictions, stale claims superseded by newer data, and "orphan pages" with no inbound links.

A typical log.md entry follows a strict chronological format so you can parse it with standard command-line tools:

## [2026-04-12] ingest | The Bitter Lesson — Rich Sutton
 
- Created: [[The Bitter Lesson]], [[Rich Sutton]]
- Updated: [[Reinforcement Learning]], [[Moore's Law]]
- Status: Integrated; added cross-links to [[Software 2.0]].

How to build your own LLM wiki with Claude Code

You can stand up a personal LLM wiki in a few minutes using Obsidian as the interface and Claude Code as the agent.

1. Environment. Install Obsidian to serve as the "IDE" and create a new vault (e.g. ~/my-wiki).
2. Folder structure. Inside the vault, create /raw, /raw/assets, /wiki, and /templates.
3. Agent. From a terminal in the vault, launch Claude Code: npx @anthropic-ai/claude-code.
4. Schema. Create a CLAUDE.md at the root to define the agent's role and rules.

Here is a minimal CLAUDE.md to start from:

# Role: LLM Wiki Maintainer
 
You are a systems knowledge engineer for this vault.
 
- `raw/`: original source data. Never modify it.
- `wiki/`: compiled markdown files. Prefer a flat structure.
- Every file needs YAML frontmatter: title, tags, summary, date.
- Use [[wiki links]] for every important entity.
- On `ingest`: always update `index.md` and append to `log.md`.

With that in place, you drive the wiki in natural language. To pull in a new source, for example: claude "Ingest the new file in raw/, update backlinks and the index". The agent reads, extracts, and writes the markdown files in seconds, then reports which pages it created and updated.

Best practices for a queryable knowledge base

An effective wiki is optimized for the model to skim. The most important rule is one topic per file. Splitting knowledge into focused entity pages lets the agent locate information without loading huge, unrelated documents into the context window — a 10,000-word catch-all is always harder to query than ten focused 1,000-word notes.

Put a one-line summary at the top of every note. That summary lets the agent scan index.md or the head of each file to route a query without spending the tokens to read full bodies. Consistent aliases matter too: tag "Retrieval-Augmented Generation" and "RAG" as the same entity so the agent links them, and use [[wiki links]] liberally so it has a rich graph to traverse for associative reasoning.

Power-user tooling

• Obsidian Web Clipper. Use this browser extension to convert articles straight to markdown in your /inbox, then let the agent triage and file them in batches rather than organizing by hand.
• Local image downloading. In Obsidian, set the attachment folder to /raw/assets/ and bind a hotkey to "Download attachments for current file," so the model references images locally instead of relying on external URLs that break.

When to use an LLM wiki vs RAG

The choice is a trade-off between scale and precision.

For production, a hybrid is often optimal: use an LLM wiki for core product and policy knowledge — the "foundational" layer that always sits in context — and use RAG for large historical archives, the "archival" layer queried only when needed. The practical advice is to start simple: validate the wiki pattern against your core documentation before investing in heavy vector infrastructure.

References

• llm-wiki · GitHub — Andrej Karpathy
• Karpathy's LLM Wiki: 95% Less Token Use Than RAG — MindStudio
• Andrej Karpathy's LLM Wiki: Create Your Own Knowledge Base — Urvil Joshi
• LLM Wiki vs RAG: A Decision Framework for AI Knowledge Bases — MindStudio
• What Is Andrej Karpathy's LLM Wiki? How to Build a Personal Knowledge Base With Claude Code — MindStudio
• Fable 5 + Karpathy's LLM Wiki is Basically Cheating — YouTube