obsidian-llm-wiki: a Karpathy LLM Wiki plugin that skips the vector database

The problem: notes that never become a knowledge base

Most people accumulate Obsidian vaults faster than they connect them. Folders grow, links stay sparse, and the answer to "what do I already know about this?" depends on remembering a thread from months ago. The plugin's own framing of the problem is blunt: "You write notes. They sit in folders. Finding what relates to what means remembering threads you forgot months ago."

The project targets a specific reader. Someone who writes in Obsidian, has a vault with real content in it, and wants generated entity pages and concept pages rather than a chat window bolted onto a folder. It is a plugin, not a service, and the README positions it against other open-source reimplementations of Karpathy's LLM Wiki idea by noting that most of those are CLI tools or agent skills rather than a one-click plugin.

That placement matters for adoption. The value is not the language model. It is that generation happens inside the editor where the notes already live, so the output lands as markdown files in the vault rather than in a separate application's database.

Graph retrieval instead of a vector store

The architecture is the interesting part. There are no embeddings and no vector database. Retrieval runs on the link graph itself using Personalized PageRank, with the README citing Haveliwala 2002 for the algorithm and Fogaras 2005 for a Monte Carlo variant. A five-stage seed-selection cascade picks the starting nodes, and Tier 1 and Tier 2 duplicate detection keeps generated pages from piling up on top of each other.

The trade-off is explicit. Graph retrieval only works when there is a graph, so a vault of unlinked notes gives the ranking nothing to walk. Embedding-based retrieval would still find semantic neighbours in that situation. In exchange, you avoid an embedding model, an index rebuild step, and a vector store to keep in sync with your files.

The README publishes one number for this: PPR @5 = 27.1% against pure kNN at 24.1% on the project's own corpus, described as the only published number in this open-source LLM-wiki space. Treat it as a single internal measurement on one corpus, not a general result. The margin is small enough that the practical argument for this design is operational simplicity, not retrieval quality.

Generation itself is multi-page. The plugin produces entity pages and concept pages, and source pages can carry verbatim quotes from the pages they were built from. A rewrite guard is mentioned in the 1.27.1 release notes as "sourced-paragraph rewrite guard", which suggests the project has already hit the failure mode where a model paraphrases a source and loses the original wording.

Installing the plugin and running a first ingest

The README lists two install paths: the Obsidian community marketplace under the plugin id karpathywiki, and the repository. The runtime requirement is Obsidian 1.11.4 or newer, desktop and mobile. There are no runtime dependencies to install by hand; the Vercel AI SDK v6 is bundled.

If you build from source, the package manager is pinned and Node 22 is the floor:

pnpm install
pnpm build

The build script runs esbuild in production mode and emits main.js, which is what Obsidian loads alongside manifest.json and styles.css. The repository also defines a single verification target that chains lint, typecheck, build, test and CSS lint:

pnpm gate:1

It is worth knowing about because the project's own release notes for 1.27.1 mention 3993 tests, and this is the target that exercises them.

After enabling the plugin, the first real use is an ingest run over a folder. You pick a provider and a model in the settings, point the plugin at notes or a PDF, and let it generate pages. The README describes an ingest candidate gate, which means the plugin proposes what to ingest before writing it. Do the first run on a copy of the vault. Nothing in the README documents a rollback for generated pages, so the safe assumption is that you undo by deleting files yourself.

Providers, local models, and what local-first actually covers

The plugin supports 16 or more LLM providers according to the README: Anthropic, OpenAI, Bedrock with both API key and SSO/IAM paths, Gemini, DeepSeek, Qwen, Grok, Kimi, GLM, MiniMax, Step, Hunyuan, MiMo, Gemma, Ollama, LM Studio, OpenRouter, an Anthropic-compatible endpoint, and Codex OAuth. That is a wide net, and it is the main reason the plugin is not tied to one vendor's account.

Local-first here means the plugin has no backend of its own. The README states there is no backend and calls it GDPR-friendly. That claim covers the plugin's own infrastructure, not your inference. If you point it at Anthropic or OpenAI, note text leaves the machine. If you point it at Ollama or LM Studio, it does not. The setting is yours to make, and the README does not pretend otherwise.

Bedrock support is the unusual entry. SSO and IAM credentials are not typical in an Obsidian plugin, and they exist because the target user is often someone with a corporate AWS account. Codex OAuth is there for the same reason on the OpenAI side.

The user interface ships in 11 languages, and the README notes that wiki output language is independent of interface language. That distinction is easy to miss and matters if you write in one language and want generated pages in another.

Where the plugin is the wrong tool

Three cases stand out.

First, a vault with no links. Personalized PageRank needs edges. If your notes are a flat pile of files, the five-stage seed cascade has almost nothing to rank against, and you would be better served by a chunk-based retrieval tool that indexes text rather than structure. The README itself lists atomicstrata/llm-wiki-compiler as a chunk-based TypeScript CLI, which is the honest alternative for that shape of vault.

Second, headless and automated pipelines. This is an Obsidian plugin, so it runs where Obsidian runs. The project maintains a separate CLI repository, obsidian-llm-wiki-cli, and the README links it under a Headless CLI heading. If your goal is a cron job over a notes directory, the plugin is the wrong entry point and the CLI is the right one.

Third, anyone expecting the plugin to be a chat interface over a folder. The output is generated markdown pages that live in the vault. Query is conversational, but the artifact is a wiki, and a wiki needs maintenance. Duplicate detection and the lint health scan exist precisely because that maintenance does not disappear.

Maintenance cost, licence, and release cadence

The last push to the default branch was on 2026-09-10, and the most recent release is 1.27.1 from 2026-09-06. The 1.27.1 notes describe 46 commits since 1.27.0, covering deterministic related lists, the sourced-paragraph rewrite guard, vault-wide link repoint, a stream-path thinking policy, local-date stamps, contradiction gates and deterministic shaping. That is a lot of behavioural change in a patch release, and it tells you the project is still settling its generation semantics rather than only fixing bugs.

For an operator, that cadence has a cost. Vault-wide link repoint means the plugin can rewrite links across the vault, so a version bump is not a cosmetic event. The lint health scan and Smart Fix All features exist to repair drift, but they also mean you should read the changelog before upgrading rather than after.

The licence is Apache-2.0, which permits commercial use and modification and requires that you keep the licence and notice files. The repository carries a NOTICE file, which is standard for Apache-2.0 and worth preserving if you redistribute a build. This is a description of the licence terms, not legal advice; if you are embedding the plugin in a product, have someone qualified read the terms.

One more cost item: model spend. The plugin has no metering of its own, and generation is multi-page, so a large ingest run against a hosted provider is billed by that provider. Local models through Ollama or LM Studio remove the per-token cost and move it to your hardware instead.

Editorial conclusion

Adopt it if you already live in Obsidian, want entity and concept pages generated from notes you have already written, and are willing to configure a provider key and watch the ingest gate rather than trust automatic writes. Do not adopt it if you need a headless pipeline that runs outside the editor, or if your notes carry no links for the graph to traverse. Before committing, verify the plugin version against manifest.json, confirm your chosen provider appears in the model settings, and run one small folder through ingest on a copy of the vault so you can see what the candidate gate accepts.

Frequently asked questions

Official sources

1. GD4AI/obsidian-llm-wiki on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases