What Is LLM Wiki? Karpathy's Idea That Turns Notes Into a Brain

What LLM Wiki Actually Means and Why the Term Is So Confusing

Search for "LLM Wiki" and you'll run into a wall of conflicting explanations. Some pages describe a personal note-taking method. Others point to a downloadable desktop app. A few reference GitHub repositories that auto-generate encyclopedia-style articles using AI agents. They're all using the same two-word phrase, but they're talking about very different things.

Before unpacking each layer, here's the simplest definition you need:

An LLM Wiki is a structured collection of markdown files designed to be read, queried, and maintained by a large language model — turning your personal notes and documents into a living knowledge base that an AI can reason over, rather than a static archive only a human can browse.

That core idea, championed by Andrej Karpathy, is where everything starts. But the term has splintered into at least three distinct meanings — and understanding which one someone is referring to saves you hours of confusion.

The Three Meanings of LLM Wiki

When someone says "LLM Wiki" or "llm-wiki," they could mean any of the following:

• The design pattern — A workflow philosophy where you maintain a directory of plain markdown files organized so that an LLM (like Claude, GPT, or an open-source model) can consume them directly as context. You ask questions in natural language; the model reads your files and gives grounded answers drawn from your knowledge, not the general internet. This is the Karpathy-originated concept at the heart of the movement.

• Open-source CLI and agent tools — Projects like nvk/llm-wiki, which functions as a plugin for coding agents such as Claude Code or OpenAI Codex. It spins up parallel research agents that investigate topics and compile cross-referenced wiki articles — no standalone app required.

• Desktop applications and wiki generators — Tools like nashsu/llm_wiki, a cross-platform desktop app built with Tauri and React that provides a visual knowledge tree, a chat interface, and a knowledge graph view. Other projects, such as Pratiyush/llm-wiki, mine your existing LLM conversation transcripts and generate a browsable static wiki from them.

Each meaning is legitimate. Each serves a different audience. And the overlap between them is exactly what makes a simple search so disorienting.

Why the Term Has Become So Confusing

The AI knowledge management space has exploded in a remarkably short window. Concepts that barely existed a couple of years ago — retrieval-augmented generation, agent-driven research, context-window optimization — have gone from academic papers to everyday developer tools. In that rush, distinct ideas collapsed into shared shorthand.

"Wiki LLM" might refer to using AI to generate wiki content. "LLM wiki" might mean feeding a wiki to an AI. The design pattern and the tools built around it ended up sharing a name, and most articles you'll find online assume you already know which version they're discussing. Some focus entirely on one GitHub repository without acknowledging the broader concept. Others explain the philosophy without mentioning that installable tools already exist.

The result is a fragmented content landscape where beginners bounce between pages that each tell a different slice of the story, never getting the full picture. This article is designed to fix that. It covers all three meanings, explains how they connect, and helps you decide which approach — or combination of approaches — fits your actual needs.

The concept is deceptively simple on the surface, but the engineering choices underneath it reveal a genuinely new way of thinking about knowledge. To understand why this idea resonates so deeply with developers, researchers, and AI enthusiasts, it helps to trace it back to the person who articulated it most clearly.

Andrej Karpathy and the Origin of the LLM Wiki Concept

Andrej Karpathy is not someone who needs an introduction in the AI world. As a co-founder of OpenAI, former senior director of AI at Tesla (where he led the Autopilot vision team), and one of the most respected educators in deep learning, his ideas carry serious weight. So when Karpathy published a GitHub Gist titled "LLM Wiki" describing a pattern for building personal knowledge bases with LLMs, the developer community paid attention. The gist quickly accumulated thousands of stars and forks, sparking a wave of implementations, critiques, and adaptations.

The Karpathy LLM Wiki concept starts with a deceptively simple observation: most people's experience with LLMs and documents looks like RAG — you upload files, the model retrieves relevant chunks at query time, and generates an answer. It works, but the LLM is rediscovering knowledge from scratch on every question. Nothing compounds. Nothing builds up.

Karpathy's Vision of LLM-Readable Knowledge

Imagine you've spent months researching a topic. You have dozens of articles, papers, and notes scattered across apps. Every time you ask an AI a question about that research, it starts from zero — finding fragments, piecing them together, with no memory of the synthesis it performed yesterday. That's the problem Karpathy identified.

His core insight flips the typical RAG workflow on its head. Instead of just indexing raw documents for retrieval, the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files that sits between you and the raw sources. As Karpathy describes it, when you add a new source, the LLM reads it, extracts key information, and integrates it into existing pages — updating entity entries, revising topic summaries, noting contradictions, and strengthening the evolving synthesis. The knowledge is compiled once and kept current, not re-derived on every query.

This Andrej Karpathy LLM knowledge base architecture has three clean layers:

• Raw sources — Your curated collection of documents, articles, and data files. These are immutable. The LLM reads from them but never modifies them.

• The wiki — A directory of LLM-generated markdown files: summaries, entity pages, concept pages, comparisons, and an evolving synthesis. The LLM owns this layer entirely.

• The schema — A configuration file (like CLAUDE.md for Claude Code or AGENTS.md for Codex) that tells the LLM how the wiki is structured, what conventions to follow, and what workflows to execute during ingestion, querying, or maintenance.

You'll notice how naturally this connects to the broader ecosystem of AI coding configuration files. CLAUDE.md, AGENTS.md, and similar files already instruct AI assistants about project conventions, tech stacks, and workflows. The Karpathy wiki pattern simply extends that same principle from code projects to all knowledge — your research, your notes, your domain expertise. The schema file is what transforms a generic chatbot into a disciplined wiki maintainer.

From Concept to Community Movement

What happened after Karpathy published the gist is a case study in how quickly ideas propagate through open-source communities. Developers began forking the pattern and adapting it to their own domains — product management, competitive analysis, academic research, health informatics, even reading companion wikis for books. Some built CLI tools to automate the ingest-query-lint cycle Karpathy described. Others integrated it with Obsidian's graph view, using the editor as a real-time browser while the LLM handled all the cross-referencing and bookkeeping.

