obsidian-llm-wiki: Karpathy's LLM Wiki pattern running against local Ollama

The problem: notes that accumulate but never compile

A folder of Markdown files is a pile, not a knowledge base. The same idea gets written three times under three names, links point at pages that were renamed, and nothing tells you which notes have gone stale. Retrieval-augmented setups answer questions over that pile but leave it a pile; the answer disappears into a chat log.

The README frames the project as a practical implementation of Andrej Karpathy's LLM Wiki pattern, quoting the idea that the model "doesn't just store what you tell it, it synthesizes, cross-references, and keeps everything current." The design consequence is that your raw notes are treated as source material and the wiki is the compiled artifact. Concepts get their own articles, articles link to each other with wikilinks, and the result opens in Obsidian so graph view, backlinks and Dataview work without extra tooling.

It is aimed at one person with one vault. The pyproject classifier says "Intended Audience :: End Users/Desktop" and the CLI writes only to wiki/ and .olw/, leaving raw notes untouched. There is no server component and no multi-user story in the README.

Ingest, extract, compile: the pipeline behind olw

The flow is a three-stage loop. You drop a Markdown file into raw/. The pipeline reads it, extracts concepts, and creates or updates articles under wiki/. The README's own diagram shows quantum.md yielding "Qubit" and "Superposition", ml-basics.md yielding "Neural Network" and "SGD", and physics.md yielding "Qubit" again, at which point the existing article is updated rather than duplicated.

Two model roles are configured separately: a fast model for analysis and routing, and a heavy model for article writing. The README suggests gemma4:e4b for the first and qwen2.5:14b for the second, with 7B or larger recommended for writing, and notes that a minimal setup can point both roles at gemma4:e4b.

Compiles are incremental. Changing a source note recompiles only the articles tied to that note. Language is detected per note at ingest, and the README states extraction rules do not depend on hard-coded word lists, so articles come out in the language of the source. Querying runs over the published wiki without embeddings or a vector database, which is the sharpest architectural difference from a RAG stack: there is no index to rebuild and no embedding model to keep in sync.

Installing obsidian-llm-wiki and running a first compile

The README recommends PyPI. Either pip or uv works, and both expose the same two entry points, olw and obsidian-llm-wiki, declared under [project.scripts].

pip install obsidian-llm-wiki

If you prefer an isolated tool install, the README gives the uv form. There is also a source path: clone the repository and run python install.py, which the README says detects uv or falls back to pip, verifies the install, and prints the next step.

uv tool install obsidian-llm-wiki

Next, Ollama. Install it from the download page, then pull the models. The tags matter because the setup wizard asks for them by name.

ollama pull gemma4:e4b
ollama pull qwen2.5:14b

Now run the wizard. It 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 README estimates about 30 seconds.

olw setup

For continuous operation, the watcher is the intended entry point: run it once and anything dropped into raw/ is processed automatically, with ingest and compile happening in the background. The README does not print the expected console output for olw watch, so treat the first run as something to observe rather than to script against.

Rejection feedback is the part worth understanding before you adopt

Most note-to-wiki tools give you one lever: regenerate. This one adds a review loop. When a draft is wrong you reject it and attach a reason, and the next compile of that concept includes your feedback in the prompt. The README states that five rejections without an approval auto-block the concept until you re-enable it. That threshold is a blunt instrument: a concept you are actively arguing with will silently stop compiling, and the README does not describe a notification when it happens.

The other half of the loop is hand-edit protection. Edit an article in Obsidian and the compiler detects the change on the next run and skips it, so regeneration does not overwrite your work. This is the right default for a personal vault, but it means the wiki can drift from its sources: a hand-edited article is no longer a pure function of the notes that produced it, and nothing in the README reconciles the two later.

Self-maintenance runs alongside this. Aliases such as PC for Program Counter are extracted at ingest and used to repair broken wikilinks. olw lint reports orphans and stale articles, and olw maintain --fix rewrites alias links and creates stubs for missing targets. Stub creation is a design choice worth noticing: it keeps the graph connected at the cost of pages that contain a link target and little else.

Git as the safety net, and where the README goes quiet

Every automatic action commits with an [olw] prefix, and olw undo reverts the last one. Because the tool only writes to wiki/ and .olw/, a bad compile is recoverable without touching your notes. That is a stronger guarantee than most LLM writing tools offer, and it is the reason the git-aware design is worth the commit noise.

The limits are real. olw undo reverts the last action, not a range of them, and the README does not document rollback of a batch. The README also does not document what happens when two source notes disagree about the same concept, or how conflicts between a hand-edited article and a fresh compile are surfaced. And there is no web interface: this is a CLI plus Obsidian, so anyone expecting a browser UI is looking at the wrong project.

The larger caveat is upstream. 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 Synto, described as the successor with a broader scope. The last push to this repository was on 2026-05-26, and the most recent release listed is v0.8.5 from 2026-05-17. The README says migration is handled by Synto's migration command, which points at an existing vault and converts the project to Synto's format, and that notes and wiki content remain the source of truth.

obsidian-llm-wiki versus a RAG stack over the same vault

The obvious alternative for a personal vault is a retrieval pipeline: chunk the notes, embed them, store the vectors, and let a chat model answer with retrieved context. The difference is what persists. A RAG stack produces answers and discards them; this project produces articles and keeps them, with source hashes and the same hand-edit protection when you use olw query --synthesize to save an answer as a permanent page.

That shifts the failure mode. Retrieval fails by returning the wrong chunk and you notice immediately. Compilation fails by writing a plausible article that quietly misstates a concept, and you notice when you read the wiki, which may be weeks later. The rejection loop exists precisely because of that asymmetry, and it only works if you actually review drafts.

The second alternative is simply doing the bookkeeping by hand in Obsidian. That has no model dependency and no maintenance-mode clock, and for a vault of a few dozen notes it is probably the better answer. The pipeline earns its place when the notes outgrow your willingness to maintain links and aliases manually.

Licence, upgrade cost and what maintenance mode means here

The project is MIT licensed, with the licence declared both in the repository's LICENSE file and in pyproject.toml. MIT is permissive: you can use, modify and redistribute it, including in closed products. This is not legal advice, and if the licence matters to your organisation, read the LICENSE file itself rather than the classifier.

Upgrade cost is low in the short term and open-ended in the long term. Runtime dependencies are ordinary and few: click, rich, pydantic, pyyaml, httpx, watchdog and python-frontmatter, with Python 3.11 or newer required. There is no database, no server and no embedding model to keep in step, so a working install does not rot quickly. Bug fixes are stated to continue.

The long-term cost is the successor. New features are being developed in Synto, and the README describes a migration command that converts an existing vault to Synto's format. That means the upgrade path exists and is documented, but it also means feature requests against this repository have somewhere else to go. If you build workflows on olw, the questions to settle early are whether Synto's format accepts what you produce and whether the migration is one-way.

Editorial conclusion

Adopt it if you already write Markdown notes in Obsidian, want an Ollama-only pipeline with no embeddings or vector database, and accept that the README declares maintenance mode with Synto as the successor. Do not adopt it if you need new features, a web UI, or a stable long-term surface for a team. Before committing, verify two things yourself: that your Ollama models are pulled under the exact tags the wizard expects, and that olw undo actually reverts an [olw] commit in a copy of your vault.

Frequently asked questions

Official sources

1. Issues
2. kytmanov/obsidian-llm-wiki-local on GitHub
3. License: MIT
4. README
5. Releases