Compiling knowledge into a wiki beats re-deriving it from documents every query

The central bet OpenKB makes is that knowledge retrieval should be a compilation problem, not a lookup problem. Traditional RAG re-derives everything from raw documents on every query. OpenKB instead runs the LLM once over your documents to produce a persistent, interlinked wiki — summaries, concept pages, entity pages, cross-references — and then queries that compiled artifact. The insight is credited to Andrej Karpathy: knowledge should compound rather than be re-derived.

The retrieval mechanism is what makes this more than a fancy note-taker. Long PDFs — anything over 20 pages by default — get processed by PageIndex, which builds a hierarchical tree index rather than chunking text into vectors. The LLM reasons over the tree structure instead of scanning full text, which is how the system claims to handle genuinely long documents without context rot. Short documents go through markitdown to plain Markdown and are read in full. Both paths produce the same output: a summary page and a set of concept pages that get merged into the existing wiki rather than stored in isolation.

When you add a document, the LLM reads existing concept and entity pages before writing new ones, so each addition enriches what's already there. A single source can touch ten to fifteen wiki pages. Entity extraction — people, organizations, places, products — happens automatically and stays synchronized. The wiki itself is plain Markdown with wikilinks, which means it opens directly in Obsidian for graph view, no conversion needed.

The generator layer sits on top of this compiled foundation. openkb query answers a question with citations. openkb chat runs multi-turn sessions with session persistence. The Skill Factory is the most unusual output: it distills a portable agent skill from your wiki that Claude Code, Codex, and Gemini CLI can install natively, so other agents can call on the compiled knowledge without re-reading the source documents.

The roadmap is candid about what's missing. Long-document handling currently only covers PDFs; other formats are on the list. Nested folder support and hierarchical concept indexing for very large collections aren't there yet. A database-backed storage engine is planned but not built. The web UI — the Knowledge Workbench — is marked complete and ships bundled, served locally at port 7566 with auth off by default.

The no-vector-database stance is a genuine architectural choice, not just a marketing angle. PageIndex's tree indexing is the load-bearing piece, and it runs locally without external dependencies. Cloud support is optional, adding OCR for scanned PDFs and faster indexing for complex documents. The whole stack — PageIndex, markitdown, OpenAI Agents SDK, LiteLLM — is open and composable, and LiteLLM means you're not locked to any single provider.