The pattern resonated because it addressed something deeply frustrating: humans abandon wikis because the maintenance burden grows faster than the value. Updating cross-references, keeping summaries current, noting when new data contradicts old claims — that tedious bookkeeping is exactly what LLMs handle effortlessly. As Karpathy puts it, the human's job is to curate sources, direct the analysis, and ask good questions. The LLM's job is everything else.

This division of labor is what bridges the gap between casual note-taking and a production-grade knowledge system. You don't need to be a meticulous librarian to maintain a rich, interlinked knowledge base — you just need to feed it good sources and stay curious. The LLM handles the grunt work that makes the whole thing actually useful over time.

Of course, a compelling vision is one thing. Understanding the mechanics that make it work — how markdown flows into an LLM's context window, how files get organized, and what happens when your wiki outgrows what the model can read in a single pass — is where the real learning starts.

How LLM Wikis Work Under the Hood

Picture a shelf of neatly labeled notebooks. Each notebook covers a single topic, written in clean handwriting with a table of contents on the first page. When someone asks you a question, you pull the relevant notebooks off the shelf, flip to the right sections, and synthesize an answer. An LLM Wiki works the same way — except the notebooks are markdown files, the shelf is a directory on your computer, and the reader is a large language model.

The architecture follows a surprisingly straightforward flow. You maintain a folder of structured markdown files on a topic you care about. When you ask a question, those files get loaded into the LLM's context window — the working memory the model uses to generate responses. The LLM reads your curated knowledge, grounds its reasoning in what you've written, and produces answers, summaries, or new content that reflects your specific domain rather than generic internet knowledge.

That simplicity is the entire point. There's no vector database to configure, no embedding pipeline to debug, no infrastructure to deploy. It's files, a folder structure, and a model that can read them. But the details of how you organize those files — and what happens when they grow beyond what the model can read in one pass — make the difference between a toy demo and a genuinely useful knowledge system.

The Markdown-First Architecture

Why markdown, specifically? Four reasons converge to make it the natural format for LLM-consumable knowledge:

• Lightweight and universal — Markdown files are plain text. They open in any editor, on any operating system, with zero dependencies. No proprietary formats, no lock-in.

• Human-readable and LLM-readable simultaneously — A well-written markdown file communicates clearly to both you and the model. Headings create hierarchy. Lists organize related ideas. Bold text signals emphasis. The model parses these structural cues natively.

• Version-controllable via Git — Every change to your wiki can be tracked, diffed, and rolled back. This matters enormously when an LLM is editing your files during the ingest cycle — you need the ability to review what changed and revert bad updates.

• Natively parseable by LLMs — Large language models are trained on massive amounts of markdown content from GitHub, documentation sites, and technical blogs. Markdown is arguably the format they understand best after plain prose.

A practical directory structure gives both you and the LLM a predictable map of where knowledge lives. While there's no single "right" layout, a pattern like this provides a solid starting point that you can adapt:

The /agents/ folder deserves special attention. This is where files like CLAUDE.md and AGENTS.md live — the instruction layer that transforms a general-purpose LLM into a disciplined wiki editor. If you've worked with a code LLM like Claude Code, you've already seen this pattern in action. A Karpathy-style CLAUDE.md file for a knowledge wiki serves a parallel purpose: it tells the model the wiki's structure, the naming conventions for files, the rules for when to create a new topic page versus updating an existing one, and the workflow for flagging contradictions. As Claude Code's best practices documentation recommends, these instruction files should include what the model can't guess on its own — editorial policy, merge rules, review conventions — while omitting anything it can figure out by reading the files themselves.

In the nashsu/llm_wiki implementation, this instruction layer splits the ingest process into two distinct stages. Stage 1 analyzes a new source, extracting entities, concepts, relationships to existing wiki pages, and potential contradictions. Stage 2 then generates or updates the actual wiki artifacts — source summaries, entity pages, concept pages, and index files. That separation between understanding and writing is a design choice worth noting. It lets the model surface structural insights before committing anything to the wiki, reducing the risk of shallow or disjointed output.

Context Window Constraints and Chunking Strategies

Here's the scaling question that most introductions to this concept gloss over: what happens when your markdown wiki grows larger than what the LLM can read in a single prompt?

Every model has a context window — a hard ceiling on how much text it can process at once. Even today's long-context models with 200,000-token windows hit a practical limit when a wiki spans hundreds of densely written files. And as research into the "lost in the middle" problem has shown, even when content technically fits inside the window, information buried deep in a long prompt can be overlooked or underweighted by the model.

This constraint doesn't invalidate the LLM Wiki pattern — it just means you need strategies for deciding which files to load and how to handle content that exceeds the ceiling. Several approaches work well, and most mature setups combine more than one:

• Selective file inclusion — Instead of loading the entire wiki for every query, you pick only the files relevant to the current question. An index.md file that maps topics to file paths acts as a table of contents the LLM (or a lightweight script) can scan to decide what to pull in. This is the simplest strategy and often sufficient for personal wikis.

• Hierarchical summarization — Each topic file has a brief summary at the top (a few sentences) and detailed content below. When context space is tight, the LLM reads only the summaries across many files to get the big picture, then dives into full detail for the most relevant topics. Think of it as zooming in and out on a map.

• Chunking the wiki into Obsidian-style atomic notes — Rather than writing long monolithic files, you break knowledge into small, self-contained chunks — one concept per file, each with clear metadata headers and internal links. These Obsidian chunks are independently meaningful, so any subset of them can be assembled into a coherent context window without missing critical dependencies.

• Hybrid retrieval — For larger knowledge bases, you can layer a lightweight search step on top of the wiki. Embed each file or section as a vector, retrieve the most relevant ones for a given query, then feed those into the LLM's context window. This is where the LLM Wiki pattern starts to overlap with RAG — and that's intentional. As architectural analyses of the pattern emphasize, LLM Wiki does not eliminate retrieval; it adds a persistent, curated wiki layer and then retrieves from both wiki pages and raw sources.

• Leveraging emerging long-context models — The context window ceiling keeps rising. Models that can process hundreds of thousands of tokens make the "selective loading" problem less acute for small-to-medium wikis. A personal wiki of 50 to 100 well-structured markdown files may already fit comfortably in a single prompt with current-generation models, no chunking required.

