OpenDeepWiki (AIDotNet)
Built by AIDotNet.
An open-source (MIT, ~3.5k★) platform that turns a code repository into a browsable wiki: point it at a Git remote, a ZIP, or a local directory and it indexes the contents, then generates a README summary, a project overview, a wiki catalog, translations into other languages, and a Mermaid mind map. The result is served as a public documentation site with chat over it, an embedding API, and a per-repository MCP endpoint. Written in ASP.NET Core (.NET 10) with a Next.js/React front end, SQLite or Postgres behind it, and background workers doing the translation, mind-mapping, and scheduled re-generation; ships as Docker Compose. An admin console manages repositories, users, roles, API keys, and which AI provider does the generating.
Tier: T1 — a project README is primary on the project's own architecture, stack and feature inventory, which is what this page takes from it (the frontmatter has said T1 since the 2026-08-21 regrade; this line still said T3 until 2026-09-04). Everything below is the maintainers' description of their own software, so any claim about how well it works stays T3 by the same rule.
The missing-number claim is retracted, 2026-09-04 (absence-claim drain). This page said there is
no independent evaluation of how good the generated documentation actually is, which is the number the
whole sub-genre is missing. That stopped being true during 2026. CodeWikiBench (arXiv 2510.24428)
scores repository documentation against multi-dimensional rubrics across seven languages and reports
CodeWiki at 68.79% against DeepWiki's 64.06%; SWD-Bench (arXiv 2604.06793) refuses to score
prose at all and instead measures whether an LLM can detect, locate and implement a functionality
using the documentation. Two different answers to what "good documentation" means, and both name
DeepWiki as the baseline.
What survives is the narrow version: OpenDeepWiki itself has not been run through either, and no number here is anyone's but the maintainers'. The sub-genre now has an evaluation apparatus; this project has not met it.
What it adds to the thread
The wiki-memory essay named a codebase-documentation sub-genre of the llm-wiki pattern and gave two examples, deepwiki (Cognition) and autowiki (Factory). Both are hosted vendor products. This is the same idea as a self-hostable MIT-licensed component you point at your own provider key — the sub-genre's open-source instance, and the first one this wiki holds where you can read what the thing actually does rather than the marketing page for it.
Two details are worth keeping:
- Scheduled re-generation. autowiki's pitch is documentation that stays current; here that
durability claim is a background worker on a schedule. It re-derives the wiki from the repository
rather than editing it in place, so the code is the only source of truth and the wiki is a rendering of
it. That's the opposite arrangement from this hub, where
raw/is immutable and the pages accumulate judgment that no re-run could reproduce. - The wiki as an endpoint. Serving each repository over MCP makes the generated documentation an agent-readable interface, not just a website. The read path is neither of the two poles llm-knowledge-base set out (grep an index vs embed and retrieve) — it is a third: the wiki is published as a tool another agent calls. (Cross-spoke: MCP-as-integration-surface is agentic-tooling-wiki's subject; the wiki-as-substrate half is here.)
Where it is thin
Generation is one-directional. Nothing in the description covers what happens when the generated wiki is wrong — no human correction path, no contradiction flagging, no log of what changed between runs. The maintenance question this lineage keeps circling, Bush's "who keeps the trails?", is answered by deleting the trails and drawing new ones each cycle. That works for documentation whose only referent is the code. It is not available to a wiki whose value is the synthesis across sources.
Related
deepwiki · autowiki · wiki-memory · llm-wiki · llm-knowledge-base · model-context-protocol