Andrej Karpathy recently described a shift in how he uses LLMs: instead of primarily generating code, a large fraction of his token budget now goes into compiling knowledge. Raw articles, papers, datasets, and images go into a raw/ directory. An LLM reads them and produces a structured wiki — interconnected markdown files, concept summaries, backlinks, category pages. The LLM doesn’t just answer questions about your data; it organizes and maintains the entire knowledge structure.
The GitHub Gist describing the approach hit 5,000 stars in days. The X post that announced it got 16 million views. Community members reported going from zero to a working wiki in under 15 minutes. A wave of implementations followed within the week.
Here’s what the pattern actually is, why it works at personal scale, and the one gap that every tutorial glosses over.
The Three-Layer Architecture
The system is simple once you see its layers:
- raw/ — Immutable source documents. Articles clipped via Obsidian Web Clipper, PDFs, papers, datasets, images. These never change after ingest. They’re the authoritative source.
- wiki/ — LLM-generated pages. The model reads
raw/and produces structured markdown: concept summaries, cross-references, category pages, backlinks. You rarely write to these directly — the LLM maintains them. - Schema (CLAUDE.md or equivalent) — The rules file. This is the most important file in the entire system. It tells the LLM how pages should be structured, what cross-references to maintain, and how to handle new ingests. Without a well-written schema, the output becomes inconsistent as the wiki grows.
Karpathy’s mental model captures it cleanly: Obsidian is the IDE, the LLM is the programmer, the wiki is the codebase. The LLM writes and maintains all of the data in the wiki. You rarely touch it directly.
Why This Works — and When It Doesn’t
The natural comparison is RAG — retrieval-augmented generation, where you embed documents into a vector store and retrieve relevant chunks at query time. The LLM wiki takes a fundamentally different approach: pre-compile the synthesis once at ingest, store it as stable markdown, and let the model read it directly at query time.
At personal scale — roughly under 500 pages — pre-compilation wins on almost every dimension. Query responses are more coherent because the synthesis already happened; you’re not re-deriving meaning from raw source chunks on every question. The LLM maintains index files and brief summaries of all documents, so it knows what to read for any given query without scanning the full corpus. There’s no vector database to manage, no embedding model to run, no approximate nearest-neighbor index to tune.
The community figure circulating is that this approach runs 70x more efficiently than traditional RAG at this scale — a plausible number given the absence of embedding overhead and the coherence gains from pre-compilation.
RAG wins when your corpus is enormous (tens of thousands of documents) or changes faster than you can compile it. For personal knowledge management, you’re not there.
Getting It Running
The setup takes four steps:
- Create a vault in Obsidian with
raw/andwiki/directories. - Write a
CLAUDE.mdschema that defines your page structure — what sections each wiki article should have, how to format backlinks, what tags to apply consistently. - Clip a few articles using the Obsidian Web Clipper extension. This saves the full article content locally as markdown — not just a URL pointer. The content is in your vault.
- Point Claude Code at the vault and ask it to compile
raw/into the wiki.
After that, the core loop is: ingest new sources into raw/, ask the LLM to update the wiki, run occasional lint passes to find inconsistencies and orphan pages, and query the wiki for complex questions that benefit from synthesized answers rather than keyword search.
On a mature wiki at ~100 articles and ~400K words — Karpathy’s own scale — you can skip a dedicated search index entirely. The LLM reads its own index files and navigates to the relevant content without needing RAG tooling. This surprises most people who assume they’ll need a proper search layer; the structure the LLM maintains is good enough at this size.
The one thing you shouldn’t skip is the schema file. Users who dive straight into compiling without defining structure end up with a wiki that’s inconsistent in ways that compound over time — some pages have backlinks, some don’t; some have source sections, some don’t. The schema is cheap to write upfront and expensive to retrofit later.
The Gap No Tutorial Mentions
Here’s what actually happens once you move past the initial setup: you ask the LLM to research a topic it doesn’t yet have in raw/, and it does a solid job — adds wiki articles, synthesizes information from web searches. But it doesn’t clip the web sources. It synthesizes from them and cites them in the conversation, but those citations don’t land in the vault.
The result is a two-tier provenance problem the community surfaced quickly after adoption:
- Clipped articles — solid provenance. The full content is in
raw/. If the URL goes dead tomorrow, the data survives in your vault. - Web-researched articles — citations exist in the conversation only, not persisted to the vault. If those URLs die, the synthesis in your wiki loses its source with no fallback.
This isn’t a flaw in the system design — raw/ is meant to be your archive. The gap is behavioral: the ingest discipline applies to manually clipped content, not to content the LLM researches on your behalf during Q&A. If you don’t build a habit around clipping sources before the LLM synthesizes them, your wiki accumulates orphaned knowledge.
The Archiving Trade-Off
There’s no clean answer here, but the trade-off space has three positions:
Full archive: When the LLM researches a topic, require it to fetch and save the source content to raw/ before writing the wiki article. Maximum fidelity — if the URL dies, the content survives. The cost: storage scales linearly with corpus size, and context window pressure grows as the vault grows. This is the most defensible approach and the one the system’s design implies.
Compile-time summaries: Fetch the source, summarize it into raw/, then discard the original. You pay tokens once at ingest. Storage stays bounded. Fidelity is reduced — you’ve lost the original text — but the summary lives forever, and query-time costs stay flat. This is arguably the most practical approach for a personal wiki meant to grow over years. The compile step is expensive once; the dividends pay out on every subsequent query.
URL-only references: Cheapest upfront. Zero storage cost, zero token cost, total fidelity risk. Acceptable for sources that are permanently archived elsewhere (major papers on arXiv, for example) — not acceptable for anything that could disappear.
Most serious personal knowledge systems accept some fidelity loss and treat the compiled wiki as the durable artifact, not the raw sources. The question isn’t which approach is right in the abstract; it’s which fidelity you’re willing to trade for which cost, given your specific corpus and query patterns.
A baseline improvement regardless of which approach you choose: add a sources: section to every wiki article. Even URL-only references are better than no references. It’s the difference between a wiki that’s honest about what it knows and where it came from, and one that presents synthesis as if it were first principles.
Where This Pattern Is Heading
The natural evolution Karpathy flags: as the wiki grows, you want the LLM to know the data in its weights rather than just its context window — synthetic data generation and fine-tuning. That’s expensive and complex, but it’s the logical endpoint of the pattern. Your personal knowledge base becomes training data for a model that embodies it.
Short of that, the more tractable near-term improvement is better tooling around the compile step. The current workflow is a collection of scripts and manual conventions held together by a schema file. Purpose-built tooling is arriving: Obsidian plugins that formalize ingest and lint operations, local search engines that act as MCP servers, cross-platform desktop applications that automate the compile loop.
The pattern is now mature enough that the question isn’t whether it works — community data is clear that it does. The question is how much of the scaffolding you want to build yourself versus adopt from an emerging ecosystem of tools. If you’re already using AI tools in your workflow, the LLM wiki is a natural extension: the same models you use for code and writing can maintain your knowledge infrastructure when you give them the right structure to work within.
The insight that’s easy to miss in all the implementation discussion: this isn’t primarily a retrieval problem or a storage problem. It’s a knowledge compilation problem. The value isn’t that you can query your notes more efficiently — it’s that the act of compiling forces synthesis, and synthesis is where understanding comes from. The LLM doing the compiling is incidental. The compiling itself is the point.
At EchoForgeX, we build AI-powered tools and help businesses integrate AI into their workflows. Get in touch to learn how we can help your team work smarter with AI.