The right combination depends on scale. A researcher with 30 files on a niche topic can get away with selective inclusion and a good index. A team building a shared knowledge base across thousands of documents will need hybrid retrieval and aggressive summarization. The critical insight is that these strategies are not all-or-nothing — you can start simple and add sophistication as your wiki grows.

One detail worth flagging: the nashsu/llm_wiki project uses a SHA-256 ingest cache to skip re-processing unchanged files when new sources are added. That's a practical optimization, but it doesn't guarantee deterministic output. Both analysis and generation steps use low-temperature LLM calls (temperature 0.1 without a fixed seed), so the same source ingested twice could produce subtly different wiki content. Your wiki is a living draft, not a compiled binary.

Understanding these architectural mechanics raises an obvious follow-up question: how does this approach actually compare to the alternatives? When should you reach for an LLM Wiki instead of a traditional RAG pipeline, a fine-tuned model, or even a conventional wiki platform like Confluence? The differences are sharper — and more nuanced — than most people assume.

LLM Wiki vs RAG vs Fine-Tuning vs Traditional Wikis

Five fundamentally different approaches compete for the same job: helping you store, retrieve, and reason over knowledge. Each makes different tradeoffs on cost, complexity, privacy, and accuracy. Yet most discussions treat them as interchangeable — or worse, never put them side by side at all. The table below gives you a single reference point for comparing them honestly.

A few patterns jump out immediately. Traditional wikis like MediaWiki or Confluence have zero hallucination risk — a genuine advantage for teams that need their documentation to say exactly what a human wrote, nothing more. Fine-tuning sits at the opposite extreme: powerful but expensive, hard to update, and risky when the model encounters questions outside its training distribution. The LLM Wiki and RAG approaches occupy the middle ground, and the confusion between them is the single biggest source of misunderstanding in this space.

LLM Wiki vs RAG — Clearing Up the Biggest Misconception

Many readers encounter the LLM Wiki concept and immediately ask: "Isn't this just RAG?" The answer is no — but the distinction is more about workflow philosophy than raw technology.

RAG automates retrieval. You ingest documents into a vector database, and when a query arrives, the system searches for semantically similar chunks, injects them into the prompt, and generates a response. The user doesn't choose which chunks the model sees. The retrieval algorithm does. As enterprise analyses of the pattern consistently find, knowledge base quality — not retrieval tuning — is the dominant factor in whether RAG systems succeed or fail. A perfectly relevant chunk retrieved from a deprecated source still produces a wrong answer.

An LLM Wiki, by contrast, puts curation front and center. You — or the LLM acting under your schema instructions — deliberately structure, synthesize, and maintain the knowledge before it ever enters a prompt. The model reads a curated, interlinked set of wiki pages rather than raw, unprocessed document fragments. The critical difference is that the wiki represents compiled knowledge , not just indexed text.

When does each approach shine?

• Choose LLM Wiki when your knowledge set is small to medium (under a few hundred files), when you value synthesis over raw retrieval, when you want the model to build a persistent, evolving understanding, or when you're a solo researcher or small team that can curate sources deliberately.

• Choose RAG when your corpus is large and dynamic (thousands of documents updating frequently), when you need to serve many users with varied queries against the same data, or when enterprise-scale governance and audit trails are required.

• Combine both when your wiki outgrows the context window. As discussed in the previous section, hybrid retrieval — embedding wiki pages and retrieving the most relevant ones per query — bridges the gap naturally. The wiki adds a curated synthesis layer; RAG handles the selection at scale.

The Karpathy LLM Wiki concept doesn't reject retrieval. It argues that retrieval alone is insufficient. Feeding an LLM a carefully maintained wiki page titled "transformer-architecture.md" — with cross-references, source attributions, and noted contradictions already compiled — produces fundamentally different output than feeding it three raw chunks that a vector search deemed relevant. One is a meal; the other is a bag of ingredients.

When Simpler Deterministic Tools Are Better

Here's the contrarian take that most AI-focused articles skip entirely: sometimes you don't need an LLM at all.

If your question is "find every file in this project that mentions 'authentication timeout,'" grep answers it instantly, deterministically, and for free. A static site generator like Hugo or Jekyll turns a folder of markdown files into a searchable, navigable website in seconds — no token costs, no hallucination risk, no API latency. A lightweight full-text search index (think Lunr.js or Meilisearch) handles keyword lookup across thousands of documents faster than any LLM inference call.

The honest framing is this: LLMs excel at synthesis, connection-finding, and natural language reasoning over unstructured knowledge. Deterministic tools excel at exact matching, structured lookups, and tasks where you need a guaranteed, reproducible result. A Notion wiki with solid internal links and good search might be all a small team ever needs — no AI required.

The right question isn't "Which tool is best?" It's "What does my actual problem require?" If you need to ask open-ended questions across a body of knowledge and get synthesized, contextual answers, an LLM Wiki earns its overhead. If you need to find a specific document, verify a specific fact, or submit content to a platform like Wikipedia where every claim must be verifiable and human-authored, deterministic search and traditional editorial workflows remain superior.

Choosing the right approach also means understanding what tools already exist in this space — and several of them are evolving fast. The ecosystem around the LLM Wiki concept has grown well beyond a single GitHub gist, branching into CLI tools, desktop applications, and AI-enhanced knowledge platforms that each interpret the core idea differently.

The LLM Wiki Tool and Project Ecosystem

A compelling design pattern attracts builders. Within days of Karpathy's original post going viral, developers started shipping implementations — CLI tools, desktop apps, Claude Code skill packages, and Obsidian-first frameworks — each interpreting the core idea through a different lens. The result is a growing ecosystem where no single tool dominates, and most users end up combining several to get the workflow they want.

Understanding what's available helps you avoid reinventing something that already exists — and helps you spot the gaps that no tool has fully closed yet.

Open-Source CLI Tools and GitHub Projects

The most active corner of the ecosystem lives on GitHub. These projects range from minimal scripts to full-featured desktop applications, and they target different stages of the LLM Wiki workflow:

• llmwiki (lucasastorian) — An open-source implementation designed to work with Claude via MCP (Model Context Protocol). You upload your documents, connect the agent, and it writes and maintains your wiki automatically. Its key differentiator is tight MCP integration, which lets Claude Code read and write files directly without manual copy-pasting. Ideal for developers already embedded in the Claude Code ecosystem.

