OpenKB (VectifyAI)
Built by VectifyAI, the team behind PageIndex. Apache-2.0, Python,
4,246★ / 442 forks as of 2026-08-31; repository created 2026-04-04. pip install openkb.
The vanity domain openkb.ai redirects to the repository — there is no product site behind it.
An open-source CLI that compiles a directory of documents into an interlinked markdown wiki and then reads from that wiki instead of from the documents. It is, by its own first paragraph, an implementation of the llm-wiki pattern: "The idea is based on a concept described by Andrej Karpathy: LLMs generate summaries, concept pages, and cross-references, all maintained automatically. Knowledge compounds over time instead of being re-derived on every query." Its stated foil is the same one llm-wiki-gist named — "Traditional RAG rediscovers knowledge from scratch on every query. Nothing accumulates."
Tier: T1 for what the artifact is — architecture, commands, file layout, the stack it composes. It publishes no benchmark of any kind, so every evaluative word in it ("accurate," "context-aware," "scales") is an unmeasured claim by the maker; those are read as T3 and flagged below.
What it actually does
The design is a three-layer split the pattern keeps re-deriving: immutable raw/, an LLM-owned
wiki/, and a schema file the LLM obeys — here wiki/AGENTS.md, described as "the LLM's instruction
manual for maintaining the wiki," read from disk at runtime so edits take effect immediately. Spine
files are index.md and log.md. Pages carry YAML frontmatter and [[wikilinks]], so the vault opens
in obsidian for graph view.
The command set is the pattern's three operations with a fourth bolted on:
| Op | OpenKB | llm-wiki |
|---|---|---|
| Ingest | openkb add <file/dir/URL>, openkb watch (auto-compile on new files in raw/) |
Ingest |
| Query | openkb query "…" (cited answer), openkb chat (resumable sessions) |
Query |
| Lint | openkb lint — "structural and knowledge health checks" |
Lint |
| — | openkb recompile, remove, list, status |
— |
On add, the LLM generates a summary page, reads the existing concept and entity pages, updates
concepts with cross-document synthesis, updates entity pages, then updates the index and log. The
README's own estimate: "A single source might touch 10–15 wiki pages."
The uncomfortable part: this is a packaged copy of this wiki's own design
Set the two side by side and the correspondence is close to total — raw/→wiki/, index.md +
log.md as the only reserved spine files, a schema file that is the LLM's operating manual
(AGENTS.md here, CLAUDE.md in each spoke), auto-extracted entity pages for people, orgs, places
and products (this hub's ENTITIES.md), [[wikilinks]], an ingest that touches 10–15 pages, and a
lint for orphans and broken links. llm-wiki estimates "~10–15 pages touched" per ingest; the
research-wiki CLAUDE.md says "typically touches ~5–15 pages"; OpenKB says 10–15. Three sources, one
number.
But this is common ancestry, not independent arrival, and the distinction matters. The
llm-wiki page has been reading each new instance as evidence that the design is "a natural
attractor, not one author's idiosyncrasy." OpenKB cannot carry that weight: it says outright that it
is built from Karpathy's concept, and so is this hub. Two descendants of one gist
agreeing about file layout is what descent looks like. What OpenKB does add to the attractor
argument is weaker and more specific — that the design survives being packaged for strangers. A
one-author workflow can quietly depend on its author; a pip install used by 4.2k stargazers' worth
of people has to state its conventions in a file and defend them against every corpus it is pointed
at. Convergence proves nothing here; distribution proves a little.
What it adds that the pattern did not have
1. A general-purpose implementation you can install. Until now the instances this wiki holds split into workflows nobody can run (llm-wiki-gist is a gist), a private production system (gbrain), a coding-agent skill (llm-wiki-agent), and the codebase-documentation sub-genre (deepwiki, autowiki, opendeepwiki) which only eats repositories. OpenKB is the first general-purpose, installable, non-hosted one — point it at PDFs, Word, PowerPoint, Excel, CSV, HTML, markdown or URLs. That closes the sub-genre's most obvious hole: the open-source instance existed only for code.
2. Long documents as a first-class problem. Everything else in the cluster assumes the source fits
in context. OpenKB routes on length: short documents go through Microsoft's markitdown and are read
in full; PDFs of ≥20 pages (pageindex_threshold, configurable) go through pageindex, which
builds a hierarchical tree index the LLM reasons over instead of reading the text. This is a distinct
answer to a gap the retrieval-augmented-generation taxonomy here had only touched from the
chunking side (long-context-vs-chunking) — see pageindex.
3. The Skill Factory — the wiki compiled into an agent skill. openkb skill new <name> "<intent>" distils a portable skill from the compiled wiki that Claude Code, Codex and Gemini
CLI install natively; skill validate / skill eval / skill history / skill rollback come with
it. The README's pitch: "drop in a book; out comes a digital expert." This is the A↔B bridge the
synthesis has described in prose — knowledge markdown and procedural markdown as cousins — turned
into a command. It is cross-spoke context: the skill format and its distribution belong to
../agentic-tooling-wiki (agent-skills), the compilation step belongs here.
4. Generators as a named layer. The README separates "wiki foundation" (compile and maintain)
from "generators" (read the wiki, emit something): query, chat, visualize (a self-contained 3D /
mind-map / radial knowledge graph), deck new (a single-file HTML slide deck, with a --critique
quality pass), and the Skill Factory. "The wiki is the substrate; generators are the surfaces."
That framing — one compiled substrate, many disposable outputs — is the clearest statement in the
corpus of why one would pay the compile cost.
It is the first real adopter of OKF
The open-knowledge-format page has carried a standing caveat since June — "a specification, not a deployment; there's no adoption data here" — softened on 2026-08-15 by one developer borrowing the aesthetic without conforming. OpenKB lists OKF compliance as a headline feature and a Recent Update: "Wiki pages follow the Google OKF specification for knowledge sharing." That is a shipped tool with 4.2k stars claiming conformance, which is a different order of evidence from a blog post.
Two limits on how far that goes. The claim is self-asserted and unverified — nobody has checked
an OpenKB bundle against the spec, and OKF has no conformance suite to check it with (it deliberately
registers nothing). And OpenKB's own frontmatter conventions live in a user-editable AGENTS.md the
README invites you to rewrite, so conformance is a default, not a property. Adoption of a format
whose whole design principle is "producer-defined, unregistered" is hard to distinguish from
coincidence in shape.
Caveats
- No evaluation, anywhere. The sub-genre's missing number — how good is the compiled wiki? — is
still missing. wicer measured blind LLM compilation at 55.1% wrong-or-irrelevant answers on
probes drawn from the compiled sources; OpenKB compiles exactly that way and reports nothing. Its
lintchecks structure and itsskill evalchecks whether a skill triggers on the right prompts — neither asks whether the wiki is right.recompilewarns that manual edits are overwritten, so the human-correction path the pattern usually relies on is explicitly not durable. - Not independent of the vendor's other product. Long-document handling is PageIndex, and PageIndex has a paid cloud tier (PAGEINDEX_API_KEY) sold for OCR, faster structure generation and scale. The open-source local path is real and default; the funnel is also real.
- Volatile. Star counts, feature list and roadmap are a 2026-08-31 snapshot. Roadmap items still open: long-document handling beyond PDF, nested folders, hierarchical topic indexing for large corpora, a database-backed storage engine — i.e. it does not yet claim to scale to a corpus the size of gbrain's 146K pages.
- Composed almost entirely of other people's parts —
markitdown(Microsoft), OpenAI Agents SDK, LiteLLM (multi-provider, so any of OpenAI / Claude / Gemini / local), Click, watchdog. The original work is PageIndex plus the compilation prompts.
Related
llm-wiki · pageindex · vectifyai · llm-wiki-gist · andrej-karpathy · open-knowledge-format · retrieval-augmented-generation · wiki-memory · gbrain · llm-wiki-agent · opendeepwiki · wiki-compiler · wicer · obsidian · agent-skills · synthesis