Kwipu

Questions about a notes folder, answered with their sources

Kwipu builds a property graph from a folder of .md, .txt, .pdf and .docx files and answers plain-language questions about it, citing the chunks each answer came from. Relations come from two places: the wikilinks and YAML frontmatter already in the notes, and whatever an LLM extracts from the prose. Obsidian vaults are the main target, but any folder works, and the source files are only ever read, never rewritten. Retrieval happens at question time, the approach LLM Wiki drops in favour of compiling documents into a maintained Markdown wiki.

Resolved wikilinks, line-level provenance, hybrid retrieval

• Links point to notes, not strings: [[Bob]], [[Bob#Role]], [[People/Bob]], [[Bob|B.]] and an aliases: entry on a renamed note all land on the same node. Notes that share a file name in different folders get path-qualified names such as People/Alice and Archive/Alice.
• The words before a link name the relation: "collaborates with [[Bob]]" becomes a collaborates with edge, and a line with no matching pattern falls back to a generic "is related to" in that line's language. Patterns cover English, French, Italian, German, Spanish and Portuguese. Every structural relation records its origin, file, frontmatter field, line number and a hash of the note's content.
• Hybrid retrieval: vector similarity, BM25 and temporal metadata, plus an LLM synonym retriever that --fast mode, the MCP server and the bridge all skip.
• One index, three front ends: an interactive CLI that watches the folder, a FastAPI JSON API feeding a 3D graph in the browser, and a stdio MCP server exposing query_graph and query_graph_detailed, the second returning citations with the answer.
• Cited sources reopen without the LLM: the /expand endpoint reads the document behind a cited node, PDF and DOCX text extraction included, with no model call.
• Atomic index updates: writes go to a staging generation that is swapped in atomically, and the bridge and MCP server load the new revision on their own before answering.

Cloud model by default, full rebuild on every edit

The default LLM runs in the cloud. The GitHub description promises a "fully local" engine with "No cloud", yet the default model, gpt-oss:20b-cloud, can forward document chunks, retrieved context and questions to its provider, even when Ollama itself answers on localhost. The README flags this at the top and asks for a choice before the first index build; its local example is qwen2.5:7b. Embeddings use nomic-embed-text locally in both modes.

Editing a note rebuilds the whole index. Only newly created files are inserted incrementally. Any modification or deletion triggers a full rebuild for the batch, and an editor's atomic save can show up as a delete plus a create, with the same result. Switching embedding models requires a fresh index.

The web API has no authentication or rate limiting. Its defaults are deliberately local, limited to localhost and the Vite dev server. For production, the bridge docs say to keep Uvicorn on a private interface behind an authenticated TLS reverse proxy. A web session runs four processes (Ollama, the indexer, the bridge and Vite), while terminal-only use needs just Python 3.12 and Ollama.

No releases or tags: installation means a git clone or a ZIP of the repository. The repository opened on 21 April 2026 and has 46 commits, 41 of them by its author. None landed between June and August; October brought 22, the latest on 22 October 2026. Neither the README nor the website states a maturity level. It also includes a standard-library unittest suite.