• nashsu/llm_wiki — A cross-platform desktop application built with Tauri and React. It provides a visual knowledge tree, a built-in chat interface, and a knowledge graph view. Rather than requiring command-line fluency, it gives you a GUI for browsing the wiki the LLM generates. This targets users who want the Karpathy pattern without living in a terminal — think researchers, analysts, or knowledge workers more comfortable with visual tools.

• obsidian-wiki (Ar9av) — A framework specifically designed for AI agents to build Obsidian-native wikis using the Karpathy pattern. It treats your Obsidian vault as the output layer, so you get graph view, backlinks, and Dataview queries out of the box. Best suited for anyone already invested in the Obsidian ecosystem who wants to add an LLM-driven wiki layer on top.

• wiki-skills (kfchou) and karpathy-llm-wiki (Astro-Han) — Drop-in Claude Code skill packages that implement the ingest-query-lint cycle. Instead of building a standalone tool, these projects give you reusable prompt templates you can invoke inside Claude Code with a single command. They lower the barrier to entry dramatically — if you already use Claude Code, you can start running the pattern in minutes.

• llm-wiki-compiler — Compiles markdown knowledge files into topic-organized wikis. It focuses on the "compilation" metaphor Karpathy emphasizes — treating raw sources as input and wiki pages as compiled output. Useful for users who want a batch-processing approach rather than an interactive agent conversation.

A related class of tools supports the broader workflow without being "LLM Wiki" projects per se. Rendergit-style tools let you visualize how markdown files have changed over time — essential when an LLM is updating your wiki pages during ingest and you need to review the diffs. Browser extensions that show rendered versus raw source views (similar to how a view rendered source Chrome extension displays raw HTML alongside rendered output) serve a parallel purpose: they help you inspect exactly what the LLM produced versus what you expected. These aren't glamorous, but they're part of the quality-control layer that separates a reliable wiki from a black-box generator.

Karpathy himself has adjacent projects that feed into this ecosystem, most notably his research-oriented work on using AI agents for automated investigation and synthesis. Tools like QMD — a local markdown search engine built by Shopify CEO Tobi Lutke that uses hybrid BM25/vector search with LLM re-ranking — serve as the search layer Karpathy explicitly recommends for navigating large LLM Wikis. Claude Code users working in Vim or terminal editors can invoke these tools directly, keeping the entire workflow inside the command line without needing a separate GUI.

Personal Knowledge Tools With AI Integration

The open-source projects above were purpose-built for the LLM Wiki pattern. But established knowledge tools have been converging toward the same territory from the opposite direction — adding AI capabilities to platforms originally designed for human-only use.

Obsidian remains the closest natural fit. Its graph view visualizes the interlinked structure an LLM Wiki generates. Its internal links and backlink panels let you trace how concepts connect across pages. Its plugin ecosystem — including Dataview for structured queries, Smart Connections for AI-assisted linking, and the Obsidian Web Clipper for pulling articles directly into your raw sources folder — covers many of the pieces Karpathy's pattern calls for. Multiple community members maintain their raw sources and wiki pages as Obsidian vaults synced via Git, giving them version control and visual navigation in one setup.

Notion has taken a different path, layering AI features (summarization, Q&A, autofill) directly into its wiki product. For teams already using Notion for documentation, this is the lowest-friction way to get AI-assisted knowledge management. The limitation is that Notion's AI operates on your pages as isolated documents — it doesn't build persistent, cross-referenced wiki structures the way the Karpathy pattern prescribes. You get AI-powered search and summaries, but not the compounding synthesis where each new source strengthens every related page.

The reality for most power users is a stitched-together stack: Obsidian for editing and visualization, Git for version control, Claude Code or another LLM agent for ingest and maintenance, QMD or a similar tool for search, and perhaps a web clipper for capturing sources. It works — but the friction is real. Sync conflicts between Obsidian and Git, context fragmentation when your sources live in one app and your wiki lives in another, and the absence of a unified AI layer that can see everything at once. Each tool handles its piece well, but no single tool handles the whole workflow.

This fragmentation isn't just an inconvenience. It creates real knowledge gaps. When your captured sources, your AI-generated summaries, and your visual concept maps live in three different applications, the LLM can only ever see part of the picture. The richer and more interconnected you want your knowledge base to become, the more that tool-stitching friction works against you — and the more important it becomes to understand the honest limitations of the current approach before committing to a setup.

Limitations and Honest Challenges You Should Know About

Every tool and pattern has a highlight reel. The previous sections covered the vision, the architecture, the ecosystem, and the comparisons. This section covers what breaks — because if you're going to invest time building an LLM-consumable knowledge base, you deserve to know exactly where the cracks form before you discover them the hard way.

The LLM Wiki pattern is genuinely powerful. It's also genuinely fragile in ways that demo setups rarely expose. The challenges below aren't reasons to avoid the approach — they're reasons to go in with your eyes open and your expectations calibrated.

Hallucination Risk and Knowledge Conflicts

Imagine you've built a 50-page wiki on a technical domain. One of your source articles contains an outdated statistic. The LLM ingests it, weaves that number into three different topic pages, and links it to two entity entries. A week later, you add a newer source that contradicts the old figure. The LLM might update one page but miss the other two. Or worse — it might attempt to reconcile the contradiction by inventing a narrative that bridges both numbers, producing a plausible-sounding synthesis that's actually wrong.

This is the hallucination contamination risk that Steph Ango, CEO of Obsidian, has flagged as a hard requirement to address: keeping human-curated vaults strictly separate from agent-generated content. When an LLM writes an incorrect connection into your wiki, that error doesn't stay isolated. Every subsequent query that touches those pages gets contaminated. The knowledge compounds — but so do the mistakes.

The underlying problem is subtler than simple factual errors. LLMs are pattern-completion machines. When they encounter two related but contradictory statements across different markdown files, they don't flag an error the way a database constraint would. They interpolate. They smooth over the tension. They produce confident, well-structured prose that papers over genuine disagreements in your source material. For a research wiki where tracking disagreements is the point, this LLM style of confident synthesis can quietly erase the nuance you were trying to preserve.

