Skip to content

LLM Wiki

Summary

An LLM Wiki is a folder of interlinked Markdown pages that an LLM agent writes and maintains from a curated set of raw sources, guided by a schema file such as CLAUDE.md or AGENTS.md. Knowledge is compiled once at ingest time and kept current by lint passes, instead of being re-derived from raw chunks on every query as in RAG. Andrej Karpathy described the pattern in an idea-file gist on 2026-04-04. This vault is itself run this way.

The LLM Wiki is an architectural pattern for Personal Knowledge Management (PKM) and team knowledge bases, popularized by Andrej Karpathy in April 2026. It represents a paradigm shift from stateless, retrieval-centric workflows (like standard RAG) to stateful, agent-maintained, continuously compounding knowledge bases.

In this model, a Large Language Model (LLM) acts less like a search engine and more like a dedicated librarian or archivist. Instead of merely fetching chunks of raw text when queried, the LLM proactively digests incoming information and "compiles" it into a highly structured, interlinked network of markdown files—a wiki.

Key Facts

Fact Value
Type Architectural pattern ("idea file"), not a product; no versioned releases
Latest Version Gist llm-wiki.md as published 2026-04-04 (no versioned revisions tracked; checked 2026-09-25)
Author Andrej Karpathy
Origin X post "LLM Knowledge Bases" (2026-04-02), then the gist (2026-04-04)
License None stated: the gist has no license clause (checked 2026-09-27)
Layers Raw sources (read-only), wiki (LLM-owned), schema (CLAUDE.md / AGENTS.md)
Operations Ingest, Query, Lint
Recommended search layer qmd 2.8.3 (2026-08-16), MIT, Node.js >= 22
Index-only scale "~100 sources, ~hundreds of pages" per the gist
Adoption Gist ~48.6k stars, ~10k forks (2026-09-25)

The compact diagram shows the three layers and the agent loop. The full component diagram is in Explanation.

flowchart LR
    RAW["raw/ sources<br/>(read-only)"] -->|"ingest"| AGENT["Agent<br/>Claude Code, Codex, OpenCode"]
    SCHEMA["CLAUDE.md / AGENTS.md"] -->|"rules"| AGENT
    AGENT -->|"write, cross-link, lint"| WIKI["Wiki pages<br/>index.md + log.md"]
    WIKI -->|"query"| AGENT
    AGENT <-->|"CLI or MCP"| QMD["qmd search"]
    HUMAN["Human in Obsidian"] -->|"curate + ask"| AGENT
    HUMAN -->|"read + review"| WIKI

Why It Is Better Than RAG

Traditional Retrieval-Augmented Generation (RAG) suffers from a "stateless" problem. When you ask a question, the LLM pulls chunks of text from raw documents, synthesizes an answer, and then immediately forgets that synthesis. The next time you ask a similar question, it must re-read and re-synthesize from scratch.

The LLM Wiki solves this by introducing a persistence layer: - Compounding Synthesis: Knowledge is extracted and filed into canonical concept and entity pages. New documents append to or challenge existing knowledge rather than just sitting in a vector database. - Pre-computed Reasoning: Because the LLM maintains the wiki asynchronously (during the ingestion phase), complex synthesis is already "pre-computed." When queried, the LLM reads from a highly organized, dense knowledge graph rather than scattered raw fragments. - Human-Readable: Unlike vector embeddings, the intermediate state (the wiki) is plain-text markdown. You can browse it, edit it, and visualize it in tools like Obsidian.

When Does It Fit?

The LLM Wiki pattern is ideal for long-term, compounding knowledge domains: - Personal Development: Tracking health, psychology, journal entries, and synthesizing a structured picture of oneself over time. - Deep Research: Conducting multi-week research on complex topics where an evolving thesis must be maintained. - Book/Media Consumption: Building rich companion wikis for long-form content (for example, character relationships, plot threads, thematic analysis). - Internal Team Wikis: Maintaining living documentation fed by meeting transcripts, Slack threads, and customer calls, without placing the maintenance burden on human engineers.

Ecosystem & Connections

The LLM Wiki pattern relies on a triad of tools: 1. The IDE (Obsidian): The human interface for reading, editing, and visualizing the knowledge graph (using features like Graph View and Dataview). 2. The Agent (Claude Code, Codex, OpenCode): The autonomous actor that executes instructions, reads files, and writes markdown. 3. The Search Engine (qmd): As the wiki scales, local hybrid search engines like qmd (BM25 + Vector + LLM Reranking) provide agents with precise retrieval capabilities via the Model Context Protocol (MCP).

Compatibility & Requirements

To implement an LLM Wiki, you need: - An LLM agent with direct, unrestricted read/write access to a local filesystem. - A well-defined schema or instruction file (for example, CLAUDE.md, AGENTS.md) to enforce structural consistency. - A local-first markdown editor for human oversight. - (Optional) A local embedding/search tool for scaling beyond simple index.md traversal.

Alternatives

  • Standard RAG (for example, NotebookLM, ChatGPT File Uploads): Better for quick, one-off interactions with static documents where long-term persistence is unnecessary.
  • GraphRAG: An advanced form of RAG that builds a knowledge graph from raw documents, but typically stores it in a graph database rather than human-readable markdown.
  • Manual PKM: The traditional Zettelkasten or Second Brain approach. Highly personalized but often suffers from "maintenance bankruptcy" where the effort of cross-referencing outpaces the value.

Migration & Lock-in

Because the output of an LLM Wiki is standard markdown, there is zero vendor lock-in. You can swap the LLM agent (for example, moving from Claude Code to a local model via Ollama) or the IDE (from Obsidian to Logseq) without losing any synthesized knowledge or structural integrity.

Community Health

The shift toward agent-maintained wikis gained significant traction from April 2026, driven by capable coding agents and tools like qmd that bridged the gap between raw file systems and LLM context windows. Many community implementations favor open-source, local-first toolchains for privacy and data sovereignty.

Adoption signals (as of 2026-09-25):

  • Karpathy's "LLM Knowledge Bases" X post (2026-04-02) was reported at 16M+ views in early write-ups and ~21.9M in later ones. The gist collected 5,000+ stars within days and stood at ~48.6k stars and ~10k forks on 2026-09-25.
  • The framing comes from the gist itself: "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."
  • Within about two weeks, dozens of implementations appeared, including Obsidian plugins and hosted services. Some run the pattern fully offline (for example, NiharShrotri/llm-wiki: Ollama + Qwen3 + qmd), which shows the maintenance loop does not depend on frontier cloud models.

Core Operations

The pattern reduces to three recurring agent workflows. Step-by-step versions are in How-to Guides, and the input/output contract of each is in Reference.

  1. Ingest — read a new raw source, create a provenance reference note, merge facts into entity/concept pages, flag contradictions, update the global index, append to the audit log.
  2. Query — read the index, open the 3-5 relevant pages, synthesize an answer. Valuable answers are filed back as new wiki pages rather than discarded.
  3. Maintain — periodic lint passes: fix broken links, merge duplicate pages, refresh stale summaries, and keep the index consistent with the file tree.

Topic Map

Page What it covers
How-to Guides Ingest/query/lint workflows, log.md and git recipes, qmd setup and MCP wiring, writing links that survive the build, troubleshooting
Reference File roles, operation contracts, scale thresholds, qmd facts, the vault's link and citation contract, security checklist
Explanation Origins, three-layer architecture, ingestion lifecycle, RAG contrast, scaling, failure modes, why wikilinks are the citation unit, security model
Ref: Karpathy LLM Wiki Source note for the original gist
  • Zero Data Retention — provider-side retention controls for cloud agents that read the wiki.
  • AI PDLC — the same "curated repo knowledge as agent substrate" thesis at organization scale.
  • LLM Fundamentals — RAG, context windows, and model internals behind the RAG-vs-wiki trade-off.
  • AI Agents domain and the OpenClaw vs Hermes Agent vs Claude Code comparison — the agents that can run the maintenance loop. No domain comparison page covers the LLM Wiki pattern itself yet.
  • Tools Catalogue — lists qmd and LLM-wiki implementations such as claude-obsidian.

Sources

Questions

  • Scaling Limits: The gist says index-only navigation works at "~100 sources, ~hundreds of pages". Where exactly (file count/token size) does it break down and require qmd? No published measurement exists yet; see Reference: Scale Thresholds.
  • Conflict Resolution: How should the agent handle direct contradictions between an older, highly trusted source and a newer, not-yet-corroborated source during the Ingestion phase? This vault's current rule (cite both, flag in the newer note) is in Reference: Link and Citation Contract.
  • Human-in-the-Loop: What is the optimal UI/UX for a human to review and approve the wiki modifications of the agent before they are committed? Git diffs and PRs are the current answer (Explanation: Git as the State Store).