Open-source alternatives to NotebookLM: 4 AI research notebook tools compared
NotebookLM keeps your sources, the notes derived from them and the citations between them on the vendor's servers, and these four candidates split into three shapes: a client for the same hosted service, a retrieval library you embed, and applications you deploy yourself. If the sources have to stay on your own machines, khoj-ai/khoj is where most readers should start.
What NotebookLM does, and why people look elsewhere
NotebookLM is a hosted notebook that reads the sources you upload, answers questions about them with citations and turns the same material into study notes.
- the sources you upload and the notes derived from them are stored on the vendor's servers
- the answers cite the vendor's copy of the sources, so a shared notebook is a shared copy rather than a link to your own file
- there is no self-hosted notebook for the same workflow, so the whole reading and quoting loop stays with the vendor
The candidates at a glance
| Project | Licence | Maintenance | Language | GitHub stars | Install |
|---|---|---|---|---|---|
| teng-lin/notebooklm-py | MITPermissive: commercial use allowed | Commits in the last six monthsLast push October 22, 2026 | Python | 19,885 | Command documented |
| QuivrHQ/quivr | MITPermissive: commercial use allowed | Commits in the last six monthsLast push October 21, 2026 | Python | 39,602 | See analysis |
| khoj-ai/khoj | AGPL-3.0Network copyleft: hosting a modified version means sharing source | Commits in the last six monthsLast push August 2, 2026 | Python | 37,811 | See analysis |
| onyx-dot-app/onyx | Custom licenceCustom licence: read the LICENSE file | Commits in the last six monthsLast push October 23, 2026 | Python | 32,920 | Command documented |
Each alternative in detail
teng-lin/notebooklm-pyUnofficial Python API and agentic skill for Google Gemini Notebook. Full programmatic access to NotebookLM's features—including capabilities the web UI doesn't expose—via Python, CLI, and AI agents like Claude Code, Codex, and OpenClaw.
- Best for
- A bulk job: importing dozens of sources at once, generating artefacts such as audio overviews, slide decks, quizzes and mind maps, and pulling them out as MP3, MP4, PDF, PNG, CSV, JSON or Markdown.
- What you give up
- It is an unofficial client for the same hosted service, driven by undocumented Google endpoints, so your sources stay on the vendor's servers and your credential is an expiring session cookie; the README itself points at prototypes, research and personal projects. Its dependency caps wait on pull requests, so an installed version can lag behind what the code expects.
- Moving from NotebookLM
- Sources are imported in bulk from URLs, PDFs, YouTube links and Google Drive files, and the generated material comes back out as Markdown, JSON, CSV, PDF or media files, so a corpus can be moved in and the results moved out.
- First install step
- Full setup guide
uv run --frozen --extra browser --extra dev --extra markdown --extra mcp \ --extra server --extra impersonate --extra cookies pytest -n auto \ --dist loadgroup -m repo_lint --timeout=180 --no-cov
QuivrHQ/quivrOpiniated RAG for integrating GenAI in your apps 🧠 Focus on your product rather than the RAG. Easy integration in existing products with customisation! Any LLM: GPT4, Groq, Llama. Any Vectorstore: PGVector, Faiss. Any Files. Anyway you want.
- Best for
- A product team that wants retrieval removed from its critical path and will build the interface itself, with the retrieval strategy expressed as a YAML graph of nodes instead of hard-coded calls.
- What you give up
- It is deliberately thin, so the work you avoid in building retrieval you take on in configuration, because the behaviour lives in the workflow file. The most recent tagged release dates from February 2025, so the version you install may not be the one the current documentation describes, and the licence GitHub reports and the licence the README states are not the same.
- Moving from NotebookLM
- Files are ingested by pointing the Brain at your own list of paths, with PDF, text and Markdown handled and a Megaparse integration available when you need a different loader.
khoj-ai/khojYour AI second brain. Self-hostable. Get answers from the web or your docs. Build custom agents, schedule automations, do deep research. Turn any online or local LLM into your personal, autonomous AI (gpt, claude, gemini, llama, qwen, mistral). Get started - free.
- Best for
- A team that wants an assistant over its own documents and the open web, reachable from a browser, an editor or a phone, and able to run against a local model instead of a hosted one.
- What you give up
- The licence is AGPL-3.0, so hosting a modified instance that other people reach over a network carries an obligation to publish your changes, and some organisations have a standing policy against that. The release line is still beta, and the document types you care about, Notion and org-mode for instance, need checking against your own files first.
- Moving from NotebookLM
- Khoj reads documents directly in the formats it indexes, including PDF, Markdown, Word, org-mode and Notion, so a corpus can be pointed at the running instance instead of uploaded notebook by notebook.
onyx-dot-app/onyxOpen Source AI Platform - AI Chat with advanced features that works with every LLM
- Best for
- An organisation whose knowledge is spread across many applications, where an index that reaches into those applications and answers with citations matters more than asking one document a question.
- What you give up
- The index is where the cost sits. The lite deployment mode carries no document index at all, and the standard mode adds a vector and keyword index, background containers running job queues and workers, model inference servers, Redis and MinIO, which is a stack to operate rather than a script to install. The repository documents two licence editions, so features you need may sit outside the code you get.
- Moving from NotebookLM
- Connectors index the applications where your documents already live, and MCP covers the rest, so a corpus is indexed where it sits instead of being re-uploaded into a notebook.
- First install step
- Full setup guide
curl -fsSL https://onyx.app/install_onyx.sh | bash
Four tools, three shapes: a client, a library, an application you deploy
Sort them first, because they are not four answers to the same question.
teng-lin/notebooklm-py is a client, not a replacement. It is an unofficial Python API, command line and agent skill for Google's notebook service, driving the same backend through undocumented endpoints with your live session cookie as the credential. What it changes is the interface, not the custody of the data: bulk imports, batch artefact downloads, an MCP server for agents, and exports the web interface does not offer. The sources still live on the vendor's side.
QuivrHQ/quivr is a library. There is no server and no interface to look at, only a Brain object you construct in your own code that ingests files and answers questions. The retrieval strategy is data rather than code: a YAML file describes a graph of nodes, from a start node through a history filter and a rewrite step to a retrieve step and a generate step, with a history length and a reranker configuration alongside. You write the chat surface around it.
khoj-ai/khoj is an application you deploy and use. It answers from your documents and from the web, runs against local or hosted models, and reads a wide range of document formats. It exposes agents with their own knowledge and tools, scheduled automations, semantic search, and access from a browser, an editor, a desktop app or a phone.
onyx-dot-app/onyx is an application with an index behind it. It connects to the applications where knowledge already lives, more than fifty of them by the repository's own count, and serves that index to chat, to agents and to MCP clients. It treats the problem as search infrastructure rather than as a chat surface.
The artefact gap: audio overviews, mind maps and study guides
Two things define the NotebookLM experience, and neither is common in the open-source replacements: generated artefacts such as audio overviews, quizzes, flashcards, mind maps and study guides, and answers that cite the exact source document.
The artefact half is where the field is thinnest. A self-hosted assistant answers questions and stops there. khoj-ai/khoj and onyx-dot-app/onyx add agents, deep research and generated output of their own kind, but nothing in the self-hosted set reproduces the notebook pattern of uploading a fixed set of sources and receiving study objects derived from them. If that set is the reason you use the product, the honest answer is that the open-source route stops short of it. The closest available path is the client: teng-lin/notebooklm-py drives the same service and can produce audio overviews, videos, slide decks, quizzes, flashcards, infographics, data tables, mind maps and study guides, then download them in bulk as media, PDF, CSV, JSON or Markdown.
The citation half is better served by the self-hosted set. quivr, khoj and onyx all retrieve from documents you control and can point at a source inside the answer.
What was left out, and why, deserves a line. Note-taking applications with a chat panel over your own vault index a folder of notes rather than a set of uploaded source documents, so they answer a different question and were not put on this list. The hosted notebook products with the same shape are closed services, so there is no code to point a reader at.
What it costs to run each one yourself
quivr costs almost nothing to run, and that is both its appeal and its limit: it is a library inside a process you already run, against a vector store and a model provider you choose. What it costs is your own application, because there is no interface to deploy and no scheduler to write.
khoj-ai/khoj is a single service with a container image and a Python package, which makes it the cheapest of the deployed options. The cost sits in the model, a local one on your own hardware or a hosted one with keys to manage, plus an index and storage for the documents themselves.
onyx-dot-app/onyx carries a real operations bill, and its README is unusually clear about what is in the box. The lite mode is a chat interface that runs in under a gigabyte of memory and carries no document index. The standard mode adds a vector and keyword index, background containers running job queues and workers that keep the connectors in sync, model inference servers for the models used during indexing and answering, Redis as an in-memory cache and MinIO as a blob store. That is several kinds of service to run and monitor, and the deployment guides assume you are comfortable with Docker, Kubernetes, Helm and Terraform.
teng-lin/notebooklm-py costs the least to run and passes the bill on. It has no server to host and no index to maintain, because the index is on the vendor's side. What it needs is a credential that expires and a transport that can change without notice.
Licences: MIT, one to check, AGPL-3.0 and two editions
Two of the four are plainly permissive. teng-lin/notebooklm-py is MIT. QuivrHQ/quivr is MIT as GitHub reports it, although the README states Apache 2.0 and points at a LICENSE file, so read that file before relying on either reading. onyx-dot-app/onyx is the more involved case: the repository documents two licence editions, the community build under MIT and a separately licensed enterprise build for larger organisations, and the features on the other side of that line include single sign-on, role-based access, audit history and group provisioning, which are exactly what a compliance-driven buyer looks for.
khoj-ai/khoj is AGPL-3.0, and that is the licence decision on this page that deserves real attention. AGPL-3.0 is network copyleft. Run an unmodified instance for your own staff and you have no obligation to publish anything. Modify it, let other people reach that modified instance over a network, and the licence asks you to offer those people the source of your modified version. That is a different question from the one server-side licences usually raise, and it is the question most teams asking about a self-hosted assistant are actually asking. A policy that keeps copyleft code out of the stack rules out khoj-ai/khoj on the spot. A policy that is comfortable with copyleft as long as internal modifications stay internal leaves it on the table.
Choosing by scenario, and where each one is the weaker choice
For a solo researcher with a fixed set of papers who wants to hear them summarised, the artefacts are the reason to stay, and teng-lin/notebooklm-py delivers them in bulk without the web interface. It does not move the documents off the vendor's servers, so anyone whose requirement is custody has to look elsewhere.
For a small team with documents it already owns, khoj-ai/khoj is the simplest deployment: one service, one container, many document formats, and it runs against a local model if you want that. The catch is the AGPL-3.0 licence and a beta release line.
For a company whose knowledge sits in many applications, onyx-dot-app/onyx is the only candidate here that indexes the places rather than the files, and the price is the stack that index needs. If your documents live in one shared drive, that stack buys you very little.
For a product team building its own interface, quivr is the one to embed, with the understanding that the retrieval behaviour lives in a YAML file you own and maintain.
The weaker choice in each pairing is worth naming. A self-hosted assistant is the wrong answer when the artefacts are the point, because nothing here generates a notebook's worth of study objects. notebooklm-py is the wrong answer when data custody is the point, because it changes the interface and nothing else. quivr is the wrong answer when you want something to deploy, because it is a library. And khoj is the weaker of the two deployed options whenever documents live in more than a handful of applications, which is where onyx's connectors earn their keep.
Bottom line
Take teng-lin/notebooklm-py if the generated artefacts matter more than where the documents live, khoj-ai/khoj if a single self-hosted assistant over your own files is enough, onyx-dot-app/onyx if the documents are spread across applications, and quivr if you are writing the interface yourself. Before committing, read the LICENSE file of the project you picked, check the Python version its image needs, and confirm that one real question comes back with a citation you can click.
Sources
Was this useful?