Version control through Git helps — you can diff every change the LLM makes and revert bad updates. But version control tells you what changed, not whether the change was correct. Reviewing LLM-generated diffs requires domain expertise, and as your wiki grows, the volume of changes per ingest cycle grows with it. A single new source can trigger updates to 10-15 wiki pages, according to Karpathy's own description of the operational cycle. Reviewing all of them carefully is realistic at 30 files. At 300, it becomes a full-time job.

Maintenance Burden and the Gap Between Demo and Production

Here's a pattern that plays out repeatedly: someone reads about the LLM Wiki concept on a weekend, sets up a folder of markdown files, feeds in a handful of sources, asks a few questions, gets impressively grounded answers, and tweets about how transformative it is. That demo experience is real. The problem is what happens on week four.

Production-grade knowledge systems require ongoing curation that demos never surface. Files accumulate. Some become outdated. Naming conventions drift. The index file falls out of sync with the actual directory contents. Two topic pages cover overlapping ground because they were generated from different sources at different times. The LLM, working from its schema instructions, may not notice these structural issues unless you've explicitly programmed lint rules to catch them — and even then, the lint process itself consumes tokens and requires review.

Cost compounds alongside complexity. Every query against a commercial LLM API bills you for every token in the context window. A 100-file wiki loaded into a single prompt can easily consume 200,000 to 500,000 tokens per query. At current frontier model pricing — $1.75 per million input tokens for GPT-5.2, $5.00 for Claude Opus 4.6 — that translates to roughly $0.35 to $2.50 per query before the model even generates a response. Run 50 queries a day for a month and you're looking at $525 to $3,750 in input costs alone.

The key challenges that separate demo setups from production systems:

• File hygiene degrades silently — Outdated pages, duplicate coverage, and orphaned files accumulate over weeks. Unlike a database with integrity constraints, a folder of markdown files has no built-in mechanism to enforce consistency.

• Token costs scale with wiki size, not query complexity — A simple yes/no question costs the same as a deep synthesis request if you're loading the same context window. Selective file inclusion mitigates this, but adds engineering work to decide which files to load.

• LLM output is non-deterministic — Ingesting the same source twice can produce subtly different wiki content. Low-temperature settings reduce variance but don't eliminate it. Your wiki is a living draft, and no two runs produce identical results.

• Quality assurance doesn't scale automatically — Reviewing LLM-generated updates is manageable for a small wiki. Beyond ~100 articles (Karpathy's own acknowledged sweet spot of approximately 400,000 words), the review burden outpaces most individuals' capacity.

• Cross-team use introduces conflicts — When multiple people contribute sources or query the same wiki, contradictory tribal knowledge and concurrent editing conflicts emerge. Basic markdown files lack the governance features — role-based access, edit approvals, conflict resolution — that enterprise platforms like Confluence provide out of the box.

Local and open-source LLM alternatives change the cost equation significantly but introduce their own tradeoffs. Running a model like Llama or Mistral locally eliminates per-token API fees entirely. The tradeoff is hardware requirements (a capable GPU), lower raw performance compared to frontier models, and the maintenance overhead of managing model updates yourself. For personal knowledge bases and experimentation, local models are increasingly viable. For production systems where answer quality directly affects decisions, the gap between local open-weight models and frontier APIs remains meaningful — though it narrows with every release.

Privacy and Data Governance Concerns

This is the challenge that stops many enterprise and privacy-conscious users before they start. The entire LLM Wiki pattern revolves around feeding your knowledge — notes, research, proprietary documents, meeting transcripts — into a language model. If that model is a cloud-hosted API, your data leaves your machine, traverses the internet, and lands on someone else's infrastructure.

As enterprise AI analyses consistently note, the questions are unavoidable: Where does the data go? Is it stored? Who has access? Could it be used to train future model versions? For a personal wiki about a hobby, these questions are minor. For a knowledge base containing client data, financial analysis, medical research, or proprietary competitive intelligence, they're deal-breakers.

The spectrum of options looks roughly like this:

The Karpathy methodology explicitly supports local models — tools like Llama and Mistral can run the entire ingest-query-lint cycle on your own hardware. This makes the pattern suitable for environments with significant data security concerns, including finance, healthcare, and regulated industries. The tradeoff is real, though: as of current model generations, the quality gap between a locally-run open-weight model and a frontier cloud API is noticeable on complex reasoning and synthesis tasks — exactly the tasks where an LLM Wiki shines brightest.

For many users, the practical middle ground is a tiered approach. Keep sensitive or proprietary content in a local-only wiki queried by a local model. Use cloud APIs for general-purpose research topics where the content isn't confidential. Maintain strict separation between the two — different folders, different schema files, different workflows. It's not elegant, but it balances privacy against capability without forcing an all-or-nothing choice.

There's also a subtler governance concern that goes beyond data transit. When an LLM synthesizes your wiki content, the output blends your knowledge with the model's pre-trained patterns. If you later use that synthesized wiki to generate training data for fine-tuning — a path Karpathy himself proposes — errors from both the wiki and the model's prior knowledge get permanently embedded in model weights. Research from Tanwar et al. (2024) found that fine-tuning on hallucinated data causes "poor calibration," baking mistakes into the model in ways that are difficult to detect and impossible to fully reverse. The pipeline is only as trustworthy as its weakest input.

These limitations are real, but none of them are fatal. They're engineering challenges with known mitigations — careful curation, selective context loading, local model options, vault separation, and disciplined review cycles. The question isn't whether the LLM Wiki pattern has problems. Every approach does. The question is whether you're willing to invest the effort that turns a fragile demo into a reliable system — and that starts with understanding exactly how to build one from scratch.

How to Build Your Own LLM Knowledge Base Step by Step

Knowing the limitations sharpens your decisions — but it shouldn't keep you from starting. The gap between "understanding the concept" and "having a working knowledge base" is smaller than most people expect. You don't need specialized infrastructure, a computer science degree, or a weekend-long setup marathon. You need a folder, a handful of well-structured markdown files, and a clear set of conventions that both you and the LLM can follow.

This section walks you through the practical moves: how to organize your directory, what naming conventions actually matter, and how to write markdown that an LLM can parse reliably. The guidance is tool-agnostic — whether you make MD files in Obsidian, write in VS Code, or use a plain text editor, the principles hold.

