Spokes.wiki Search About
Created
Updated

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 lint checks structure and its skill eval checks whether a skill triggers on the right prompts — neither asks whether the wiki is right. recompile warns 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.

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