Node 24 turns raw sources into a persistent Markdown wiki
llmwiki asks you to spend model time before the question arrives. It ingests notes, papers, READMEs, transcripts, PDFs, images, or web pages, then compiles them into linked Markdown pages with source references and review state. Later queries work from that maintained wiki instead of reconstructing the same relationships from loose chunks. The useful distinction is persistence: an answer can become a page, changed sources can mark pages stale, and a person can inspect what the model produced.
The repository is much broader than a folder-to-Markdown converter. Version 1.3.0 includes typed profile records, workflow gates, a local viewer, exports, an MCP server, and a TypeScript SDK. The built-in AutoSci and Newsroom templates show how one compiler can enforce different records and transitions. That machinery pays off when the wiki itself is a maintained asset. For a one-off question over a few files, it is a lot of policy and state to own.
Runtime gates make generated pages reviewable, not automatically true
A profile can require fields, relations, evidence, artifacts, and lifecycle transitions before a write is accepted. External Open Knowledge Format bundles enter a review queue by default, and compilation can hold risky pages for approval. Those controls are more useful than a prompt that merely asks the model to cite sources. They give an operator somewhere concrete to reject a bad page and a lint command that can find broken citations, stale ownership, or schema drift later.
The boundary still matters. llmwiki uses an LLM to extract concepts and write pages, so a passing gate does not prove that every claim is correct. Full evaluation can ask another model to judge citation support, which adds cost and another model decision. The product makes review possible and records provenance; it does not remove the need to read important output. Teams with regulated or safety-sensitive knowledge should define who approves pages before they compile the first real corpus.
What happened when we ran it
Our sandbox installed 448 npm packages in 18 seconds and occupied 601 MB on disk. The build succeeded in 78 seconds. This was commit 3fa9f37 in an unprivileged Debian container with 3 CPUs and 8 GB of RAM. The checkout contained 2,793 files and about 361,383 lines of source, with npm workspaces and 3 CI workflow files but no Dockerfile. Setup was quick relative to the size of the codebase.
The test command did not finish before our 900-second limit. Its final lines showed individual cancellation and handoff cases still passing, some taking more than 16 seconds, followed by completed files for 104 identity-path tests and 15 viewer-journey tests. The log tail contains no final suite summary and no stated cause for the timeout. We can say the run exceeded our cap while work continued; we cannot call the suite passing or identify a defect from that output.
The npm audit found 13 known vulnerabilities: 6 high severity, 6 moderate, and 1 low, with none marked critical. That count is a dependency finding for the installed tree, not evidence that the viewer or MCP server is exploitable. Before deployment, inspect the actual advisories and whether affected packages sit on a reachable path. The measured result is still a reason to make dependency review part of evaluation rather than treating the successful 78-second build as the finish line.
Provider choice reaches beyond one API key
Node.js 24 or newer is the minimum. Anthropic is the default, while the README also documents OpenAI-compatible services, Ollama, GitHub Copilot, Atlas Cloud, OrcaRouter, Claude Agent SDK login, and Codex CLI login. Some choices need a separate embedding provider. Read-only MCP operations work without model credentials, but compile, query, and full citation judging do not. A serious trial should price page generation, embedding refreshes, and evaluation against the corpus you will maintain.
Storage has a visible ceiling too. Version 1.3.0 added binary embedding files for stores beyond the earlier 64 MiB JSON limit, yet retrieval still loads the index into memory. The release notes explicitly avoid claiming out-of-core search. Incremental compilation and content hashes reduce repeated work, but a large wiki still needs memory planning. If the source is a fast-moving stream, the README itself recommends raw search because review and repair can lag behind the input.
Linux is the supported choice while Windows validation remains open
The last push was September 23, 2026, and GitHub showed 2,108 stars plus 7 open issues and pull requests. Three open pull requests were receiving updates in the preceding days, while v1.3.0 had shipped on September 11. That is current activity, not an abandoned tag. The open count combines issues and pull requests, so it should not be read as 7 confirmed bugs.
One open item is decisive for platform selection. Issue 217 says native Windows filesystem guards, lock behavior, package launching, and a required Windows CI job still need validation. The release notes advise Linux for untrusted projects. Start there, pin the provider and configuration, compile a representative source set, then inspect the held pages and memory use. The 900-second test timeout makes that pilot a release gate, not a formality.