Designing Your Directory Structure and File Conventions

A well-designed folder layout does double duty. For you, it keeps knowledge navigable. For the LLM, it creates a predictable map it can scan before diving into individual files. The goal is the same principle James Croft emphasizes in his machine-readable knowledge base design: consistency and standardization eliminate ambiguity for both the human and the AI reader.

A recommended starting structure looks like this:

Notice the clear ownership boundaries. The /raw/ folder is yours — the LLM reads from it but never modifies it. The /wiki/ folder belongs to the LLM — it generates and updates those files under the rules you set in /agents/. This separation is what keeps your original sources intact even when the LLM rewrites a synthesis page for the third time.

Naming conventions matter more than you'd think. A file called notes-v2-final-FINAL.md tells neither you nor the LLM anything useful. Instead, adopt a pattern like topic-name.md for concept pages (e.g., transformer-architecture.md, attention-mechanisms.md) and source-author-year.md for source summaries (e.g., source-karpathy-2025.md). Kebab-case, lowercase, no spaces. This convention is instantly scannable by both humans and LLMs, and it plays well with Git, Obsidian internal links, and every search tool in the ecosystem.

The most underappreciated piece of the structure is the index or manifest file. This is a single markdown document — typically index.md at the wiki root — that maps every file in the wiki with a one-line description. Think of it as a table of contents the LLM reads first, before deciding which files to pull into its context window. As DAIR.AI's breakdown of Karpathy's architecture describes, these index files with brief summaries of all documents serve as the entry point for queries — the LLM scans the index, identifies relevant pages, and loads only those files. Without an index, the LLM either has to read everything (expensive and slow) or guess which files matter (unreliable).

A README file at the root of your project serves a similar grounding purpose. As Croft notes in his Obsidian knowledge base design, when AI skills interact with the vault, the instructions often start with "Read the vault README to understand the structure." That single instruction grounds the LLM in your conventions before it does anything else — which folders to scan, what naming patterns to expect, and how information flows through the system.

Writing Markdown That LLMs Can Actually Use

Having a clean directory is half the battle. The other half is what's inside each file. Not all markdown is equally useful to a language model. A page of flowing, literary prose with implied context and subtle cross-references might read beautifully to a human but leave an LLM guessing about structure, scope, and intent.

The difference between markdown that works and markdown that works well for LLMs comes down to a few principles. These aren't arbitrary rules — they're drawn from how models actually parse text and where they tend to lose signal.

1. Start every file with a metadata header. A YAML frontmatter block at the top of each file transforms unstructured text into queryable data. Include fields like title, tags, created, last_updated, and status (e.g., draft, reviewed, stale). As Croft's template system demonstrates, the frontmatter is the most important design choice for machine readability — it lets both you and the LLM filter, sort, and categorize notes programmatically.

2. Use clear, hierarchical headings. H1 for the page title. H2 for major sections. H3 for subsections. This heading structure isn't just visual — it tells the LLM where one concept ends and another begins, enabling it to extract specific sections without reading the entire file.

3. Prefer explicit statements over implicit context. Instead of writing "As mentioned earlier, this matters because..." write "Attention mechanisms matter because they allow the model to weigh different parts of the input sequence." LLMs don't have persistent memory across files unless you provide it. Every file should be understandable on its own, with explicit cross-references (links) to related pages rather than assumed background knowledge.

4. Structure information in lists and tables where appropriate. Research on LLM-friendly content confirms that bulleted lists are more reliably recognized as lists of distinct items than comma-separated sentences in a paragraph. Tables convey comparative data more cleanly than prose descriptions. Use the format that matches the information type — don't force everything into paragraphs for the sake of readability.

5. Include a brief summary at the top of each file. Two to three sentences immediately after the frontmatter that capture the core point of the page. This summary serves the hierarchical loading strategy: when context space is tight, the LLM can read summaries across many files to find what's relevant, then load full content selectively.

6. Handle math notation and specialized formatting carefully. If your knowledge base includes equations, use standard LaTeX notation inside dollar signs (e.g., $E = mc^2$ or $$\sum_{i=1}^{n} x_i$$ for display math). Most LLMs parse LaTeX-style math notation reliably, as it dominates their training data from academic sources. For those using Obsidian, this is the same syntax the app's built-in math renderer uses — so your files render correctly for both human reading and LLM consumption. Specialized formatting in R Markdown follows similar conventions: bold text uses double asterisks (**bold**), and equations use the same LaTeX-in-dollar-signs pattern.

7. Use consistent internal linking. When one topic page references another, link to it explicitly — [attention mechanisms](attention-mechanisms.md) or, in Obsidian-style, [[attention-mechanisms]]. These links create the connective tissue of your wiki. They tell the LLM which concepts are related, and they let tools like Obsidian's graph view visualize the link structure automatically.

One principle ties all of these together: write for clarity, not cleverness. The Webex engineering team's analysis puts it well — markdown aligns closely with natural language, making it more intuitive for LLMs to parse. The format's emphasis on plain text and minimal symbols helps models maintain context and continuity. Every heading, every metadata field, every explicit link reduces the cognitive load on the model and improves the quality of what it gives back.

You don't need to rewrite your entire knowledge base overnight. Start with five files on a topic you know well. Give each one a frontmatter block, a summary, clear headings, and explicit links to the others. Create an index file that maps them. Write a one-page schema instruction in your /agents/ folder. Feed the whole thing to an LLM and ask a question that requires synthesizing across multiple pages. The quality of the answer will tell you immediately whether your structure is working — and where to tighten it.

With a working directory and well-written files in place, the next decision is where all of this lives. The workspace you choose — a local vault, a cloud platform, or something in between — shapes everything from privacy and collaboration to how seamlessly AI integrates into your daily knowledge workflow.

Choosing the Right Workspace for Your AI Knowledge Base

You've got the directory structure mapped out, the writing principles internalized, and a handful of markdown files ready to go. The remaining question is deceptively consequential: where does all of this actually live? The workspace you choose determines how smoothly your notes, sources, summaries, and visual maps work together — and whether AI is bolted on as an afterthought or woven into the fabric of your thinking.

