Local-NotebookLM: turn a PDF into a podcast with local LLMs and TTS
Googles NotebookLM but local
At a glance
- What is it?
- Goekdeniz-Guelmez/Local-NotebookLM is an Apache-2.0 Python tool that reads a PDF and writes a generated audio script, with a CLI, a Python API, a Gradio UI and a FastAPI server. The interesting part is the plumbing; the weak part is that the README never tells you how to configure the model endpoints it depends on.
- Who is it for?
- Adopt it if you already run an OpenAI-compatible LLM endpoint or a Kokoro-FastAPI TTS server and want a scripted pipeline rather than a hosted notebook product. Skip it if you need a supported configuration surface, because the README documents the CLI flags but not the environment variables that point the client at your own model server.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 130 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Local-NotebookLM does with a PDF
The project describes itself as "a local AI-powered tool that converts PDF documents into engaging audio", and the tagline is "Googles NotebookLM but local". That framing is accurate about the shape of the output and misleading about the scope. NotebookLM is a hosted product with a fixed model stack. Local-NotebookLM is a pipeline you run yourself, and it only does two things: extract text (and optionally images) from a PDF, and ask a language model to turn that material into a script that a text-to-speech engine then reads aloud.
The audience follows from that. If you have a pile of papers, internal reports or lecture notes and you want a spoken version in a chosen register, this repository is aimed at you. If you want to ask questions against a document corpus, cite passages or build a knowledge base, nothing in the README suggests this tool does any of that. It generates audio. The repository ships example output in examples/podcast_example_casual.wav and examples/podcast_example_genz.wav, and the README notes the example podcast was produced with "gpt4o and Mini with tts-hs on Azure", which tells you the author's own reference run was not fully local.
The pipeline: extraction, script generation, speech synthesis
The data flow is linear and easy to reason about. A PDF goes in through --pdf. Text is extracted, and if --is-vlm is set, extracted PDF images are sent to the language model as well, making the transcript multimodal. The LLM then produces a script shaped by three knobs: --format_type, --style and --length. Finally a TTS stage converts the script to audio using a selected voice, and the result lands in --output_dir, which defaults to ./output.
The format system is the most developed part of the design. Formats split into single-speaker (summary, narration, storytelling, explainer, lecture, tutorial, news-report, executive-brief, analysis), two-speaker (podcast, interview, panel-discussion, debate, q-and-a, meeting) and multi-speaker (panel-discussion and debate at 3, 4 or 5 speakers). --num_speakers accepts 1 through 5 and defaults to 2 for podcast and interview. The speaker count is not cosmetic: it changes how many distinct TTS voices the synthesis stage has to produce and keep separate, which is where a two-speaker podcast becomes noticeably harder than a narrated summary.
The provider list is broad on paper. The README names OpenAI, Groq, LMStudio, Ollama and Azure, and the repository topics add Anthropic and Gemini. The default value for --llm_model is gemini-3-flash-preview:cloud, which sits oddly against a project whose selling point is locality. Treat the default as a convenience for a first run, not as a statement about where inference happens.
Installing Local-NotebookLM and generating a first file
The README gives two install paths. The published package is the shorter one. Python 3.9+ is listed as a prerequisite, though pyproject.toml sets requires-python to ">=3.12" while setup.py still says ">=3.9", so the two packaging files disagree and the safer assumption is the higher bound.
pip install local-notebooklmIf you prefer the source tree, clone it and install the pinned requirements into a virtual environment.
git clone https://github.com/Goekdeniz-Guelmez/Local-NotebookLM.git
cd Local-NotebookLM
python -m venv venv
source venv/bin/activate # On Windows, use: venv\Scripts\activate
pip install -r requirements.txtThe requirements file is short: PyPDF2, numpy, soundfile, openai, tqdm, pydantic, gradio, fastapi, uvicorn. There is no local inference runtime in that list, which confirms that the LLM and the TTS engine are external services you bring yourself.
Docker is the third route. The image exposes 7860 and 8000, defaults to the Gradio UI, and switches to the API when APP_MODE is set to api.
docker build -t local-notebooklm-ui .
docker run -p 7860:7860 local-notebooklm-ui
docker run -e APP_MODE=api -p 8000:8000 local-notebooklm-uiThe first run is a CLI call. The README's basic example takes a PDF path and nothing else.
python -m local_notebooklm.make_audio --pdf documents/research_paper.pdfWith no other flags you get the defaults: format_type podcast, style normal, length medium, two speakers, output in ./output. To make the run predictable, set the format and the language explicitly.
python -m local_notebooklm.make_audio --pdf documents/research_paper.pdf --format_type podcast --length long --style casual --language englishWhat you should see is a generated script and a rendered audio file under the output directory. What the README does not tell you is which endpoint the client called, because the base URL and API key configuration is not documented there. Expect to read the source under local_notebooklm/ to find out.
If you want the pipeline inside a larger program, the processor module exposes a function with the same parameters as the CLI.
from local_notebooklm.processor import generate_audio
generate_audio(
pdf_path="documents/research_paper.pdf",
output_dir="./test_output",
llm_model="qwen3:30b-a3b-instruct-2507-q4_K_M",
language="english",
format_type="interview",
style="professional",
length="long",
num_speakers=2,
custom_preferences="Focus on the key technical aspects"
)For a fully local TTS path, the README points at Kokoro-FastAPI and gives one concrete verification step: check that http://localhost:8880/v1 returns the JSON {"detail":"Not Found"}. That response is the expected one, not an error.
Where the documentation stops and you start reading code
The largest limitation is not a bug, it is an absence. The README documents every CLI flag in a table and gives five worked examples. It does not document how to point the OpenAI-compatible client at LMStudio, Ollama or Azure, which environment variables carry the API key and base URL, or how a voice is selected for each speaker. The prerequisites mention a local LLM server and a local TTS server as "optional", without saying what interface either must expose, with the single exception of the Kokoro-FastAPI health check on port 8880.
That gap has a practical consequence. The default --llm_model is a cloud Gemini identifier, so a first run without configuration may leave your machine. Anyone adopting this for confidential documents should verify the outbound endpoint before feeding it a real PDF, and the README will not help you do that.
The second limitation is scope. This is a one-shot transformation, not a notebook. There is no retrieval, no follow-up questioning, no citation of page numbers back into the source. A long PDF is compressed into a script by a single generation pass, and the --length flag controls how much of that content survives. If your goal is to interrogate a document, this is the wrong tool regardless of how good the audio sounds.
Third, the packaging files disagree about the Python version, and the README's prerequisites say 3.9+ while pyproject.toml says 3.12+. On a 3.9 or 3.10 interpreter you may install successfully and hit failures later.
Local-NotebookLM compared with a plain script over an LLM and TTS API
The honest alternative is not another repository. It is writing the pipeline yourself: extract text with PyPDF2 or pypdf, send it to your model with a prompt that describes the desired format, then post the result to a TTS endpoint. That is roughly what this project does, and the requirements list shows how few moving parts are involved.
The difference is in the parts you would have to write. Local-NotebookLM encodes sixteen format types, eight styles, four lengths and a speaker-count model, and it has already resolved the awkward details of multi-speaker synthesis, where a script has to be segmented by speaker before voices are assigned. Reproducing that from scratch is a day of work, not an afternoon, and the repository ships example audio so you can judge the output before building anything.
The trade-off runs the other way too. A hand-written script uses whatever configuration mechanism you already have, and it will be documented because you wrote the documentation. This project's configuration surface is undocumented, so the cost you avoid in prompt engineering you pay back in source reading. For a one-off conversion, the manual route is competitive. For repeated runs across many documents with varied formats, the format taxonomy here is the reason to use it.
A second alternative worth naming is the author's own stand-alone app, which the README announces as a separate repository at https://github.com/Goekdeniz-Guelmez/Local-Notebook-LM-App. If you want a packaged application rather than a Python module and a server, that is the project to look at first.
Maintenance, licensing and what a v2 upgrade costs
The repository is not archived. The last push was on 2026-05-08, which is the same date as the v2.0.1 release, so the release and the last commit coincide. The release history is short and unevenly spaced: v1.2.2 on 2025-03-26, v2.0.0 on 2026-02-24, then v2.0.1. That pattern suggests bursts of work rather than a steady cadence, and the eleven-month gap between v1.2.2 and v2.0.0 is worth knowing if you plan to depend on the programmatic API, since a major version bump can move the processor signature.
The licence is Apache-2.0, declared in both pyproject.toml and setup.py. That permits commercial and closed-source use, and it includes a patent grant. The practical implication for a tool like this is that the licence is not the constraint; the external services are. Your LLM provider's terms and your TTS provider's terms govern the audio you produce and the text you send, and neither is covered by the Apache grant. That is a description of where the obligations sit, not legal advice.
Upgrade cost is concentrated in two places. The dependencies are unpinned in requirements.txt, so a fresh install can pull newer versions of gradio, fastapi or openai than the author tested against. And because configuration is undocumented, an upgrade that changes how endpoints are read will not appear in a changelog you can consult.
Editorial conclusion
Adopt it if you already run an OpenAI-compatible LLM endpoint or a Kokoro-FastAPI TTS server and want a scripted pipeline rather than a hosted notebook product. Skip it if you need a supported configuration surface, because the README documents the CLI flags but not the environment variables that point the client at your own model server. Before committing, install it, run the CLI against a short PDF, and confirm which endpoint and voice it actually called, since that is the one thing the documentation leaves you to discover.
Frequently asked questions
Is there a local NotebookLM I can run myself?
Local-NotebookLM is presented as exactly that, described in the README as "Googles NotebookLM but local". It converts PDFs into audio using language models and text-to-speech, and it can run against local servers such as Ollama, LMStudio and Kokoro-FastAPI. It does not reproduce NotebookLM's question-and-answer features, only the audio generation.
Is Local-NotebookLM a good local NotebookLM alternative?
It covers the PDF-to-audio part of the workflow and offers sixteen format types, eight styles and one to five speakers, which is more control than a hosted product typically exposes. It does not do source-grounded question answering or citation, so it is an alternative for audio generation specifically, not for the whole product.
Which language models and TTS engines does Local-NotebookLM support?
The README lists OpenAI, Groq, LMStudio, Ollama and Azure as LLM providers, and the repository topics add Anthropic and Gemini. For speech, the README points to Kokoro-FastAPI as a local TTS server. The default --llm_model value is gemini-3-flash-preview:cloud.
Can Local-NotebookLM run entirely offline?
The prerequisites list a local LLM server and a local TTS server as optional, and the README explains how to verify a Kokoro-FastAPI instance at http://localhost:8880/v1. Because the default model identifier points at a cloud Gemini model, a default run is not offline; you have to configure a local endpoint, and the README does not document how.
How do I install Local-NotebookLM?
Install from PyPI with pip install local-notebooklm, or clone the repository, create a virtual environment and run pip install -r requirements.txt. A Dockerfile is also included and exposes ports 7860 for the Gradio UI and 8000 for the FastAPI server.
What are the hardware requirements for Local-NotebookLM?
The README states at least 8GB RAM, with 32GB or more recommended for local models, and 10GB or more of free disk space. Python 3.9+ is listed as a prerequisite, although pyproject.toml declares requires-python as >=3.12.
Community notes