Part IV: From LLM Wiki to the AI Scientist

Chapter 10: Rise of the LLM Wiki — Karpathy's Obsidian + Claude Code Workflow

Written: 2026-04-28 Last updated: 2026-06-11

10.1 A Gist with 16 Million Views

On April 4, 2026, Andrej Karpathy published a gist [4]. Title: "LLM Wiki." It was not a product launch; it was a pattern. Keep raw sources immutable, let an LLM compile them into a markdown wiki, then use that wiki as the basis for querying, cleanup, and further synthesis. The post introducing it reached 16M+ views [4], and by early May 2026 the gist had passed 19k+ stars and 4k+ forks [4].

Why such explosive reach? The pattern was simple and powerful. RAG and file-upload workflows retrieve chunks from raw documents at query time. LLM Wiki flips the order: the model first compiles what it reads into entity pages, concept pages, and comparison pages. Later questions start from accumulated structure rather than a fresh pile of documents. The key shift: a one-shot chat tool becomes a compounding personal knowledge engine [13].

10.2 The Three Layers

Karpathy's LLM Wiki uses three layers [4]:

L1: Raw Sources — immutable originals


vault/
└── raw/
    ├── papers/          # PDFs, arXiv, papers
    ├── articles/        # blogs, news
    ├── notes/           # meeting notes, ideas
    └── bookmarks/       # bookmarks, clippings

The LLM reads this layer only. Never writes to it. Immutability is guaranteed.

L2: Wiki — LLM-owned markdown


vault/
└── wiki/
    ├── entities/        # people, projects, companies
    ├── concepts/        # technical concepts, terms
    ├── summaries/       # paper and article summaries
    └── comparisons/     # comparison and contrast pages

The LLM reads L1 and writes/updates this layer. Entity pages, concept pages, comparison pages, and cross-references.

L3: Schema — CLAUDE.md or AGENTS.md

The file explaining the vault structure to the LLM. "Entity pages live in wiki/entities/", "Concept pages live in wiki/concepts/", etc.

The S8 survey adds a useful operational framing: treat the wiki as an idea file, not just a summary cache [16]. In that framing, each generated page should preserve at least five fields: source, claim, evidence, relation, and unresolved question. A page that only summarizes is easy to generate and hard to trust. A page that records claims and unresolved questions can become input to later research loops.

Three basic operations:

  • ingest: add a raw source, create/update wiki pages
  • query: navigate the wiki to answer questions
  • lint: clean up broken links, duplicates, inconsistencies

Recent implementation guides add one practical rule: L2 is LLM-owned, but changes must be git-visible [8]. As the wiki grows, hallucinated claims, duplicate pages, and bad merges become real risks. The minimal operating loop is therefore not just raw/, wiki/, and CLAUDE.md; it is also git diff, lint, and review.

S8's working convention extends the three layers with small control files:


index.md    # map of sources, generated pages, and status
log.md      # ingest/query/lint operations and diffs
schema.md   # page fields, link rules, and source requirements

Those files are intentionally boring. They make an LLM Wiki portable across Claude Code, Codex, and local models because the agent no longer has to infer the operating procedure from conversation history.

Figure 10.1: Karpathy's LLM Wiki, three layers — L1 raw sources (immutable originals), L2 wiki (LLM-owned markdown), L3 schema (CLAUDE.md or AGENTS.md). illustration by author Gemini assisted
Figure 10.2: Three basic operations of an LLM Wiki — ingest, query, lint. Each works in a different direction between the raw and wiki layers. illustration by author Gemini assisted

10.3 How a Pattern Adopts a Community

After Karpathy's gist, the community response was rapid. Since mid-April 2026, write-ups have interpreted the pattern in three main ways:

  • [8]: a step-by-step setup around raw/, wiki/, and CLAUDE.md
  • [13]: llm-wiki as a reference implementation, with markdown, git, and cross-links reducing vendor lock-in
  • [14]: a RAG vendor's view of LLM Wiki as a compiled knowledge artifact with different cost and quality tradeoffs
  • [15]: a 30-minute first wiki from five research papers
  • [7] and [6]: Obsidian second brain + Claude Code as a personal productivity workflow

Nate Herk's video "Karpathy 10x'ed Claude Code" [10] explains the spread best: "LLM Wiki is a 10x tool — it converts a one-shot chat tool into a compounding personal knowledge engine." (YouTube ID: 20d5cSkSvcU, uploaded 2026-04-05 by Nate Herk; fact-checker confirmed this is the correct original upload, not the re-upload)

10.4 The Counter-Argument: You Need a Knowledge Graph

