Quick answer: a local AI knowledge base is three things on your own machine — your files, an index an AI can search, and something that answers. Every tool in this space is a bundle of choices about those three parts. Decide the three below first and the tool picks itself; skip them and you’ll migrate your library twice.
Decision 1: files in place, or imported?
Most tools import: you upload documents into their store — a workspace, a notebook, a database — and the AI reads the copy. It works, until the original changes and the copy doesn’t, and you discover you’ve taken a part-time job as the librarian of a second library.
The alternative is indexing in place: the tool points at folders you already have, derives an index from them, and rebuilds it when files change. Your disk stays the source of truth; adding material is saving a file where it already goes.
If your library is a bounded, finished set — one course, one case — importing is fine. If it’s alive, in-place is the only model that doesn’t rot.
Decision 2: answers only, or artifacts?
Nearly everything in this category outputs chat: you ask, it answers with citations, the answer scrolls away. Useful, but nothing accumulates — the hundredth question starts from as little as the first.
The alternative is a tool that leaves artifacts: notes, summaries, or wiki pages written to disk as plain files you keep, re-read, and build on. If you want a knowledge base rather than a Q&A box, insist on artifacts you own — in a format that outlives the tool, which in practice means Markdown.
Decision 3: who gets to query it?
Every tool answers in its own chat box. The question is whether anything else can ask. If you already work with Claude Code, Codex, or any MCP client, a knowledge base only they can’t search is a dead end — you’ll paste answers between windows forever.
The dividing line is MCP direction: most desktop AI apps are MCP clients (they pull tools in), which does nothing for your other agents. What you want is your library exposed as an MCP server, so every agent you use queries the same index.
The decisions, mapped to tools
| You chose | Tool that matches |
|---|---|
| import + chat + own box, cloud | NotebookLM |
| import + chat + own box, local | AnythingLLM, Open Notebook |
| in place + chat + own box | Hyperlink |
| in place + artifacts + DIY agent | a folder plus Claude Code or Codex |
| in place + artifacts + any agent over MCP | StashBase |
Full comparisons, including project-health checks and this year’s graveyard, are in the local NotebookLM alternatives roundup.
The part everyone underestimates: formats
A knowledge base that only handles Markdown and text is indexing the easy half of your library. Real folders hold scanned PDFs, DOCX files, screenshots, and recordings — none of which a grep or a naive RAG pipeline can see. Whatever you pick must derive text first: extraction for PDFs and DOCX, OCR for images, transcripts for audio and video. The second half of that problem is search that works by meaning, not wording — semantic search over local files — so “the argument about switching costs” finds the note that says “lock-in.”
Where StashBase lands
StashBase is the last row of the table, by design: folders indexed in place, derived text for mixed formats built in the background, keyword search offline plus semantic search, wiki pages written as visible Markdown you own — and the whole library served over MCP to Claude Code, Codex, Claude Desktop, Cursor, or anything else that speaks the protocol. It’s an app you run, and it’s a free download.
Three decisions, then the tool. Most regret in this category comes from picking in the other order.