nvk/llm-wiki: an LLM-compiled knowledge base that ships as an agent plugin
LLM-compiled knowledge bases for any AI agent. Parallel multi-agent research, thesis-driven investigation, source ingestion, wiki compilation, querying, and artifact generation.
At a glance
- What is it?
- llm-wiki turns research sessions with Claude Code, Codex, OpenCode or a portable agent into a compiled, Obsidian-compatible wiki, and it separates rough Ideas from explicitly promoted Projects. The design is opinionated about governance and versioning; the payoff depends on whether you want a plugin owning your notes.
- Who is it for?
- Adopt llm-wiki if you already run Claude Code or Codex daily and want research output to land in files you own rather than in a chat log; the MIT licence and the plain-markdown, Obsidian-compatible output keep the exit cost low. Do not adopt it if you need a single stable interface or you are not willing to re-read the changelog before every upgrade, because the adapter boundary, the index contract and the session hooks have all changed inside the v0.21 to v0.24 window.
- 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 received new commits within the last day.
- 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 fills between a chat session and a notes folder
Most agent research ends as a transcript. You ask a model to compare hardware wallet threat models, it answers, and the answer survives only as long as the thread. llm-wiki targets that specific loss. The README describes a flow where you capture rough Ideas, research and shape them, then explicitly promote approved briefs into delivery Projects. The word explicitly carries weight here: promotion is a deliberate step, not something the tool infers from activity.
The intended user is someone who already works inside Claude Code, OpenAI Codex, OpenCode or a portable agent and wants the research artefact to outlive the session. The output is markdown, and the project states it is Obsidian-compatible, so the wiki is readable without the plugin. The repository is Python, MIT-licensed, and the homepage is llm-wiki.net. If you keep notes in a proprietary app that cannot read a folder of markdown files, the compilation step buys you much less.
Ideas, Projects and Concepts as separate record types
The v0.18.0 release notes describe a hub-wide portfolio command, /wiki:portfolio, as a live read-only view across active topic wikis. That view lists canonical Ideas and active Projects separately, distinguishes Projects that were explicitly promoted from those created directly, and keeps Concepts as supporting knowledge. The release notes also state what the portfolio avoids: catch-all topics, duplicated records, inferred lineage, and stale portfolio caches.
That list of avoidances is the clearest statement of the project's data model in the supplied material. Records have a type, a topic, and a provenance flag for promotion. A topic is not a dumping ground, and lineage is recorded rather than guessed. The practical consequence is that you cannot silently merge two topics and expect the portfolio to reconcile them; the model would rather show two records than invent a parent. For a personal research wiki this is the right default. For a team that wants one canonical page per subject, it means someone has to do the consolidation by hand.
Research modes, thesis-driven investigation and query depths
The README's table of contents names several distinct capabilities: parallel research, collector catalogs, session memory, source ingestion, compilation, audits, querying, and artifact generation. It also lists research modes, thesis-driven research, and query depths as separate sections. The description supplied with the repository repeats the same set and adds parallel multi-agent research.
What can be confirmed is the shape of the interface rather than the internals. Commands visible in the README include @wiki research, @wiki collect, @wiki ingest, @wiki audit, @wiki session status, @wiki feedback list --unpromoted, @wiki session disable, and @wiki ll. The existence of a query-depth control and a thesis-driven mode implies that a query is not a single retrieval pass; the depth parameter changes how much work the agent does before answering. The material does not state the number of depths, the retrieval algorithm, or the cost per level, so treat depth as a knob whose price you should measure on your own corpus rather than a documented guarantee.
Installing it for Claude Code, Codex and OpenCode
Claude Code takes a native plugin install:
claude plugin install wiki@llm-wiki
Codex uses a marketplace flow. From GitHub:
codex plugin marketplace add nvk/llm-wiki codex plugin add wiki@llm-wiki
The README then instructs you to start a new Codex thread and use @wiki or type $ to select wiki-query. A local checkout can be registered with ./scripts/bootstrap-codex-plugin.sh --scope user --verify, or manually with codex plugin marketplace add /absolute/path/to/llm-wiki followed by codex plugin add wiki@llm-wiki. Upgrades run codex plugin marketplace upgrade llm-wiki and then re-add the plugin. Removal is two commands: codex plugin remove wiki@llm-wiki and codex plugin marketplace remove llm-wiki.
OpenCode is configured through opencode.json, either project-level or at ~/.config/opencode/.opencode.json. You add an instructions URL pointing at the wiki-manager SKILL.md and an external_directory permission block that allows paths such as ~/.config/llm-wiki/** and the iCloud wiki directory. A smaller read-only preset swaps in the wiki-query SKILL.md instead. The README notes OpenCode fetches the URL fresh on every session start, so there is no manual update step, and that the profile is sync- and budget-tested but not tied to one model. The troubleshooting notes are worth reading before you file a bug: the marketplace add command only registers the catalog, the plugin add command installs and enables it, and if you run Codex under a sandbox wrapper such as nono, Codex needs read and write access to $HOME/.codex for plugin install to work.
Session memory, hooks and the opt-out you should know about
The README advertises session memory and a session-hook compatibility fix in v0.21.3. The Codex instructions tell you to open /hooks to review and trust the bundled hooks if you want automated session capture, and state that the @wiki skill works without hook trust. That is a meaningful split: the skill is usable immediately, while the memory feature depends on granting hooks permission to run.
There is an opt-out command, @wiki session disable, described as optional. If your work involves material you would not want captured, the honest reading is that session capture is on by default in the sense that trusting the hooks enables it, and the disable command is how you turn it off. The v0.24.3 release is titled Privacy-Sensitive Log Retraction, which suggests the maintainers treat captured content as something that may need to be withdrawn after the fact. The material does not describe the retraction mechanism, so if that matters to you, read the release notes for that version before enabling hooks.
The adapter boundary and why the public plugin is thinner than it looks
Several recent releases are about removing capability from the public plugin rather than adding it. v0.22.0 introduces declarative private-adapter routing, where registered adapters declare provider-neutral intent and exact-URL routes plus an adapter-owned workflow guide; the public plugin discovers the route before ingestion but no longer embeds any provider's authentication, browser, recovery or editing workflow. v0.21.3 calls itself an adapter-boundary transition and says provider-specific workflow material from the v0.21 line lives only in the corresponding private adapter. v0.19.0 adds a trusted, machine-local adapter registry with a portable llm-wiki-adapter/v1 JSON contract, manifest handshakes, path scopes, sanitized environments and hash-verified artifacts. v0.20.0 extends adapters with exact remote-resource allowlists, declared read and write effects, approval bound to an exact plan hash, expected revisions and idempotency keys.
Read together, these notes say the interesting integrations are not in this repository. If you install llm-wiki expecting it to log into a site, drive a browser or write to a remote service, the public plugin will not do that; it discovers a declared route and hands off. The governance machinery is unusually specific for a personal knowledge tool: approvals bound to a plan hash, expected revisions, content-free terminal reporting. That is the vocabulary of a system that has been burned by an unattended write, and it is a reasonable thing to want. It also means the setup cost for a custom source is higher than a scraper script, because you are writing a manifest and a workflow guide, not a function.
Where llm-wiki is the wrong tool
The project is Claude-first and multi-runtime by design. The README's own architecture heading is Claude-first multi-runtime, and the install paths are three separate agent ecosystems plus a portable option. If your team standardises on a runtime that is not Claude Code, Codex or OpenCode, you are on the portable path and should expect to carry more of the integration yourself.
The second limitation is churn at the boundaries. Within roughly four weeks the release list shows an adapter CLI compatibility fix, a privacy-sensitive log retraction, a safe index contract repair, and before those, the adapter-boundary transition. A safe index contract repair implies the index has a contract that can be violated, and that a release existed to repair it. Anyone pinning to an old version and skipping the changelog is exposed to exactly that class of breakage.
The third is scope. This compiles research into a wiki. It is not a note-taking app with a plugin system bolted on, and it is not a general document store. If your need is a shared team knowledge base with access control and an editorial workflow, the Ideas-to-Projects promotion model is a personal-scale abstraction, and you will spend your time working around it rather than with it.
Obsidian as the alternative, and the real difference in approach
The obvious alternative is Obsidian itself, with a community plugin or a manual folder convention, or a plain git repository of markdown files edited by hand. The README states llm-wiki output is Obsidian-compatible, so these are not mutually exclusive: you can point Obsidian at the vault llm-wiki writes.
The difference is who does the compiling. In a hand-maintained vault, you decide what a note is called, where it lives and when two notes are the same note. In llm-wiki, an agent performs ingestion, compilation and auditing, and the record types and promotion rules constrain what it may create. That constraint is the product. It is also the cost: an agent that compiles your sources will produce structure you did not choose, and the audit command exists because that structure needs checking. If you enjoy curating a vault, the compilation step removes the part you like. If you never get around to curating, it removes the part you skip.
Upgrade cost, licence and what to verify first
The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a statement about the licence text, not legal advice; if you redistribute a modified plugin, read the file yourself or ask counsel.
Upgrade cost is the part to budget for. The documented Codex upgrade is two commands, but the changelog shows interface-level changes landing repeatedly, including an adapter CLI compatibility release and a session-hook compatibility fix. A knowledge base is long-lived by nature, so the interesting risk is not the plugin breaking; it is the compiled output drifting away from what a newer version expects to read. The v0.24.0 notes describe a Project Knowledge Checkpoints Export that writes under docs/knowledge/<slug>/ with dry-run-first create and refresh, read-only verification, bounded import, exact source and section coverage, explicit omissions and a thin-output guard, and they state that checkpoint writes never authorize commit, publication or import. That dry run is the cheapest way to test an upgrade: export a checkpoint from a topic before you move versions, then compare section coverage after. If the coverage list changes shape, you have learned something about the release that the version number did not tell you.
Editorial conclusion
Adopt llm-wiki if you already run Claude Code or Codex daily and want research output to land in files you own rather than in a chat log; the MIT licence and the plain-markdown, Obsidian-compatible output keep the exit cost low. Do not adopt it if you need a single stable interface or you are not willing to re-read the changelog before every upgrade, because the adapter boundary, the index contract and the session hooks have all changed inside the v0.21 to v0.24 window. Before committing, verify three things against your own setup: that your agent runtime installs the plugin and trusts its hooks, that the wiki directory you allow in your sandbox config is the one you actually want written to, and that the checkpoint export under docs/knowledge/<slug>/ produces the section coverage you expect on a dry run.
Community notes