As the community adopted LLM Wiki, limitations emerged. infranodusllmwiki2026's critique:

"Karpathy's LLM Wiki is flat-file. It can't express relationships between entities. 'A cited B', 'C is a follow-on to D' — relational knowledge is hard to express in markdown files. A knowledge graph layer is needed."

This is a valid critique. But it should be understood in context: Karpathy's pattern is not "the perfect knowledge management system" — it's a good starting point that works well with LLMs. Recent implementation write-ups converge on the same position: markdown + wikilinks + git is the lowest-friction default for personal and small-team scale. But if citation graphs, experiment lineage, or enterprise permission boundaries are central, a graph database or hybrid search layer should be added [11].

S8 sharpens the critique in two directions. First, an LLM Wiki can become "RAG with extra steps" if the wiki pages are only generated summaries without provenance or disagreement tracking. Second, bigger context windows do not remove the need for structure; they just delay the moment when missing provenance becomes painful. The useful middle ground is a Zettelkasten-like rule: links are not decoration, they are thinking. Each link should say why two notes belong together.

10.5 "Farzapedia" — The Personalization Argument

Karpathy introduced the concept [4]: your own Wikipedia. Your interests, papers you've read, projects you've worked on — all defined from your perspective. Instead of everyone sharing the same Wikipedia, each person has a knowledge base optimized for their own context.

This is the theme of Chapter 11: connecting this pattern to your own activity.

10.6 Claude Code vs Codex for LLM Wiki

Karpathy's original implementation used Claude Code + Obsidian. Codex works the same way:

Claude Code approach: Describe the vault structure in CLAUDE.md; use claude conversationally to update the wiki. More interactive, better for rapid exploration.

Codex approach: Describe the vault structure in AGENTS.md; run tasks via codex exec "ingest this paper". More autonomous, better for batch processing.

Both use the same three-layer structure. The choice is a matter of working style. The larger lesson from the April 2026 guides is that LLM Wiki is less a product than a file convention an agent can read and edit [4]. Claude Code, Codex, OpenCode/Pi, and local models can all operate the same pattern: raw is immutable, wiki is editable, schema defines commands, and diffs are reviewed.

That portability has a boundary. The file convention can move between tools; the agent loop cannot be assumed identical. Claude Code may be better for exploratory conversation over the vault. Codex is better when the operation can be expressed as a bounded task: ingest these five papers, audit pages without sources, update the index, leave a diff. A mature LLM Wiki therefore separates vault convention from agent execution surface.

Figure 10.3: Same vault, two operating styles — Claude Code's conversational approach vs Codex's batch-task approach. Both run on the same three-layer structure. illustration by author Gemini assisted

References

  1. Karpathy, Andrej, "LLM Wiki," gist, 2026. [Karpathy, 2026]
  2. Karpathy, Andrej, "LLM Wiki tweet," Twitter, 2026. [Karpathy, 2026]
  3. Karpathy, Andrej, "LLM Wiki talk / post," 2026. [Karpathy, 2026]
  4. Karpathy, Andrej, "Farzapedia — personalization argument," 2026. [Karpathy, 2026]
  5. Joshi, "How I built my personal LLM Wiki," Medium, 2026. [Joshi, 2026]
  6. Paige, "Second brain setup," 2026. [Paige, 2026]
  7. Aimaker, "AI-powered second brain from LLM Wiki," 2026. [Maker, 2026]
  8. Starmorph, "LLM Wiki step-by-step guide," 2026. [Starmorph, 2026]
  9. Mindstudio, "Karpathy Wiki implementation," 2026. [MindStudio, 2026]
  10. Herk, Nate, "Karpathy 10x'ed Claude Code," YouTube (ID: 20d5cSkSvcU), 2026-04-05. [Herk, 2026]
  11. Infranodus, "LLM Wiki needs a knowledge graph," 2026. [infranodusllmwiki2026]
  12. LLM Wiki Full Setup, "Canonical demo," 2026. [llmwikifullsetup2026]
  13. Cognition, "llm-wiki: the reference implementation of Karpathy's self-building AI memory pattern," 2026-04-16. [Cognition, 2026]
  14. Denser.ai, "From RAG to LLM Wiki: What Karpathy's Idea Means for AI Knowledge Bases," 2026-04-16. [Denser, 2026]
  15. Data Science Dojo, "The LLM Wiki Pattern by Andrej Karpathy," 2026-04-16. [Data Science Dojo, 2026]
  16. terryum survey S8, "LLM Wiki to AI Scientist," 2026. [Um, 2026]