LLM Wiki: a Claude-maintained personal wiki built on MCP and a folder of your own files
Open Source Implementation of Karpathy's LLM Wiki. Upload documents, connect your Claude account via MCP, and have it write your wiki !
At a glance
- What is it?
- LLM Wiki turns a directory of documents into a Next.js wiki that Claude writes and updates over MCP, usually on a nightly schedule. The design is opinionated about where your files live and how the app is reached, and both choices narrow who should run it.
- Who is it for?
- Adopt LLM Wiki if you already keep source documents in a folder, you use Claude Desktop, Claude Code or another MCP client, and you want the synthesis step to run on a schedule rather than on demand. Do not adopt it if you need a shared multi-user knowledge base, if you cannot run Python 3.11 and Node 20 on the machine holding the files, or if you want retrieval to stay a read-only query over a vector store.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap LLM Wiki is aimed at: notes you never compile
Most personal knowledge tools stop at capture. You clip a page, highlight a paragraph, drop a PDF into a folder, and the pile grows while the synthesis step stays manual. LLM Wiki's premise is that the synthesis step is the part worth automating, and that a language model with file access is a reasonable thing to hand it to. The README frames the output as a record of what you thought about what you read, not just what you read, because the Chrome extension captures highlights and margin comments alongside the source and those comments are visible to Claude over MCP. The project cites Andrej Karpathy's LLM Wiki gist as its inspiration and states that it puts more weight on autonomous maintenance than the original concept does. The audience is narrow on purpose: one person with a document folder and a Claude account, or an organization that wants a knowledge layer it does not have to staff. The README's own claim about organizations is blunt, that know-how generally lives in people's heads, and the project is offered as a model for that rather than a finished product for it.
What the local workspace actually does to your folder
The unit of work is a workspace, which is any folder on disk you choose. It does not have to sit inside the cloned repository, and the README recommends pointing it at the folder that already holds your documents. On first run the tool initializes the workspace, builds a local search index so the files appear in the web app and are readable by Claude, then starts the API and the Next.js frontend. The README is explicit that it never moves, modifies, or uploads your files, and that the only additions are a wiki/ folder for generated pages and a hidden .llmwiki/ index. That is a clean separation and it is the strongest argument for the design: your originals stay where they were, and everything the tool creates is in two known locations you can inspect, back up or delete. The indexing step is what makes the folder queryable, so the cost of adding a large existing archive is paid once at open time and then incrementally as the watcher notices new files. Formats listed as supported include Markdown, PDF, Word, PowerPoint, Excel and images. Word and PowerPoint extraction depends on LibreOffice being installed, and higher-quality PDF OCR depends on a MISTRAL_API_KEY. Neither is required, but the README presents them as the difference between basic and better extraction, so a folder heavy in scanned PDFs will behave differently depending on whether that key is set.
The MCP server is the whole integration surface
Claude does not reach into the app through a bespoke plugin. The project ships an MCP server, and the command ./llmwiki mcp-config prints a JSON block you paste into claude_desktop_config.json for Claude Desktop or .claude/settings.json for Claude Code. The README notes that one workspace maps to one MCP server entry, so a second folder means a second entry. That detail matters more than it looks: the mental model is not one wiki with many sources, it is one wiki per folder, and cross-referencing between two of them is not something the configuration describes. The server exposes read, write and search over the wiki, which is what allows the same client both to answer questions from your material and to author new pages. MCP compatibility is claimed for Claude.ai, Claude Cowork, Claude Code, Codex and any other MCP-compatible app, so the wiki is not locked to a single vendor's client even though the examples are Claude-centric. The instruction the README suggests giving Claude after connecting is short: read the guide, then ingest sources and start building. There is no separate ingest command to learn, which is convenient and also means the quality of the first pass depends on the model following a guide it reads at runtime rather than on a deterministic pipeline.
Getting it running: the commands and the loopback constraint
Requirements are Python 3.11 or newer and Node.js 20 or newer, with LibreOffice and MISTRAL_API_KEY optional. Installation is a clone, a virtual environment, pip install -r api/requirements.txt -r mcp/requirements.txt, and npm install inside web/. Windows users get a PowerShell variant, and the README addresses the case where activation is blocked by execution policy, suggesting Set-ExecutionPolicy -Scope CurrentUser RemoteSigned once or using .venv\Scripts\python directly. The entry point is ./llmwiki open ~/research on macOS and Linux, or python llmwiki open C:\Users\you\research on Windows, which initializes the workspace, indexes the folder, starts both services and opens localhost:3000. The constraint to plan around is stated plainly: local mode is loopback-only, the API listens on 127.0.0.1 and does not support LAN or remote binding. If you wanted to run the indexer on a home server and browse from a laptop, local mode is not the path; the README points to self-hosting the remote app instead. There is also a development-only preview flag, NEXT_PUBLIC_ONBOARDING_PREVIEW=true npm run dev, which renders the hosted onboarding flow at localhost:3000/onboarding without authentication or API writes. The README warns that the flag must be set before starting the dev server and that the preview simulates creation in memory, so it creates no wiki and changes no onboarding state. Treat it as a UI sketch, not a setup shortcut.
Claude Routines are the maintenance mechanism, and the weakest link
The self-maintaining claim rests on scheduled prompts rather than on a daemon inside the repository. The README describes two ways to schedule one: Claude Code Routines, which run on Anthropic's cloud on a fixed cadence even when your machine is closed, and a Desktop scheduled task, which runs the same prompt locally. The suggested prompt tells Claude to read the guide, find everything added since the last run including clips and highlights, then write new pages, fold material into existing ones, and repair cross-references and citations. This is where the architecture is most exposed. There is no diff review step described, no dry-run mode, and no rollback beyond whatever your own version control or backups provide for the wiki/ folder. An unattended run that misreads a source can rewrite citations across several pages before you look. The README's framing is that the wiki compounds over months, which is true only if the individual runs are trustworthy. The honest reading is that the nightly routine is a convenience feature with a real blast radius, and anyone running it against material they care about should keep the workspace under git or a snapshot schedule first. The upside is equally real: because each run is instructed to process only what changed, the incremental cost per night is proportional to new material rather than to the size of the archive.
Where the wiki format helps and where a plain RAG stack wins
The alternative most engineers will already have is a retrieval pipeline: chunk the documents, embed them, and answer questions over the vector store at query time. That approach never writes anything back. It is cheaper to operate, it cannot corrupt a page, and it handles a corpus that changes constantly without a compile step. What it does not give you is a persistent artifact. Every question starts from raw chunks, so there is no place where two sources have been reconciled into one statement, and no page you can read a year later without re-running the query. LLM Wiki inverts the timing: synthesis happens ahead of the question, into Markdown pages with citations, a table of contents, native cross-linking back to sources, a graph view of entities and relationships, and support for charts, SVGs and Mermaid diagrams. If your need is occasional lookup across a stable corpus, the vector store is the better tool and the wiki is overhead. If your need is a durable summary of a body of reading that you will revisit, the compile step is the point. The trade is maintenance for persistence, and it is a real trade rather than a strict improvement.
Licence, upgrade surface and what you are taking on
The project is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved, and it includes an explicit patent grant. That is a permissive choice with no copyleft obligation on your own code, but it says nothing about the content you put in the workspace, and it says nothing about Anthropic's terms for the Claude account and routines that do the writing. The repository has no releases listed in the supplied material, so there is no versioned upgrade path to reason about: installation is from the master branch, which means an update is a git pull plus reinstalling the two Python requirement files and the npm packages. There is no migration story documented for the wiki/ folder or the .llmwiki/ index, and no compatibility statement about whether an index built by an older checkout will be read by a newer one. The practical consequence is that you should treat the workspace as data you own and the code as something you can re-clone, keeping the two genuinely separate. The README already enforces that separation by keeping generated pages and the index out of your source folder's original files, which makes the whole thing disposable and rebuildable in principle. Whether a rebuild is actually cheap depends on how long the initial indexing of your archive takes, which the material does not quantify.
Editorial conclusion
Adopt LLM Wiki if you already keep source documents in a folder, you use Claude Desktop, Claude Code or another MCP client, and you want the synthesis step to run on a schedule rather than on demand. Do not adopt it if you need a shared multi-user knowledge base, if you cannot run Python 3.11 and Node 20 on the machine holding the files, or if you want retrieval to stay a read-only query over a vector store. Before committing, verify three things: that ./llmwiki mcp-config prints JSON your client accepts, that a single routine run produces pages you would keep, and that the wiki/ folder and the hidden .llmwiki/ index do not collide with anything already in the directory you point it at.
Community notes