obsidian-llm-wiki: A Local LLM Compiler for Markdown Vaults, Now in Maintenance Mode
Karpathy’s LLM Wiki, 100% local with Ollama. Drop Markdown notes → AI extracts concepts → your Obsidian wiki auto-links and grows. Zero sharing. Your notes stay yours.
At a glance
- What is it?
- obsidian-llm-wiki turns a folder of raw Markdown notes into an interlinked Obsidian wiki using a local Ollama model, with incremental recompiles, rejection feedback and hand-edit protection. It is a useful implementation of Karpathy's LLM Wiki pattern, but the README now points new work at a successor project called Synto.
- Who is it for?
- Adopt obsidian-llm-wiki if you already keep notes in Markdown, want the compilation to happen on your own machine through Ollama, and accept that the README declares the project to be in maintenance mode with bug fixes only. Do not adopt it if you need a roadmap, new features, or a pipeline that does not assume an Obsidian vault.
- Can I use it commercially?
- Yes. MIT 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 113 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 problem: notes as a pile, not a wiki
Most note-taking tools store what you write and stop there. The linking, the cross-referencing and the naming of concepts is left to you, and it decays as the vault grows. This project takes the opposite position. The README quotes Karpathy's pattern directly: the LLM "doesn't just store what you tell it, it synthesizes, cross-references, and keeps everything current." Raw notes are treated as source material, not as the finished artifact.
The audience is narrow and specific. You need to already keep notes as Markdown files, you need Obsidian to view the result, and you need to be willing to run a model locally. If any of those three is false, the tool's main selling point (the wiki lives in Obsidian, so graph view, backlinks and Dataview queries come for free) does not apply to you. The README frames the output as a wiki that "persists and compounds," in contrast to a chatbot that forgets. That framing is the whole pitch, and it is a reasonable one for anyone who has watched a chat history become useless after a few weeks.
How the compile pipeline actually flows
The data flow is a two-stage separation between raw input and generated output. You write files into a raw/ folder. The pipeline reads each one, extracts concepts, and creates or updates articles under wiki/. The README's diagram shows the same concept, "Qubit", appearing in two different source notes and resolving to a single article, with the articles linked to each other through [[wikilinks]]. That deduplication at the concept level is the mechanism that makes the wiki feel like a wiki rather than a per-note summary.
Two details in the README matter more than the diagram. First, compiles are incremental: when you change a source note, only the articles tied to that note recompile. The README does not describe the bookkeeping structure that records which article came from which note, so the granularity of that dependency tracking is not something I can confirm from the material. Second, the tool is git-aware. Every automatic action commits with an [olw] prefix, olw undo reverts the last one, and the README states that raw notes are never modified because olw only writes to wiki/ and .olw/. That write boundary is the most concrete safety property in the documentation and it is the reason the tool is tolerable to run against a vault you care about.
Language handling is described as detection at ingest, with the article written in the detected language. The README claims extraction rules do not depend on hard-coded word lists. I have not verified that claim, and it is the kind of statement that is easy to write and hard to prove; treat it as a design intent rather than a tested guarantee.
Running it: install, models, and the olw commands that matter
Installation is a single package. The README recommends pip install obsidian-llm-wiki, or uv tool install obsidian-llm-wiki if you use uv. A source install goes through git clone followed by python install.py, which the README says detects uv or falls back to pip, verifies the install, and prints the next step.
The model side is Ollama. The README's example pulls two models: gemma4:e4b described as the fast model for analysis and routing, and qwen2.5:14b described as the heavy model for article writing, with a note that 7B or larger is recommended. It also gives a minimal path: pull only gemma4:e4b and set both the fast and heavy slots to it in the wizard. That two-model split is the main tuning surface. Routing and analysis are cheap; prose generation is not.
Configuration runs through olw setup, an interactive wizard that the README says takes about 30 seconds and selects a provider, configures the URL and an optional API key, picks the fast and heavy models, sets an optional default vault, and offers experimental features. The config file is wiki.toml, which is what olw compare is designed to keep you from editing blind: the README says it previews a provider switch in isolated vaults so you can decide before touching wiki.toml.
Beyond setup, the commands the README names are olw watch for the file watcher, olw query for answering from the published wiki, olw lint for reporting orphans and stale articles, olw maintain --fix for rewriting alias links and creating stubs for missing targets, and olw undo for reverting the last [olw] commit. The default local path is Ollama; the README also lists Groq, Together AI, LM Studio, vLLM, Azure OpenAI and any OpenAI-compatible endpoint as options.
Rejection feedback and the five-strike block
The feature I would single out is the review loop. When a draft is wrong you reject it and attach a reason, and the README states that the next compile of that concept includes your feedback in the prompt. This is a different design from a regenerate button. The correction is stored and reused, which means the model's output is steerable without editing prompts by hand.
The guardrail is blunt: five rejections without an approval auto-block the concept until you re-enable it. That number is arbitrary but the failure mode it prevents is real. A concept the model keeps getting wrong will otherwise burn compute on every compile cycle forever. Blocking it forces a human decision instead of an infinite retry loop.
The same protection applies to your own edits. If you edit an article in Obsidian, the README says the compiler detects the change on the next run and skips it, so regeneration does not overwrite you. This is the correct default, and it also means the wiki can drift away from what the model would produce. Once you hand-edit an article, the pipeline effectively stops maintaining it. That is a trade-off the README presents as a feature, and for a personal knowledge base it probably is one.
Where it breaks down, and when it is the wrong tool
The largest limitation is stated by the project itself. The README carries a note that obsidian-llm-wiki is now in maintenance mode, that bug fixes will continue, and that new features are being developed in a successor called Synto. For anyone choosing a tool today, that changes the calculation. You are adopting something the author has stopped extending. The README does offer a migration path: Synto's migration command points at an existing vault and converts the project to Synto's format, with the README stating that notes and wiki content remain the source of truth. Whether that conversion is lossless is not something the material establishes.
The second constraint is hardware. The README recommends a 7B or larger model for article writing. That is not a small requirement for a laptop, and the README gives no throughput figures, no memory guidance and no statement about how long a compile of a large vault takes. If you have hundreds of notes, the first full compile is an unknown quantity from the documentation alone.
Third, the architecture assumes Obsidian. The wikilink format, the vault concept and the graph view are all load-bearing. If you use a different Markdown editor, you can still run the CLI, but the payoff the README advertises (backlinks, Dataview queries, graph view) is gone. The query path is also deliberately not RAG: olw query answers from your published wiki without embeddings or a vector database. That removes an entire class of infrastructure, and it also means retrieval quality depends on how well the wiki itself was compiled. Garbage articles produce garbage answers.
The alternative it defines itself against
The README positions the tool as a "rag-alternative" and a "rag-local" entry in its topic list, so the comparison is explicit even if no competitor is named. The difference in approach is structural. A conventional retrieval system chunks your documents, embeds the chunks, stores the vectors, and at query time retrieves passages for a model to read. Nothing is written back. The corpus is static and the index is derived.
obsidian-llm-wiki inverts that. Compilation happens ahead of query time, and its output is durable, human-readable Markdown that you can edit, link and version in git. The query step then reads from that compiled layer rather than from embeddings. The practical consequences cut both ways. You get an artifact you can inspect and correct, and you get incremental recompiles instead of a full reindex. You also get a compile step that costs model time up front, a wiki that can contain the model's mistakes as permanent pages, and no vector search to fall back on when the compiled article is thin. If your corpus is large and mostly reference material you never intend to edit, a plain embedding index is less machinery for the same retrieval job.
Maintenance, licence and what to check before committing
The licence is MIT. That permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are preserved. I am not a lawyer and this is not legal advice, but the practical implication for a personal vault tool is that MIT imposes almost nothing on you. The relevant risk is not the licence, it is the maintenance posture.
The README states that bug fixes will continue and that new features are going to Synto. Release history is consistent with a project that shipped steadily through v0.8.x before the maintenance notice. Nothing in the material says when support ends or whether the maintenance window has a defined length, so treat the current behaviour as the behaviour you are buying. If a bug affects your workflow, the README's promise of continued bug fixes is the only remedy named.
The upgrade cost is the migration itself. Synto's migration command is described as converting an existing project to Synto's format, and the README says your notes and wiki content remain the source of truth, which suggests the conversion is a reformatting rather than a rewrite. What it does not say is whether hand-edited articles, rejection feedback history and blocked concepts survive the move. Those are the pieces of state most likely to be project-specific, and they are the pieces I would check first by running the migration against a copy of the vault rather than the original.
Editorial conclusion
Adopt obsidian-llm-wiki if you already keep notes in Markdown, want the compilation to happen on your own machine through Ollama, and accept that the README declares the project to be in maintenance mode with bug fixes only. Do not adopt it if you need a roadmap, new features, or a pipeline that does not assume an Obsidian vault. Before installing, verify two things: that your hardware can run the models you intend to pull, since the README suggests a 7B or larger model for article writing, and whether Synto's migration command already covers your vault, because the README says that command converts an existing vault into Synto's format and that your notes and wiki content remain the source of truth.
Community notes