What Is an LLM Wiki? The RAG Alternative

An LLM wiki is a personal knowledge base that the model writes and maintains for you: you hand it documents, and instead of indexing them for retrieval, it reads each one and folds what it learned into a growing set of interlinked markdown pages. Andrej Karpathy published the pattern as a gist called llm-wiki.md, and the idea has spread far enough that the most popular implementation of it picked up 18,205 GitHub stars in five months.

The name confuses people, so: an LLM wiki is not a wiki about LLMs. It is a wiki written by one.

Key Takeaways:

• RAG re-derives an answer from raw chunks every query. An LLM wiki compiles knowledge once and keeps it current.
• The spec is three layers (raw sources, generated wiki, schema) and three operations (ingest, query, lint).
• The output is plain markdown with [[wikilinks]], so an Obsidian vault opens it directly.
• The flagship implementation, nashsu/llm_wiki, is GPL-3.0, not the permissive licence the GitHub API's NOASSERTION might lead you to assume.

The idea, in one paragraph

Karpathy's gist is short and written to be pasted into an agent rather than run as software. Most people's experience of LLMs plus documents looks like retrieval: you upload files, the model pulls relevant chunks at query time and generates an answer. It works, but nothing accumulates. Ask a question that needs five documents synthesised and the model finds and reassembles those fragments from scratch, then throws the synthesis away. The gist argues for the opposite: have the model incrementally build and maintain a persistent wiki that sits between you and the raw sources, so that when a new source arrives the model reads it, extracts what matters, and integrates it into what is already there, updating entity pages, revising summaries, flagging where the new data contradicts old claims.

Compiled once, kept current, rather than re-derived on every query. That sentence is the whole pattern.

Why this is not RAG with extra steps

The objection comes up immediately and it deserves a real answer rather than a shrug.

A retrieval system optimises for finding. An LLM wiki optimises for having found. The difference shows up in the class of question each can handle: retrieval is strong when the answer sits in a passage somewhere, and weak when the answer only exists as the relationship between six documents nobody has ever read side by side. Cross-references in a wiki are already written down. Contradictions have already been flagged, at ingest time, by a model that had the luxury of thinking about one source carefully instead of answering a user in two seconds.

The cost is symmetrical and worth stating plainly: ingest is slow and expensive, and you pay it whether or not you ever ask the question. A retrieval index over a thousand PDFs is cheap to build. A wiki over the same thousand PDFs means a thousand rounds of careful reading. If your corpus is enormous and your questions are lookups, RAG wins and the pattern is a waste of tokens. If your corpus is a few hundred things you actually care about and your questions are synthesis, the trade goes the other way. We have written separately about a graph-structured take on the same problem for codebases, which shares the instinct that structure built ahead of time beats structure inferred at query time.

That ingest cost is also the practical reason this pattern strands people. Reading a hundred sources twice over, with a vision model captioning embedded images along the way, is hours of compute that has to happen somewhere, and a laptop is the worst possible host for it because you close it. Zentor is a hosted cloud AI computer, which means the ingest queue keeps draining while your machine is in a bag, and the wiki is finished when you next look at it rather than 40% done and paused.

The three layers Karpathy specified

The spec is deliberately boring, which is why it survived contact with a real implementation.

Raw sources sit at the bottom and are immutable: whatever you fed in, unchanged, so every claim upstream can be traced back. The wiki layer above it is entirely LLM-generated and entirely disposable in principle, since it can be rebuilt from the sources. Schema sits alongside as the rules and configuration that tell the model how the wiki should be organised. Two files do the bookkeeping: index.md is the catalogue the model navigates by, and log.md is the chronological record of every operation in a parseable format. Cross-references use [[wikilink]] syntax and every page carries YAML frontmatter.

Three operations act on that structure. Ingest reads a source and writes pages. Query answers from the wiki. Lint checks the wiki against its own schema and flags what has gone stale or inconsistent.

The division of labour is stated outright in the spec: the human curates, the LLM maintains. That is a narrower claim than "the AI organises your knowledge for you", and the narrowness is the point.

Because the wiki is just markdown in a directory, an Obsidian vault opens it with no conversion. That is not a minor convenience. It means the pattern's output survives the tool that produced it, which is more than most knowledge-management software can say.

nashsu/llm_wiki: the pattern as a desktop application

Karpathy's gist is an idea file. nashsu/llm_wiki, by nash_su, is what happens when someone implements it properly: a cross-platform desktop app, first committed 8 April 2026, at 18,205 stars on 11 September 2026, with v0.6.11 released three weeks before that. The README credits the gist directly and is explicit that the original is an abstract design pattern and this is a concrete implementation with extensions.

