A knowledge base you can actually open
OpenKB takes a different position from most retrieval systems. Traditional RAG usually converts documents into chunks and embeddings, stores them in a vector database, and retrieves a few chunks whenever somebody asks a question. OpenKB instead asks a model to compile each source into a persistent wiki. It writes summaries, concepts, entities, cross-links, an index, and a log as plain Markdown and supporting data. Later questions use that accumulated structure rather than rediscovering every relationship from raw chunks.
The output is the attraction. Open the wiki directory in Obsidian and the knowledge base is legible without OpenKB running. People, organizations, places, and products receive dedicated pages. Concepts are synthesized across documents instead of remaining isolated source summaries. Because the files follow a documented structure and use ordinary wikilinks, a researcher can inspect what the model wrote, correct it, put it in source control, or use another text tool on top.
OpenKB also turns the wiki into several outputs. The CLI supports cited one-off questions, persisted multi-turn chats, an interactive graph, and single-file HTML slide decks. Its Skill Factory distills the knowledge into a portable agent skill with validation, trigger evaluation, version history, and rollback. A bundled skill lets Claude Code, Codex, and Gemini CLI read the wiki without an MCP server or a running OpenKB process. That is a clever bridge between personal knowledge management and agent tooling.
Vectorless does not mean computation-free
Short documents go through Microsoft’s MarkItDown and are read in full by the language model. PDFs with at least 20 pages take a different path: PageIndex builds a hierarchical tree and summaries so the model can navigate the document without embedding every chunk. PageIndex runs locally by default. Its optional cloud service adds OCR for scans, faster structure generation, and support for large or complex PDFs.
This avoids operating a vector database and makes the retrieval structure easier to reason about. It does not remove model work. When a source is added, OpenKB generates its summary, reads existing concept and entity pages, rewrites relevant pages with cross-document synthesis, then updates indexes and logs. The README says one source may touch 10 to 15 wiki pages. That up-front compilation is the product, but it also creates latency and cost before the first useful query.
Issue #203 shows the limit of the incremental design. In a backfill of about 1,100 related documents, frequently mentioned entities and broad concepts grew after every ingest, and the system regenerated those pages repeatedly. The reporter measured individual rewrites taking several minutes and consuming thousands of output tokens, with total work approximating quadratic growth. The repository’s roadmap lists large document collections, hierarchical topics, nested folders, and database storage as aspirations. Those items should not be treated as current scale guarantees.
Setup favors a capable hosted model
The happy path is appealing: pip install openkb, initialize a directory, select a LiteLLM provider, put a key in .env, and add a file, folder, or URL. Supported inputs include PDF, Word, Markdown, PowerPoint, HTML, Excel, CSV, and text. The bundled web extra serves a Workbench and REST API on localhost for browsing, uploads, compilation, queries, and chat. Authentication is disabled by default, so an API token is essential before binding or proxying it beyond a trusted machine.
Provider breadth needs qualification. LiteLLM gives OpenKB a common route to OpenAI, Claude, Gemini, subscription OAuth providers, and compatible local servers. The downstream agent still depends on the chosen model producing reliable structured tool calls. Issue #205 reports that ingest worked through Ollama while query and chat failed to complete their tool loop across several tested models. Results included raw call JSON, empty objects, incomplete answers, and timeouts. Another report describes hours of failed PageIndex retries with local models through LM Studio on a well-equipped Mac. Local operation is possible in configuration, but it is not the low-friction path today.
Packaging has one narrower blemish. The normal pip command is documented, but issue #130 says uv tool install openkb from PyPI installed a metapackage without a binary or dependencies on macOS. Installing directly from the Git repository worked for that reporter. This is a workaround, not a reason to avoid the project, but it weakens the otherwise clean install story.
Compilation needs editorial oversight
A generated wiki can make model mistakes durable. Issue #214 reports misspelled names, an unsupported characterization, and fabricated biographical details written during compilation. The same model found some errors when the user later ran openkb lint, leading to a request for automatic self-review. Until such a gate exists, lint and source comparison belong in the normal workflow. Citations help a reviewer find evidence; they do not make synthesis automatically true.
Multimodal claims also have a visible gap. Issue #166 says the long-PDF path extracted images and recorded correct paths in JSON, yet the renderer omitted them from every page a human browses. Image-heavy manuals and scientific papers therefore need a real output inspection, not an assumption that extraction means presentation.
Project health is promising but young. OpenKB was created in April 2026, released v0.4.5 on July 20, and was pushed on July 22. That release quickly pinned an OpenAI dependency after a breaking change. On August 12, GitHub showed 37 open issues and pull requests combined, and the installation issue received a fresh maintainer reply. The recent issue activity offsets the three-week gap since the last push; it does not turn a four-month-old 0.x system into mature infrastructure.
OpenKB is best for a bounded collection where people will read and refine the wiki repeatedly. Its plain-file output is more durable and transparent than an opaque index. Start small, measure compilation cost, review generated facts, and verify the exact document types and model you intend to use before committing a large archive.