The output is a wiki that people can inspect
OpenKB asks a model to compile each source into persistent summaries, concepts, entities, cross-links, an index, and a log. The files are ordinary Markdown with wikilinks, so the result stays readable when OpenKB is not running. A researcher can open the folder in Obsidian, correct a page, track it in Git, or point another text tool at it.
The CLI accepts PDFs, office files, HTML, CSV, text, directories, and URLs. It can answer a cited question, keep a chat session, render an interactive graph, produce an HTML slide deck, or distill the wiki into an agent skill. Claude Code, Codex, and Gemini CLI integrations read that compiled material. This is useful when the knowledge base itself, rather than only the chat interface, should remain an artifact.
Long documents avoid vectors but still consume model work
Short documents pass through MarkItDown and are read in full. PDFs of at least 20 pages take the PageIndex route, which builds a tree and summaries for model-guided retrieval. PageIndex runs locally by default, while its optional cloud service adds OCR and other processing for difficult PDFs. Avoiding a vector database removes one service; it does not make indexing free.
Each new source can update 10 to 15 wiki pages according to the README. OpenKB generates a source summary, reads existing concepts and entities, rewrites relevant pages, and updates the index. Issue 203 shows how that incremental design can hurt a dense backfill. On roughly 1,100 documents, recurring pages grew and were regenerated repeatedly, pushing individual updates into minutes and making total work resemble quadratic growth.
What happened when we ran it
Our sandbox installed commit ff54396 in 37 seconds, adding 132 Python packages and consuming 533 MB. The build completed successfully in 7 seconds. The checkout contained 293 files and about 54,840 lines of source. Two CI workflow files and a tests directory were present, while no Dockerfile was found.
The test command exited 1 after 152 seconds. Pytest counted 1,079 tests: 971 passed, 104 failed, and 4 produced collection or setup errors. The final failure said async functions were not natively supported and suggested plugins such as anyio or pytest-asyncio. Four API modules ended as errors. That tail does not prove one plugin caused all 108 unsuccessful outcomes, so the honest result is a failed suite.
Pip-audit found 2 known vulnerabilities in the installed environment. Our run did not compile a private corpus, pay for a hosted model, assess retrieval accuracy, or compare answers with source documents. The 533 MB disk figure covers installed code, not a working knowledge base plus its source files, generated wiki, images, and model-side usage.
Hosted models are the easier route today
The documented start is short: install OpenKB, initialize a folder, choose a LiteLLM model, place its credential in .env, and add a document. OAuth-backed providers can avoid a conventional API key. The Workbench and REST API require a web extra and listen locally; authentication is off by default, so OPENKB_API_TOKEN belongs in the configuration before any proxy exposes port 7566.
Local provider support needs qualification. Issue 205 reports that document addition worked through Ollama, while query and chat did not reliably finish tool calls. Tested outcomes included raw JSON, {}, empty responses, invented tool names, and timeouts across several models. LiteLLM compatibility gets a request to the model, but OpenKB still depends on that model and adapter completing a structured agent loop correctly.
Issue 219 identifies another split between short and long paths. With a custom OpenAI-compatible proxy, short documents worked, but a PDF over the 20-page threshold failed with a 401. The report says PageIndex did not inherit the configured base URL and credential. Users with private gateways should test both document paths rather than assuming a successful Markdown ingest proves long-PDF support.
Generated claims need a human editor
A compiled wiki makes model errors durable. Issue 214 gives specific examples: a misspelled name, an unsupported description of a historical figure, and fabricated details about the reporter's family and location. A later openkb lint call caught some errors, but only after a person remembered to run it. Citations reduce the effort needed to inspect a claim; they do not make the claim true.
For a serious collection, put linting and source comparison after every ingest batch. Review entity merges, biographical statements, contradictions, and any page that changed across several sources. The Skill Factory adds validation, evaluation, history, and rollback for the packaged skill, but those controls do not substitute for checking the knowledge written into the wiki.
July code activity and August reports show a young project
GitHub showed 3,845 stars and 45 open issues and pull requests when fetched. Release v0.4.5 was published July 20, 2026, and the last push was July 22. Issue discussion continued into August, including proxy and packaging reports. That is a live community around a young 0.x project, not evidence that the current branch has resolved its ingestion and local-model limits.
OpenKB earns a trial because its plain-file output is genuinely useful. Start with a small, representative set, then record model spend, compilation time, page churn, and factual corrections before importing more. The failed 1,079-test run makes that staged approach more important: the architecture is interesting, but our measured checkout did not clear its own suite.