The extensions are where the engineering is. Ingest was split into two sequential model calls rather than one: an analysis pass that extracts entities, arguments, connections to what already exists and contradictions with it, then a generation pass that turns that analysis into pages. A file called purpose.md was added to hold why the wiki exists at all, distinct from the schema's rules about how it is shaped, and the model reads it on every ingest and query. Documents can be PDFs, Office files, EPUB and MOBI, Org mode, images, media, web clips, or batches of URLs, with PDF processing routed through a built-in, cloud or local MinerU. Images embedded in PDFs get captioned by a vision model and become searchable in their own right.

On top of the wiki sits a knowledge graph with a four-signal relevance model: direct links, source overlap, Adamic-Adar, and type affinity, with Louvain community detection to find clusters nobody labelled. Vector search over LanceDB is available and optional, which is a nice inversion: embeddings as an accessory to the wiki rather than the whole architecture.

There is also a local HTTP API on 127.0.0.1:19828 and a bundled MCP server, plus a companion repo, nashsu/llm_wiki_skill, that exists purely to teach Claude Code or Codex how to call that API. One npx skills add and your coding agent can search the knowledge base. Note the address, though: 127.0.0.1 means the agent has to be on the same machine as the app, which is a constraint people discover late. Putting the wiki on a Zentor cloud computer alongside the agent that queries it keeps both on one always-on host instead of tethering your research assistant to whichever laptop did the ingest.

Running it locally, and the licence nobody checked

The privacy pitch is the honest reason a lot of people want this pattern: your documents stay on your disk, and the model that reads them can be one you run yourself. The README describes per-project model configuration, chat and ingest routed independently, custom providers and headers, and a "Read Sources Only" mode that answers exclusively from imported material. As of September 2026 that is the project's description of its own behaviour, and it is what you should verify against your own network traffic before trusting it with anything sensitive.

One thing worth checking that almost nobody does: the licence. GitHub's API reports NOASSERTION for this repo, which is what it says when it cannot match the file to a known template, and it is easy to read that as "unclear, probably fine". Open the LICENSE file and it is the GNU General Public License version 3, copyright Yong Su. GPL-3.0 is genuinely open source, so "free and open source" is accurate, but copyleft is not the same thing as MIT and the difference matters the moment you want to build something on top of it and ship that. Check the file, not the badge. If you are handing document work to agents inside a company, the same caution applies to the whole toolchain, which is a theme we have written about in the practical guide to automating document workflows.

Where the pattern gets argued with

Search the term and you land in an active argument rather than a settled consensus, which is a good sign for a nine-month-old idea. Elvis Saravia's post claiming LLM wikis are being slept on sits near the top of the results; so does a Medium piece arguing that Karpathy's LLM wiki should not be applied to your personal notes, and a Hacker News thread whose title amounts to "everybody is building these now".

The strongest criticism is about drift. A wiki the model maintains is a wiki that can be quietly wrong, because a synthesis you did not write is harder to audit than a passage you can go read. Lint exists for exactly this and it is the least glamorous part of the spec, which probably means it is the part that decides whether your wiki is worth anything in six months. Nobody runs a lint pass by hand on a Tuesday, either, which is an argument for keeping the whole thing on a machine that can be told to run it every week without anyone opening a laptop; that scheduled-maintenance job is a large part of why Zentor exists as a hosted computer rather than a chat window. The second criticism is simpler: for personal notes that you wrote, having a model rewrite them into its own structure destroys something about them. That objection does not apply to a pile of other people's PDFs, which is what most people are actually pointing this at. If you want a sense of what agent-assisted knowledge work looks like day to day, our notes on Claude Code recipes for knowledge workers cover the less theoretical end.

FAQ

Is LLM Wiki free and open source?

The pattern is a public gist. The desktop app nashsu/llm_wiki is open source under GPL-3.0, confirmed by reading the LICENSE file directly; GitHub's API reports NOASSERTION, which is not the same as unlicensed. GPL-3.0 carries copyleft obligations if you distribute derived work.

Can it run without sending my documents to the cloud?

The README describes fully local operation, including a local MinerU for PDF processing, configurable local model endpoints, and a mode that answers only from imported sources. That is the project's claim as of September 2026, not an independent audit. Verify before you point it at anything confidential.

What models does it support?

Models are configured per project, and chat and ingest can be routed to different ones. Custom providers with custom headers are supported, which in practice means any OpenAI-compatible endpoint, local or hosted. Optional vector search runs on LanceDB against any OpenAI-compatible embedding endpoint.

Is an LLM wiki better than RAG?

For synthesis over a curated corpus, usually. For lookups over a huge one, no. The wiki front-loads cost at ingest; retrieval defers it to query time. Pick based on which of those you have more of.

Do I need the desktop app to try the pattern?

No. The gist was written to be pasted into a coding agent, and people ran it that way for months before any GUI existed. The app buys you ingest pipelines, a graph, and a lint pass rather than the core idea.