Build a Karpathy-style LLM wiki in Obsidian: an advanced guide

In April 2026, Andrej Karpathy described a pattern he calls the LLM wiki, and it quietly inverts everything about how most people keep notes. The usual second brain is a pile you maintain and occasionally ask an AI about. Karpathy's version reverses the arrows: the model builds and maintains the knowledge base, and you almost never write in it by hand. His own words are blunt - you rarely ever write or edit the wiki manually, it's the domain of the LLM. The framing that stuck with the community: Obsidian is the IDE, the LLM is the programmer, and the wiki is the codebase.

We run a version of this at Welzin for our own research, so this is not a theory post. It is how the thing actually works, why it beats retrieval-augmented generation at personal scale, and the advanced moves that separate a toy from a system you trust. If you want the shortest possible summary: you own the sources, the model owns the wiki, and a schema file is the contract between them.

The reversal, and why it matters#

Tiago Forte's Building a Second Brain made the case for capturing everything you learn. The problem was always the maintenance tax: a knowledge base decays the moment you stop grooming it, and nobody grooms it. Karpathy's move is to hand the grooming to the model. You spend your token budget not on generating code but on knowledge manipulation - reading, summarizing, cross-linking, reconciling. The payoff is compounding. At the time he posted, one research topic in his wiki had grown to roughly 100 articles and 400,000 words, longer than most PhD dissertations, and he had not typed a word of it. The knowledge accreted as a side effect of him going about his day.

That is the whole promise: a knowledge base that gets denser and more useful every time you feed it, without you paying the grooming tax. The rest of this post is how to build one that actually holds up.

The three-layer architecture#

The design is deliberately small. Three directories, three roles, one hard rule about who writes where.

• Raw sources (you own, read-only to the model). Your curated corpus: PDFs, clipped articles, transcripts, notes. The model reads these and never edits them. This immutability is not fussiness, it is auditability. If the model can rewrite a source, you lose the ability to trace any conclusion back to what it was actually based on. Sources are the ground truth, and ground truth does not get edited by the thing reasoning over it.
• The wiki (the model owns entirely). A directory of generated markdown: source summaries, entity pages, concept pages, topic hubs, comparisons, and an index. The model creates these, maintains the cross-links, and enforces consistency. You read it. You rarely touch it.
• The schema (the contract). A single document - think CLAUDE.md or SCHEMA.md - that tells the model how the wiki is structured, the naming conventions, the page shapes, and how each workflow runs. This file is the difference between a coherent wiki and a pile of inconsistent markdown. The last section is entirely about it.

The one rule to internalize: sources are append-only and model-read-only; the wiki is model-write; the schema is human-write. Get that boundary right and everything else is detail.

The three operations: ingest, query, lint#

The system runs on three verbs, and understanding them is understanding the whole thing.

• Ingest. You drop a source in. The model reads it, writes a summary page, updates the index, and - this is the important part - ripples the new information outward. It revises the entity pages the source touches, updates topic summaries, notes where the new material contradicts an old claim, and logs the event. One document does not just get filed, it updates everything it connects to.
• Query. You ask a question against the wiki, not against the raw sources. The model navigates the index and the interlinked pages, reads the relevant ones, and synthesizes an answer. The move that makes it compound: a good exploration can be saved back as a new page. Asking a sharp question makes the next answer easier to produce, because the synthesis is now on disk. The base gets smarter by being used.
• Lint. A periodic health check, and the operation most people skip and most regret skipping. The model hunts for contradictions, stale claims, orphan pages, broken cross-references, and concepts that are referenced but never defined. This is what keeps a large wiki from rotting into confident nonsense.

Why this beats RAG at personal scale#

This is the part worth being precise about, because "just use RAG" is the reflexive answer and it is wrong at this scale. Retrieval-augmented generation does its sorting work on every single question, over raw data that was never cleaned, and then hopes the top-k chunks happen to contain the answer. The LLM wiki does that work once, at ingest time, and produces a clean, condensed, cross-linked artifact that fits inside the context window of a modern long-context model. Pre-processing beats re-processing when the corpus is small enough to pre-process.

The failure mode that kills naive RAG is well documented: ask your vault how a note on burnout contradicts your Q1 goals, and pure vector similarity hands you notes that share the word "tired." Mathematically correct, intellectually useless, because contradiction is a relationship, not a keyword overlap. The wiki captures that relationship at ingest, when the model actually reasons about how the new source sits against the old ones.

Be honest about the boundary, though. At enterprise scale - millions of documents, granular access control, real-time freshness - RAG keeps all its advantages, and the wiki's compile-everything approach stops being feasible. The LLM wiki is not a religion, it is the right tool for the personal-to-team scale of hundreds or low thousands of sources. Above that, you are back to retrieval, or a hybrid. This is the same buy-versus-build judgement we apply everywhere: match the architecture to the scale, do not cargo-cult the fashionable one. If you want the retrieval side done well, our RAG is an architecture post is the companion to this one.

Building it in Obsidian#

Obsidian is the natural home because the wiki is just interlinked markdown, which is exactly what Obsidian renders, graphs, and backlinks natively. You get the graph view, the backlink panel, and full-text search for free, over a directory the model maintains. The minimal build is three moving parts:

• The vault - your Obsidian folder, holding sources/, the wiki pages, and SCHEMA.md at the root.
• The driver - the thing that runs the operations. Karpathy's own setup was, in his words, a hacky collection of scripts bridging the model and the files. In practice today, a coding agent such as Claude Code pointed at the vault, with the schema as its instructions file, is the cleanest driver: it can read sources, write wiki pages, and follow the conventions in one loop.
• The model - a long-context model for the synthesis. Cloud models are simplest; local runtimes (Ollama, LM Studio, vLLM) keep everything private, which matters if your sources are sensitive.

If you would rather not wire the driver yourself, the community has shipped plugins that cover parts of this: Local LLM Hub for fully local chat, RAG, and workflow automation over the vault, and ObsidianRAG for a plugin-plus-Python-backend pipeline. They lean RAG rather than pure wiki, but they are a fast way to feel the ergonomics before you commit to the full pattern.

Making it advanced#

The basic loop works on day one and rots by month three if you stop here. These are the moves that make it hold up, and they are where most of the real engineering is.

• Provenance and pedigree scoring. The single biggest weakness of an auto-maintained wiki is that it flattens a peer-reviewed paper and a random blog post into the same confident prose. Fix it at ingest: tag every source page with a pedigree field (peer-reviewed, preprint, vendor, blog, unknown) and a confidence note, and instruct the model to weight claims by pedigree and to surface the tag when it answers. A claim is only as trustworthy as its worst-cited source.
• Graph-aware retrieval, not just similarity. When the model answers a query, have it traverse the [[wikilinks]] outward from the seed pages, not just pull semantically near text. This is the insight behind graph-RAG approaches like Neural Composer's use of LightRAG: answers should come from relationships, which the wikilinks already encode, rather than from keyword proximity. The wiki structure is your knowledge graph. Use it.
• Contradiction as a first-class page, not a silent overwrite. When a new source disagrees with an existing claim, the model must not quietly rewrite one to match the other. It should keep both, flag the conflict, and note which source and date each came from. A wiki that hides its disagreements is a wiki that launders bad information into consensus.
• Incremental, not full, re-indexing. Only re-touch the pages a new source actually affects. Full re-synthesis on every ingest is slow and burns tokens; incremental updates keep the loop cheap enough to run constantly, which is the whole point.
• Route models by task. Ingest summarization is cheap and high-volume, so a smaller or local model handles it well. A hard cross-topic query that has to reconcile a dozen pages deserves a frontier model. This is the same routing discipline we wrote about for choosing when a top-tier model is worth its price - do not pay frontier rates to summarize a blog post.
• Reranking for precision. If you do keep a retrieval step for large wikis, a CrossEncoder reranker (for example bge-reranker-v2-m3) before synthesis meaningfully lifts answer quality over raw vector top-k.

The schema file is the whole system#

Everything the model does well or badly traces back to the schema. This is the file you write and maintain by hand, and it earns more of your attention than any other part. A production-grade schema specifies, at minimum:

- Page types and their exact shapes
  (source page, entity, concept, topic hub, index)
- Naming and linking conventions
  (kebab-case slugs, when to create a [[link]] vs inline)
- The ingest contract
  (write a summary, update the index, ripple to
   related pages, log the event, never edit a source)
- The pedigree rule
  (every source scored; weight claims by pedigree)
- The contradiction rule
  (keep both, flag, never silently overwrite)
- The lint checklist
  (orphans, broken links, stale claims, undefined concepts)
- Definition of done for each operation

Treat the schema like an API contract, because that is what it is. When the wiki drifts, you do not scold the model, you tighten the schema. A vague schema produces a vague wiki, reliably.

Pitfalls, and takeaways#

The three failure modes we have actually hit: letting the model edit sources (kills auditability), skipping lint (the wiki rots quietly), and a loose schema (inconsistent pages that get worse as they grow). All three are cheap to prevent and expensive to reverse.

• Karpathy's LLM wiki reverses the second brain: the model writes and maintains the knowledge base, you only curate sources. It compounds because the grooming tax is gone.
• Three layers: sources you own and the model reads read-only, a wiki the model owns and writes, a schema you write that governs both. Sources append-only, wiki model-write, schema human-write.
• Three operations: ingest (read a source, summarize, ripple outward), query (synthesize from the wiki, save good answers back), lint (hunt contradictions, orphans, and rot).
• It beats RAG at personal scale by pre-processing once instead of retrieving every time, and by capturing relationships like contradiction that vector similarity misses. Above roughly a few thousand sources, RAG or a hybrid wins again.
• Build it in Obsidian with a coding agent as the driver and a long-context model for synthesis. Go local (Ollama, LM Studio, vLLM) if sources are sensitive.
• Advanced is where it lives or dies: pedigree scoring, graph-aware retrieval over your wikilinks, contradictions kept and flagged, incremental re-indexing, and model routing by task. The schema file is the contract that makes all of it hold.

References#

1. Karpathy's instructions for building an AI-driven second brain (Techstrong.ai)
2. Karpathy's LLM wiki: a self-updating second brain with Obsidian (MindStudio)
3. What is Karpathy's LLM wiki? Building a knowledge base with Claude Code (MindStudio)
4. second-brain: an LLM-maintained knowledge base for Obsidian (GitHub)
5. obsidian-local-llm-hub: all-in-one local AI hub for Obsidian (GitHub)
6. ObsidianRAG: privacy-first RAG over your vault (GitHub)
7. The missing piece every Obsidian user needs: local RAG in 2026 (DEV)

Hero image via Unsplash.

We build knowledge systems that compound instead of rot, for our own research and for clients. Explore our other insights or get in touch if you want to talk through your own second brain.