OpenKB: A Wiki-Style Knowledge Base That Compiles Documents Once Instead of Re-Retrieving Them

The Problem: RAG That Forgets Everything

Traditional retrieval-augmented generation treats every query as a fresh start. Each question triggers a search over raw documents, and the LLM re-derives answers from scratch. Nothing is saved. OpenKB attacks this by compiling documents once into a structured wiki, complete with summaries, concept pages, entity pages, and cross-links. The wiki persists, so later queries draw on accumulated knowledge rather than re-reading the source. This is aimed at engineers and knowledge workers who manage large document collections, such as research papers, internal reports, or product documentation, and who want to ask questions across that corpus without rebuilding context each time. The README credits a concept by Andrej Karpathy: LLMs generate summaries and cross-references automatically, and knowledge compounds over time. That is the core value proposition, and it is a real shift from the stateless RAG pattern.

Two-Layer Architecture: Wiki Foundation and Generators

OpenKB separates the work into two layers. The first is the wiki foundation, which compiles and maintains your knowledge. The second is a set of generators: query, chat, and Skill Factory, which turn the wiki into output. The wiki foundation ingests raw documents through a conversion step. Short documents are converted to Markdown using markitdown, and images are extracted inline with pymupdf. The LLM then reads the full text. Long PDFs, defined as 20 pages or more, take a different path: PageIndex builds a tree index and summaries, and the LLM reads those document trees rather than the raw text. This is a deliberate trade-off. Reading a full long document would exceed context windows or cost too much, so the tree index compresses the document into a structured form that preserves context. The result for both paths is a summary plus concept pages. The wiki is stored as plain Markdown files with cross-links, which means it opens in Obsidian for graph view. The compiled wiki is not a static artifact. The README states that entity pages for people, orgs, places, and products are auto-extracted and kept in sync. That implies a maintenance process, though the exact mechanism for updating pages when new documents arrive is not detailed in the material.

Getting It Running: Commands and Configuration

Installation is a standard pip command: pip install openkb. You can also install the latest from GitHub with pip install git+https://github.com/VectifyAI/OpenKB.git, or clone and do an editable install for development. The workflow is straightforward. Create a directory, run openkb init, then add documents with openkb add, which accepts a file path, a directory, or a URL. For example, openkb add paper.pdf or openkb add https://arxiv.org/pdf/2509.11420. After adding documents, you ask questions with openkb query "What are the main findings?" or start an interactive session with openkb chat. There are optional generators: openkb skill new my-expert "..." creates a portable agent skill, openkb visualize produces an interactive knowledge graph, and openkb deck new my-deck "..." generates a single-file HTML slide deck. Configuration lives in .openkb/config.yaml. You set the model using the LiteLLM provider/model format, such as anthropic/claude-sonnet-4-6. OpenAI models can omit the prefix, so gpt-5.4 works. API keys go in a .env file as LLM_API_KEY. Subscription providers that use OAuth device flow, like chatgpt/* or github_copilot/*, need no key, and OpenKB skips the missing-key warning for them. The web UI requires a separate extra: pip install "openkb[web]" and then run openkb-web, which serves at http://127.0.0.1:7566/. Auth is off by default, and you enable it by setting OPENKB_API_TOKEN.

The Vectorless Retrieval Bet: PageIndex and Long Documents

OpenKB's headline feature is that it does not use a vector database. Instead, PageIndex provides what the README calls reasoning-based retrieval for long documents. The mechanism is a tree index. For a long PDF, PageIndex builds a hierarchical tree of summaries, and the LLM navigates that tree to find relevant sections. This is a different approach from embedding-based similarity search. Vector search maps queries to dense vectors and finds nearest neighbors, which can miss conceptual matches that share no lexical terms. A tree index, by contrast, is built to preserve document structure and context, and retrieval reasons over that structure. The trade-off is that tree construction is an LLM-heavy operation, so it is slower and more expensive than hashing text into vectors. But the payoff is that the wiki can answer questions that require synthesis across sections, not just string matching. The README claims native multi-modality, meaning figures, tables, and images are retrieved and understood, not just text. For short documents, images are extracted inline with pymupdf. For long documents, PageIndex handles them. This is a strong claim, but the material does not describe how image understanding is evaluated or what happens when an image contains no extractable text. That is a gap to probe before relying on it.