Not every tool needs to do everything. But when you're building an LLM Wiki — a knowledge base designed to serve both human understanding and AI reasoning — certain workspace characteristics matter more than others. Here's what to evaluate before committing.

What to Look for in an AI Knowledge Workspace

The ideal workspace for an LLM Wiki reduces the friction between capturing knowledge, structuring it for machine consumption, and querying it through AI. That means you need more than just a good text editor. You need a platform where notes, visual thinking, and AI capabilities coexist without forcing you to stitch together three or four disconnected apps.

The table below compares the workspace characteristics that matter most for LLM Wiki builders. Each tool is evaluated honestly — strengths and limitations included.

A few things stand out immediately. Obsidian's privacy model and local file ownership are outstanding — your .md files sit on your disk, you control backups, and the plugin ecosystem is arguably the richest in the space. Features like obsidian internal links, obsidian linked mentions in the backlink panel, and the ability to customize obsidian graph view colors to visualize topic clusters make it a natural companion for LLM Wiki workflows. Many Karpathy-pattern implementations target Obsidian vaults specifically because the tool's link-and-graph model mirrors the interlinked structure an LLM Wiki generates.

Notion, meanwhile, excels at team collaboration and structured databases. If your priority is sharing a knowledge base across a team with granular permissions, Notion's real-time editing and relational database features are hard to match. The tradeoff is data residency — everything lives on Notion's cloud servers — and the AI layer operates on individual pages rather than building cumulative synthesis across your entire workspace.

Logseq appeals to outliner-minded users who want local-first privacy and open-source transparency. Its daily journal workflow and bidirectional linking are solid, though the outliner-first paradigm can feel constraining when you're writing the kind of long-form, richly structured wiki pages the Karpathy pattern produces.

Bringing Notes, Sources, and Visual Thinking Together

Here's the core problem the ecosystem section exposed: most LLM Wiki builders end up stitching together three or four tools. Obsidian for editing and graph visualization. Git for version control. A separate AI agent for ingest and synthesis. Maybe a diagramming app for concept maps. Each tool handles its piece, but your knowledge fragments across them — and the LLM can only ever see part of the picture in any given session.

This fragmentation isn't just inconvenient. It actively undermines the compounding synthesis that makes the LLM Wiki pattern valuable. When your captured sources, your AI-generated summaries, and your visual concept maps live in different applications, the connections between them exist only in your head. The LLM doesn't know that the mind map you drew in one app relates to the research summary it generated in another. Context gets lost at every seam.

A unified workspace eliminates those seams. When notes, source annotations, AI-generated summaries, and visual canvases coexist in a single environment, the AI layer can see everything at once — and the knowledge base becomes genuinely richer than the sum of its parts.

This is where AFFiNE occupies a distinctive position. It merges markdown document editing, an infinite visual canvas for diagrams and mind maps, and a built-in AI copilot into one open-source platform — all running on a local-first architecture. For developers, researchers, students, and AI enthusiasts building a Karpathy-inspired LLM Wiki, that combination directly addresses the tool-stitching problem. You can write a structured topic page, drag it onto a canvas alongside related concept maps, and ask the AI to summarize connections — without leaving the workspace or losing context between apps.

Because AFFiNE is open-source and supports self-hosting, it also satisfies the privacy requirements the previous section outlined. Your knowledge base stays on infrastructure you control — critical for anyone handling proprietary research, client data, or sensitive analysis. The tradeoff is honest: AFFiNE's plugin ecosystem is younger and smaller than Obsidian's, and its community is still growing. If you rely heavily on specific Obsidian plugins like Dataview or Smart Connections, you'd need to evaluate whether AFFiNE's built-in features cover those workflows or whether the migration cost is worth it.

The right choice depends on where you are in your workflow and what you value most. If you're a solo researcher deeply invested in Obsidian's vault and plugin ecosystem, adding an LLM agent on top of your existing setup may be the path of least resistance. If you're starting fresh and want notes, AI, and visual thinking in one place without assembling a patchwork stack, AFFiNE eliminates the integration overhead upfront. If team collaboration with structured databases is non-negotiable and you're comfortable with cloud hosting, Notion remains a strong option despite its limitations for the LLM Wiki pattern specifically.

No single tool is perfect for every user. The workspace question is ultimately about matching your priorities — privacy, collaboration, visual thinking, AI depth, ecosystem maturity — to the tool that handles the most important ones natively, rather than through workarounds. Whatever you choose, the critical thing is to start building: pick a workspace, create your first five files, and begin feeding them to an LLM. The knowledge compounds from day one — but only if you begin.

Your Next Steps for Getting Started With LLM Wiki

You've seen the concept from every angle — the Karpathy origin story, the markdown-first architecture, the honest limitations, the ecosystem of tools, and the workspace options. The pattern is clear, the tradeoffs are mapped, and the building blocks are free. What remains is the part that actually matters: doing something with all of it.

The beauty of building a knowledge base this way is that there's no single correct entry point. A developer prototyping a weekend project and a research team managing years of literature reviews need fundamentally different starting setups. Matching your approach to your goals — rather than copying someone else's stack — is what separates an LLM knowledge base that compounds over months from one that gets abandoned after a week.

Matching Your Approach to Your Goals

Rather than prescribing one path, here's a map that connects what you're trying to accomplish to where you should begin:

• If you want to experiment quickly — Create a local folder with five markdown files on a topic you already know well. Add an index.md and a simple CLAUDE.md instruction file. Open a terminal, point Claude Code or another LLM agent at the directory, and start asking questions. Total setup time: under an hour. This is the fastest way to feel how the pattern works before investing further.

• If you're a developer building tools or learning a new domain — Pick one of the open-source implementations from the ecosystem section — llmwiki for MCP integration or a Claude Code skill package like wiki-skills for drop-in commands. Feed in documentation, API references, or technical blog posts as raw sources. Let the LLM compile a wiki you can query while you code. Version-control everything with Git so you can review and revert changes.

• If you're a researcher or student building a long-term knowledge system — Invest in a unified workspace from the start. The tool-stitching friction described earlier gets worse over time, not better. AFFiNE's AI Workspace lets you write markdown documents, arrange visual concept maps on a canvas, and use built-in AI for summarization — all in one local-first environment. Alternatively, an Obsidian vault with an LLM agent layer works well if you're already comfortable with that ecosystem.

