TL;DR: Karpathy’s LLM Wiki pattern transforms knowledge retrieval from a “re-discover every time” model to a compounding, persistent system where the LLM maintains a structured markdown knowledge base that grows richer with each source added. Several open-source implementations have already emerged, though substantive criticisms around lossy compression and update propagation remain unresolved.
The Core Problem with Traditional RAG
Most people’s experience with LLMs and documents follows a familiar pattern: upload files, ask questions, get answers. This is RAG (Retrieval-Augmented Generation)—the dominant paradigm for building AI knowledge systems.
The limitation? Every question re-discovers knowledge from scratch. Ask a subtle question requiring synthesis across five documents, and the LLM must find and piece together relevant fragments each time. Nothing accumulates. There’s no build-up, no persistent understanding, no compounding value.
Persistent Wiki] W --> A2[Answer] S -->|compounding| W style S fill:#c8e6c9 style W fill:#c8e6c9 end note1[RAG: Knowledge
re-derived each query] note2[Wiki: Knowledge
built & kept current]
This is the gap Karpathy’s LLM Wiki aims to fill.
The LLM Wiki Architecture
The pattern introduces a persistent, compounding artifact between raw sources and user queries. Instead of retrieving from documents at query time, the LLM incrementally builds and maintains a structured, interlinked collection of markdown files—a personal wiki.
Three-Layer Design
(Immutable)"] --> LLM LLM --> WIKI["📝 Wiki Layer
(Markdown)"] SCHEMA["⚙️ Schema
(CLAUDE.md)"] --> LLM end S --> RAW Q -->|synthesizes| R WIKI --> R style User fill:#e1f5fe style System fill:#e8f5e9
Raw Sources — Your curated collection of documents. Immutable. The LLM reads them but never modifies them. This is your source of truth.
Wiki Layer — LLM-generated markdown files: summaries, entity pages, concept pages, comparisons, synthesis. The LLM owns this layer entirely—creating, updating, cross-referencing, maintaining consistency.
Schema — A configuration file (CLAUDE.md or AGENTS.md) that tells the LLM how the wiki is structured, what conventions to follow, and which workflows to use. This is the critical component that makes the LLM a “disciplined wiki maintainer” rather than a generic chatbot.
Seven Operational Modes
Ingest — Drop a new source, the LLM reads it, writes summary pages, updates the index, modifies relevant entity and concept pages (typically touching 10-15 files), flags contradictions, and logs the entry.
Query — Ask questions against the wiki. The LLM searches relevant pages, reads them, synthesizes answers with citations. Good answers can be filed back into the wiki as new pages—knowledge compounds.
Lint — Periodically check for contradictions between pages, stale claims superseded by new sources, orphan pages with no inbound links, missing cross-references, and data gaps.
Update, Schema-evolve, Teach — Handle multi-page stale claim propagation, refine the schema over time, and explain the wiki structure to users.
The Index and Log
Two special files help navigation as the wiki grows:
-
index.md — Content-oriented catalog of every page with links and one-line summaries. The LLM reads this first to find relevant pages. Works well at moderate scale (~100 sources, hundreds of pages) without embedding-based RAG.
-
log.md — Append-only chronological record of ingests, queries, and lint passes. Parseable with simple unix tools like
grep "^## \[" log.md | tail -5.
Why This Works
The tedious part of maintaining a knowledge base isn’t reading or thinking—it’s bookkeeping. Updating cross-references, keeping summaries current, noting contradictions, maintaining consistency across dozens of pages. Humans abandon wikis because maintenance burden grows faster than value.
LLMs don’t get bored. They don’t forget to update a cross-reference. They can touch 15 files in one pass. The maintenance cost approaches zero.
from accumulated wiki
The human’s job: curate sources, direct analysis, ask good questions, think about what it means. The LLM’s job: everything else.
Implementations Already Emerging
The pattern has already spawned several open-source implementations:
| Project | Description |
|---|---|
| Synthadoc | Open-source engine with 3-layer architecture, multi-model support (6 providers), domain specificity via purpose.md, comprehensive auditing |
| SwarmVault | Graph merging, video ingest with transcription, SQL parser, Svelte SFC support |
| PulseOS Lite | Enterprise-focused: canonical markdown memory, graph UI, SQL/vector layer, company machine-readable |
| llm-wiki-manager | Full skill package covering all 7 modes, auto-dated reports |
| best-practices | Six-axiom schema kernel: read first, write second, verify third |
The schema layer is “underrated” according to commenters—one file makes the difference between an LLM that maintains a wiki versus one that just answers questions in a wiki-shaped directory.
Substantive Criticisms
The comments on Karpathy’s gist reveal several legitimate concerns:
Lossy Compression
“The core problem is that an LLM Wiki is lossy compression. You take raw documents and rewrite them into derived wiki pages. That may be useful for a small curated corpus, but it can also drop caveats, dates, minority views, exact wording, edge cases, and source context.”
Once people query the wiki instead of original sources, summary errors become part of the knowledge base—hallucinations compound.
Update Propagation Not Solved
“Adding one new source can affect many entity pages, concept pages, timelines, summaries, and indexes. At scale, this becomes graph maintenance: detecting what changed, resolving conflicts, avoiding duplicates, preserving provenance, preventing stale claims, and not silently breaking old pages.”
The “ask the LLM to maintain it” approach works at small scale but faces real challenges as the wiki grows.
No Empirical Evidence
“There is no benchmark, no task definition, no scale curve, and no comparison against serious baselines. We do not know whether this is better than hybrid RAG, BM25 plus reranking, vector search, GraphRAG, hierarchical summaries, long-context prompting, NotebookLM, Perplexity Spaces, or ChatGPT Projects.”
Calling it a “new architecture” without evidence is premature.
The “Wiki” Naming Debate
Some criticized calling it a “wiki” at all—human-curated wikis have fundamentally different properties. Others pushed back: “A wiki is, at the most basic level, a linked body of navigable information. If an LLM is used to generate or organize that information, you can call it a bad wiki, an unreliable wiki, or an immature wiki. What you can’t do is pretend the mere presence of AI magically disqualifies it from the category.”
When LLM Wiki Makes Sense
The pattern works well for:
- Personal knowledge tracking — goals, health, psychology, self-improvement, journal entries
- Research — going deep on a topic over weeks/months, building comprehensive wiki with evolving thesis
- Reading companion — filing chapters as you go, building character/theme/plot pages
- Business/team — internal wikis maintained by LLMs, fed by Slack, meetings, documents
It struggles with:
- Large curated corpora where lossy compression matters
- Scenarios requiring exact source citations and provenance
- Domains where edge cases and minority views are critical
The Vannevar Bush Connection
The idea relates to Vannevar Bush’s Memex (1945)—a personal, curated knowledge store with associative trails between documents. Bush’s vision was closer to this than to what the web became: private, actively curated, with connections between documents as valuable as the documents themselves.
The part Bush couldn’t solve: who does the maintenance? The LLM handles that.
References
- LLM Wiki — Andrej Karpathy, GitHub Gist (April 4, 2026) — https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- Synthadoc — axoviq-ai, GitHub — https://github.com/axoviq-ai/synthadoc
- SwarmVault — https://github.com/waydelyle/swarmvault
- PulseOS Lite — jp-carrilloe, GitHub — https://github.com/jp-carrilloe/pulseOS-lite
- llm-wiki-manager — sametbrr, GitHub — https://github.com/sametbrr/llm-wiki-manager
- best-practices — AgriciDaniel, GitHub — https://github.com/AgriciDaniel/best-practices
This article was written by OpenCode (minimax-m2.5-free | OpenCode), based on Karpathy’s LLM Wiki gist and community implementations.
