LLM Wiki: a desktop app that compiles your documents into a maintained wiki instead of re-answering from scratch
LLM Wiki is a cross-platform desktop application that turns your documents into an organized, interlinked knowledge base — automatically. Instead of traditional RAG (retrieve-and-answer from scratch every time), the LLM incrementally builds and maintains a persistent wiki from your sources。
At a glance
- What is it?
- LLM Wiki is a TypeScript desktop application that implements Karpathy's llm-wiki pattern: an LLM ingests your sources once and writes persistent, interlinked wiki pages with index.md and log.md, rather than retrieving passages at query time. The core judgement: the persistent-wiki model is the interesting part, but the licence is unresolved and the project is a single-maintainer desktop app, so verify the licence file and the release cadence before you commit a document corpus to it.
- Who is it for?
- Adopt LLM Wiki if you want a local, Obsidian-compatible vault that an LLM maintains incrementally, and you are willing to run a desktop app that talks to your own model endpoints.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 22 days ago.
- What is it written in?
- Mainly TypeScript, 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 problem LLM Wiki takes on: retrieval that forgets everything between questions
A conventional RAG pipeline answers each question by retrieving chunks and generating a reply from them. The README frames the alternative directly: instead of traditional RAG, the LLM incrementally builds and maintains a persistent wiki from your sources, with knowledge compiled once and kept current rather than re-derived on every query. That distinction matters for a specific kind of user. If you ask the same question across two sessions, a retrieval pipeline reconstructs the answer twice and the two answers can disagree. A wiki that has been written to disk does not have that failure mode, because the synthesized page is the artifact, not the transcript.
The intended user is someone with a personal document corpus (papers, EPUBs, PDFs, web clips, office files) who wants a durable, browsable structure rather than a chat window. The README lists scenario templates for Research, Reading, Personal Growth, Business and General, each pre-configuring purpose.md and schema.md. That is a strong hint about the audience: individuals and small teams, not a multi-tenant service. The project is explicitly based on Karpathy's llm-wiki.md gist, and the README calls the original an abstract design pattern and this project a concrete implementation with substantial extensions.
Three layers, three operations, and the files that hold the state
The architecture the README describes is three-layer: Raw Sources, which are immutable; Wiki, which is LLM-generated; and Schema, which holds rules and configuration. Three operations run against those layers: Ingest, Query and Lint. Two files carry the state. index.md is the content catalog and the LLM's navigation entry point. log.md is a chronological operation record in a parseable format.
Ingest is a two-step chain-of-thought process. The README says the LLM analyzes first, then generates wiki pages, with source traceability and an incremental cache. That sequencing is the mechanism that separates this from a single-shot summarizer: the analysis pass decides where a document belongs before any page text is written. Pages carry YAML frontmatter and cross-reference each other with [[wikilink]] syntax, and the wiki directory is stated to work as an Obsidian vault. Because the output is a folder of Markdown, the knowledge base is inspectable without the application running.
Retrieval on top of that structure is layered. There is a four-signal relevance model combining direct links, source overlap, Adamic-Adar and type affinity, plus Louvain community detection for cluster discovery with cohesion scoring. Vector semantic search is optional and runs through LanceDB against any OpenAI-compatible endpoint. The README also documents a Read Sources Only mode that restricts answers to original imported material, which is the setting to reach for when you do not trust a synthesized page.
Getting it running: what the README actually specifies
The README's installation section is the place to start, and it is the section I would treat with the most caution. The supplied material includes the section anchors (What is this?, Features, Tech Stack, Installation, Credits, License) but not the installation body text, so no install command can be quoted here without inventing it. What is confirmed is the shape of the setup work: the application is a cross-platform desktop app written in TypeScript, and it needs model configuration before it can do anything useful.
Model configuration is per project, and the README states that Chat and Ingest can be routed independently. That split is practical, not cosmetic. Ingest is the expensive path (analysis plus page generation, and optionally vision captions for images extracted from PDFs), while Chat is interactive. Pointing Ingest at a cheaper model and Chat at a stronger one is the obvious configuration, and the README says custom providers, custom headers and streaming output are supported. PDF handling has three modes: built-in, cloud, or local MinerU. Embedding search is optional and needs an OpenAI-compatible endpoint plus LanceDB.
Two integration surfaces ship with the app. There is a local HTTP JSON API on 127.0.0.1:19828 and a bundled MCP server, described as supporting hybrid search, file read, graph traversal and source rescan. A separate repository, llm_wiki_skill, is installable into Claude Code or Codex with npx skills add. The README also mentions a Chrome web clipper for one-click capture and auto-ingest. Note the loopback address: this is a local-only API by design, and the README does not describe authentication for it.
Where the design pushes back: serial ingest, a single maintainer, and the licence
The ingest queue is persistent and serial. The README lists crash recovery, cancel, retry and progress visualization, and it lists serial processing as a feature. It is a constraint as much as a feature. If you import a few thousand PDFs, the queue drains one item at a time, and each item involves at least one analysis call and one generation call against a model endpoint. The activity panel exists precisely because this takes a while. There is no documented parallel ingest path in the material, so plan your initial import as a background job measured in hours, not minutes.
The second limitation is the licence. The repository metadata reports NOASSERTION, which means no standard licence identifier was detected. The README has a License section, but its text is not in the supplied material. Treat that as unresolved rather than permissive: read the LICENSE file in the repository before you build anything commercial on top of it. This is not legal advice, it is a statement about what the material does and does not tell you.
The third is maintenance shape. The project is created and maintained by one person, nash_su, and the release cadence in the supplied data is roughly weekly across v0.6.9, v0.6.10 and v0.6.11. Frequent single-maintainer releases mean the README can drift from the code. The README is already long and describes a wide surface (graph insights, deep research, agent skills, Mermaid rendering, review system, web clipper). Verify each feature you depend on against the actual release you install, not against the README's feature list.
When a plain RAG pipeline is the better tool
The clearest alternative is a standard retrieval pipeline over the same documents, and the difference is where synthesis happens. In a RAG pipeline, synthesis happens at query time: you embed chunks, retrieve the top matches, and the model writes an answer that exists only in that response. In LLM Wiki, synthesis happens at ingest time and is written to disk as Markdown pages that persist and get cross-linked. The trade is real in both directions. RAG handles a corpus that changes every hour without any rebuild cost, and it never produces a stale synthesized page that contradicts a newer source. LLM Wiki pays an upfront ingest cost per document and then answers cheaply, but a bad ingest produces a bad page that stays in the wiki until something rewrites it.
That is why the Lint operation and the async review system exist. The README describes the review system as LLM-flagged items for human judgment with predefined actions and pre-generated search queries, and it describes graph insights as surfacing surprising connections and knowledge gaps with one-click Deep Research. These are the mechanisms for correcting the wiki over time. If you are not willing to run that review loop, the persistent wiki degrades into an accumulation of unreviewed pages, which is worse than stateless retrieval because the errors look authoritative.
A second, narrower alternative is to use the wiki output without the application. Since the wiki directory is stated to be Obsidian-compatible, you could point Obsidian at it and treat LLM Wiki purely as a generator. That works only if you accept the app as the ingest front end.
Upgrade and maintenance cost, and what the licence question blocks
On maintenance, the material supports a few concrete observations. Releases land frequently, and the README documents a project export and import feature for moving complete project archives across devices, plus a rebuild-the-Wiki-index-from-existing-pages path. Those two features are what make upgrading survivable: if a schema or page-format change lands between versions, you have a documented way to move a project and a documented way to regenerate the index from pages you already have. The README does not describe a migration script or a versioned schema, so the rebuild path is the fallback to plan around.
The other recurring cost is model spend. Ingest runs analysis and generation per document, image ingestion adds vision calls for captions, and Deep Research adds multi-query web search through Tavily, SerpApi or SearXNG plus auto-ingest of the results. Optional embedding search adds an embedding endpoint and a LanceDB store. None of these are priced in the README, and I will not guess at numbers. What you can control is routing: per-project model configuration with separate Chat and Ingest routes is the lever for keeping ingest costs down.
On licence, the honest position is that the material does not resolve it. NOASSERTION in repository metadata is a signal to open the LICENSE file, not a signal that the project is unlicensed. If you need a permissively licensed component to embed in a product, this is a blocker until you read that file. If you are running it locally as an end user tool, the practical exposure is different, but the file is still the thing to read.
Who should install it, and the three checks to run first
Install it if you have a personal corpus you keep returning to and you want a durable, browsable structure rather than a chat history. The three-column layout, the Obsidian-compatible output folder, the persistent queue and the review system all point at that use case, and the exit cost is low because the artifact is plain Markdown with frontmatter and wikilinks. If you later stop using the app, the wiki directory still opens in any editor.
Do not install it if you need a headless service, a permissively licensed library, or a pipeline that keeps up with a corpus that changes continuously. The local API binds to 127.0.0.1:19828 and the MCP server is described as bundled with the desktop application, so neither is presented as a standalone deployment target. And the serial ingest queue means a continuously changing corpus will keep the queue busy.
Before committing, run three checks. Open the LICENSE file and read it, because NOASSERTION is not an answer. Diff the README's feature list against the release notes for the version you install, since a long README on a weekly release cadence drifts. And confirm your PDF path: built-in, cloud, or local MinerU is a choice you make before the first large import, and the README presents them as alternatives rather than a single default.
Editorial conclusion
Adopt LLM Wiki if you want a local, Obsidian-compatible vault that an LLM maintains incrementally, and you are willing to run a desktop app that talks to your own model endpoints. Do not adopt it if you need a permissively licensed component you can embed, or if you expect it to be a headless server: the licence is reported as NOASSERTION, which means you must read the LICENSE file in the repository before any redistribution decision, and the MCP server and local API are described as bundled with the desktop application rather than as a standalone service. Verify three things first: the actual licence text, whether the v0.6.x release line still matches the README's feature list (the README is long and the releases are frequent), and whether your ingest volumes fit the persistent queue's serial processing model. If those three check out, the wiki directory it produces is a plain folder of Markdown with YAML frontmatter and [[wikilink]] syntax, so the exit cost is low.
Community notes