• If you need team collaboration and shared knowledge — Evaluate platforms with real-time editing, permissions, and privacy controls. For small teams comfortable with cloud hosting, Notion's wiki features plus its AI layer offer a low-friction starting point. For teams handling sensitive or proprietary data, AFFiNE's self-hosting option or an Obsidian vault shared via a private Git repository provides stronger data governance without sacrificing the core pattern.

• If privacy is your top priority — Run a local LLM (Llama, Mistral, or similar) on your own hardware and keep all files on disk. Pair it with a local-first workspace — Obsidian, Logseq, or AFFiNE — and never send your knowledge to a cloud API. You'll trade some answer quality for complete data sovereignty, but for medical research, legal analysis, or proprietary competitive intelligence, that tradeoff is non-negotiable.

Notice that every path above starts small. Five files. One topic. One agent. You don't need to architect a 500-page knowledge base wiki before you begin — you need to build the smallest version that teaches you how the pattern feels in practice.

Start Building Your Private LLM Wiki Today

The core insight of the LLM Wiki concept is easy to overlook because it sounds so simple: you curate the knowledge, and the LLM handles the organizing, linking, summarizing, and maintaining. That division of labor is what makes the pattern powerful. It puts knowledge curation back in your hands rather than outsourcing it to an opaque system that decides what's relevant on your behalf.

Every traditional wiki eventually dies because the maintenance burden outpaces the value. Every RAG pipeline eventually degrades because raw document quality drifts while the retrieval layer stays frozen. The LLM Wiki pattern addresses both failure modes: the LLM never forgets to update backlinks, and the human never stops curating what goes in. As practical implementations have shown, even a modest knowledge base of 50 to 100 articles creates a compounding advantage — every article you add, every question you ask, every health check you run makes the entire system richer and more connected.

Start tonight. Pick a topic you care about. Create five markdown files with clear headings, explicit statements, and YAML frontmatter. Write a one-page schema instruction. Feed everything to an LLM and ask a question that requires synthesizing across at least three of those files. If the answer surprises you with its coherence, you'll understand why Karpathy called this "an incredible new product" waiting to be built.

For readers who want notes, AI summaries, and visual concept maps in a single private workspace without assembling a patchwork of tools, AFFiNE's AI Workspace is a strong place to begin. For those who prefer a terminal-first workflow, a local folder and an open-source CLI agent get you there just as effectively. The tool matters less than the decision to start.

The relationship between humans and AI knowledge systems is still in its earliest chapters. The LLM Wiki pattern won't be the final form — but it represents something genuinely new: a way for individuals and small teams to build living, compounding knowledge systems that grow smarter with every source you add and every question you ask. The tools will evolve. The models will improve. The principle — curate deliberately, structure clearly, let the machine handle the bookkeeping — will endure.

The best knowledge base isn't the one with the most sophisticated architecture. It's the one you actually build, feed, and query — starting with five files and a question worth answering.

Frequently Asked Questions About LLM Wiki

1. What is an LLM Wiki and how does it differ from a regular wiki?

An LLM Wiki is a structured collection of markdown files specifically designed for a large language model to read, query, and maintain. Unlike a traditional wiki such as MediaWiki or Confluence, where humans manually write and update every page, an LLM Wiki uses an AI agent to synthesize sources, generate cross-referenced topic pages, and keep everything current. The human curates the raw inputs and sets the rules; the LLM handles the labor-intensive bookkeeping of linking, summarizing, and flagging contradictions. This makes the knowledge base a living, compounding system rather than a static archive that gradually goes stale.

2. Who created the LLM Wiki concept and why does it matter?

The concept was publicly articulated by Andrej Karpathy, co-founder of OpenAI and former senior director of AI at Tesla, through a widely shared GitHub Gist. Karpathy proposed that instead of relying solely on retrieval-augmented generation, users should let an LLM incrementally build and maintain a persistent wiki from curated sources. His credibility in the AI community gave the idea immediate traction, sparking dozens of open-source implementations and integrations with tools like Claude Code and Obsidian. The concept matters because it shifts knowledge management from passive storage to active, AI-assisted synthesis that compounds over time.

3. Is LLM Wiki the same as RAG (Retrieval-Augmented Generation)?

No. RAG automates retrieval by embedding documents into a vector database and pulling semantically similar chunks at query time. The user has no direct control over which chunks the model sees. An LLM Wiki, by contrast, prioritizes deliberate curation: the LLM compiles and maintains structured wiki pages from your sources before any query is asked. The wiki represents compiled, interlinked knowledge rather than raw indexed text. That said, the two approaches can be combined - when a wiki grows beyond the LLM's context window, hybrid retrieval over wiki pages bridges the gap between curated synthesis and scalable search.

4. What tools can I use to build an LLM Wiki today?

Several open-source tools support the pattern. Lucasastorian's llmwiki integrates with Claude via MCP for automated wiki maintenance. Nashsu/llm_wiki offers a cross-platform desktop app with a visual knowledge tree and chat interface. Claude Code skill packages like wiki-skills and karpathy-llm-wiki provide drop-in commands for the ingest-query-lint cycle. For the workspace layer, AFFiNE (affine.pro/ai) combines markdown editing, an infinite visual canvas, and built-in AI in a single local-first platform, while Obsidian pairs well with LLM agents through its graph view and plugin ecosystem. Each tool addresses a different part of the workflow.

5. How do I get started building my own LLM knowledge base?

Start small: create a local folder with five well-structured markdown files on a topic you know well. Give each file a YAML frontmatter header with title, tags, and date fields. Add clear headings, explicit statements, and internal links between related files. Write an index.md that maps the contents and a simple instruction file (like CLAUDE.md) that tells the LLM how the wiki is organized. Feed the directory to an LLM agent and ask a question requiring synthesis across multiple files. For a unified workspace where notes, AI summaries, and visual concept maps coexist, AFFiNE's AI Workspace at affine.pro/ai offers a local-first, open-source option that eliminates the need to stitch together separate tools.

Related Blog Posts

1. Build a Second Brain: Karpathy's LLM Wiki Method, Step by Step