Where It Struggles: Compilation Cost and Freshness

The biggest limitation is that compiling a wiki is not free. Every document you add triggers an LLM pass to generate summaries and concept pages. For a large corpus, that is a significant upfront cost in both time and API tokens. The README does not give performance numbers or cost estimates, so you cannot predict the bill without experimentation. A second issue is freshness. The wiki is compiled from documents at the time you add them. If a source document changes, you must re-add it or trigger a recompile; the README does not describe an incremental update mechanism for existing pages. The phrase kept in sync for entity pages suggests some automation, but the details are absent. For rapidly changing documentation, this could mean your wiki is stale. A third concern is that the system depends on a single LLM provider at a time. You configure one model in config.yaml, and while LiteLLM supports many providers, you are tied to that model's strengths and weaknesses. If the model hallucinates a concept page, the wiki propagates that error. Traditional RAG at least lets you re-query the source on each ask. OpenKB bakes errors into a persistent artifact, which is a different risk profile.

The Alternative: Traditional RAG with a Vector Store

The obvious alternative is the standard RAG pipeline: chunk documents, embed them into a vector database, and retrieve relevant chunks per query. Tools like LangChain plus Pinecone or Weaviate follow this pattern. The difference in approach is fundamental. RAG is stateless and query-time. It never builds a persistent knowledge structure, so every query repeats the retrieval step over the same chunks. That is cheaper to set up and easier to update, because you can re-embed a single changed document without recompiling a whole wiki. RAG also handles arbitrary query phrasing better if your embeddings are good, because it does not rely on a pre-built concept hierarchy. But RAG does not accumulate cross-references, flag contradictions, or create entity pages. Each query is a blank slate. OpenKB is for users who want that accumulated structure, and who are willing to pay the compilation cost to get it. If your need is simple question answering over a small, static set of documents, RAG with a vector store is likely the simpler and more predictable choice. If you need to synthesize across hundreds of long documents and want a browsable knowledge base, OpenKB's wiki model is the differentiator.

Licensing, Maintenance, and the Web UI Caveat

OpenKB is licensed under Apache-2.0, which permits commercial use, modification, and redistribution with attribution. That is a permissive license, so it is safe for internal tools and most products, but you should still read the full terms. The project is actively maintained, with recent releases v0.4.5 in July 2026 and v0.4.4 before that. The README notes that LiteLLM is pinned to a safe version, citing a security update from March 2026. That is a responsible move, but it means you are not getting the latest LiteLLM features unless OpenKB updates its pin. The maintenance cost for you is low if you stick to the pip package. If you run the web UI, note that auth is off by default. The README is explicit: set OPENKB_API_TOKEN before exposing the server. That is a real security footgun for anyone who binds the server to a network interface without reading the docs. The web UI is bundled, but if you want to modify it, you need to run the Vite dev server and rebuild the frontend, which adds a Node.js toolchain to your stack. For most users, the prebuilt UI is fine.

Editorial conclusion

Adopt OpenKB if you work with long, mixed-format documents and want a persistent, queryable knowledge base that accumulates structure over time, especially if you can run a local web UI and accept the dependency on a single LLM vendor via LiteLLM. Do not adopt it if you need strict real-time updates on frequently changing documents or if you cannot tolerate the cost and latency of LLM-based compilation for every added file. Before committing, verify that your document types (especially scanned PDFs or complex images) are handled well by markitdown and PageIndex, and test the quality of the generated wiki on a sample of your corpus. Also confirm that the pinned LiteLLM version supports your preferred provider and that the Apache-2.0 license fits your distribution plans.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. VectifyAI/OpenKB on GitHub