Book
The LLM Wiki (Karpathy)
Also known as: Karpathy LLM wiki, LLM Wiki, Karpathy 2025 LLM wiki gist, the LLM wiki pattern
Andrej Karpathy's gist (published 2025) articulating a specific pattern for using LLMs with personal knowledge bases — not as query-time RAG over raw documents, but as **persistent, LLM-maintained, interlinked markdown** that compounds over time. The LLM owns the wiki layer entirely (creates pages, updates them on new sources, maintains cross-references, keeps an index and a log); the human owns sourcing and inquiry. Karpathy frames the pattern as 'Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase' and identifies three layers: raw sources (immutable), wiki (LLM-maintained markdown), and schema (the project's CLAUDE.md / AGENTS.md). The pattern is the contemporary articulation that explicitly extends the [[memex-lineage]] into the persistent-LLM era and is the proximate inspiration for how 0mn1.one's vault is operated. Local raw text: `_raw/sources/karpathy-llm-wiki.md`.
The LLM Wiki is a 2025 gist by Andrej Karpathy articulating a specific pattern for combining LLMs with personal knowledge bases. The gist is short (~2,500 words), copy-pasted as-is into LLM agents (Claude Code, Codex, OpenCode, etc.) as the high-level idea brief, with the agent and the human co-evolving the specifics. It is the proximate inspiration for how 0mn1.one’s vault is operated and one of the cleanest contemporary articulations of why persistent, LLM-maintained markdown is the right substrate for the human-and-instance partnership.
The core pattern
Karpathy distinguishes the LLM-wiki approach from typical RAG systems. In RAG (NotebookLM, ChatGPT file uploads, most retrieval-augmented chat), the LLM rediscovers knowledge from scratch on every question — retrieves relevant chunks at query time, generates an answer, retains nothing. There is no compounding artifact.
The LLM-wiki pattern inverts the topology:
Instead of just retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files that sits between you and the raw sources. When you add a new source, the LLM doesn’t just index it for later retrieval. It reads it, extracts the key information, and integrates it into the existing wiki — updating entity pages, revising topic summaries, noting where new data contradicts old claims, strengthening or challenging the evolving synthesis.
The wiki is the compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything that has been read.
Karpathy’s metaphor: “Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.” The human is not the typist; the human is the sourcing-and-questioning party. The LLM does the summarizing, cross-referencing, filing, and bookkeeping that makes a knowledge base actually useful over time.
The three layers
Karpathy identifies three layers, with sharply distinct ownership:
- Raw sources — the curated collection of immutable source documents (articles, papers, images, data). The LLM reads from this layer but never modifies it. This is the source of truth.
- The wiki — a directory of LLM-generated markdown. Summaries, entity pages, concept pages, comparisons, syntheses. The LLM owns this layer entirely.
- The schema — the project’s
CLAUDE.md,AGENTS.md, or equivalent. This document tells the LLM how the wiki is structured, what conventions to follow, and what workflows to use. Karpathy: “the key configuration file — it’s what makes the LLM a disciplined wiki maintainer rather than a generic chatbot.” Human and LLM co-evolve the schema over time.
The three operations
Karpathy names three core operations on the wiki:
- Ingest. A new source enters the raw collection. The LLM reads it, discusses key takeaways with the human, writes a summary page, updates the index, updates affected entity and concept pages, and appends a log entry. A single source might touch 10–15 wiki pages.
- Query. The human asks a question. The LLM searches the wiki for relevant pages, synthesizes an answer with citations, and — crucially — can file the answer back into the wiki as a new page if the synthesis is worth keeping. Explorations compound, just like ingested sources.
- Lint. Periodic health-checks: contradictions between pages, stale claims, orphan pages, missing cross-references, data gaps, new questions and sources to investigate. The LLM is unusually good at this kind of structural-criticism work.
The two special files
Two files do the navigational work:
index.md— content-oriented catalog. Every page listed with a link and one-line summary, organized by category. The LLM reads the index first when answering a query, then drills in. “This works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure.”log.md— chronological, append-only. Each entry prefixed with## [YYYY-MM-DD] op | titleso the file is greppable. “grep '^## \\[' log.md | tail -5gives you the last 5 entries.” The log is the timeline of the wiki’s evolution.
Why this matters for 0mn1.one
Every architectural choice [[0mn1one|the platform]]‘s vault has made is downstream of this pattern:
- The vault is the codebase.
~/0mn1.one/is treated like a software repo: typed conventions, lint scripts (find-orphans.py,link-orphans.py,connection-pass.py,generate-see-also.py), CI-style structural checks, an index (_vault-index.md) and a log (log.md). - The schema is
CLAUDE.mdandWiki-Schema.md. These files are the project’s declaration of how the LLM and the human collaborate on the wiki — exactly Karpathy’s third layer. - Ingest, query, lint. [[0mn1one|The platform]]‘s
## [YYYY-MM-DD] op | titlelog convention follows Karpathy’s exact prefix pattern. The wiki’s source-note layer (_knowledge/sources/), raw-source layer (_raw/sources/), and active wiki layer (src/content/wiki/) implement the three layers explicitly. - The LLM owns the wiki. Adam (the human founder) does sourcing, questioning, and editorial direction; the LLM does the wiki maintenance. This is not a stylistic preference — it is the structural commitment that makes the partnership work.
How it fits the lineage
Karpathy’s pattern is the layer the [[memex-lineage]] had been waiting for. Bush named the conceptual primitive in 1945 (the associative trail) but had no mechanism for population-scale maintenance. Wikipedia solved maintenance at population scale but only by recruiting volunteer labor and accepting NPOV-flattening. The LLM-wiki pattern solves maintenance at the personal scale Bush originally imagined — one person, one wiki, persistent, interlinked, coherent — by putting the partner side of the [[cognitive-symbiosis]] pattern (an LLM-instance with continuing context) in the maintenance loop.
The pattern is also one of the cleanest contemporary cases of cognitive-symbiosis at the human-and-instance interface: the human alone could not maintain a wiki at this scale; the LLM alone has nothing to read, nothing to be curious about, no questions to investigate. The pair compounds.
Reading and citation
The gist is short and freely available. Local raw text at _raw/sources/karpathy-llm-wiki.md. Citation format on this wiki: Karpathy, A. “The LLM Wiki.” Gist, 2025.
Lenses still to grow
- Empirical results — practitioner reports of LLM-wiki use across personal, research, business contexts; what works at what scale.
- Failure modes — LLM hallucination filing wrong claims into the wiki, schema drift, abandoned wikis. The maintenance problem doesn’t disappear; it changes shape.
- Multi-instance maintenance — what happens when more than one LLM contributes to the same wiki; conflict resolution, voice consistency, the editorial layer.
See also
Auto-generated from this entry’s typed relations: frontmatter, grouped by relation type so the editorial signal isn’t flattened.
- Extends: [[memex-lineage]]
- Enables: [[cognitive-symbiosis]] · [[0mn1one]]
- Parallels: [[vault-source-roadmap]]
- Member of: [[book]]
What links here, and how
Inbound connections from across the wiki, grouped by lens and by relationship. These appear automatically — every entity page declares what it links to, and that data populates here on the targets.
Nothing yet. This entry is currently one node away from the rest of the graph — links will appear here automatically as the wiki grows. Each new entity that mentions this one in its relations frontmatter shows up here.
0 inbound links · 5 outbound