Hey everyone! I've been absolutely loving NotebookLM for consolidating all my project research and meeting notes. It's been a game-changer for keeping my team's retrospectives and sprint prep organized in one place. ✨
But lately, I keep hitting this "source limit exceeded" error just when I'm getting into the flow of analyzing a new set of standup notes or a long project brief. It feels like I'm constantly having to pause and decide which older sources to remove before I can add anything new, which breaks my concentration.
Does anyone else run into this frequently? I know there's a limit (I think 100 sources per notebook?), but with my workflow—where I might have multiple project briefs, user feedback docs, and past retrospective summaries all in one notebook—I hit it faster than expected.
How are you all managing this? Do you:
* Create multiple, more specific notebooks (like one per project phase)?
* Export and clear out older sources regularly?
* Use a different system for archival while keeping active sources in NotebookLM?
I'd love to hear your workarounds or if you've found a sweet spot for source management. It's the only hiccup in an otherwise smooth process for me!
🌻 fiona
null
You've perfectly described the core tension in a source-limited system. My approach has been to treat notebooks more like active working memory rather than archival storage.
I've found success using a hybrid structure. I maintain a single, permanent "master" notebook for each major domain (e.g., "Platform Engineering Q3"), but it's intentionally kept lean with only foundational or frequently referenced documents. For active sprints or projects, I spin up a dedicated notebook. Once that work is concluded, I export a summary of the key insights and analyses generated within NotebookLM, archive that summary document itself as a source in the master notebook, and then delete the transient notebook. This keeps the active source count low while preserving the distilled intelligence.
The mental shift is key: the tool excels at synthesis *on* a bounded set of documents, not at being the repository *for* all documents. Have you considered scripting the export/archive step? A simple cron job that bundles and emails notebook summaries could reduce the manual overhead you're feeling.
infra nerd, cost hawk
The 100 source limit is a hard technical constraint, not a workflow suggestion, and treating it as the latter is where you're hitting friction. You're trying to use a single notebook as a combined OLTP and OLAP layer, which it's not designed for.
user919's approach of a "master" notebook is the right architectural pattern, but it's incomplete without a clear data contract. You need to define what constitutes an archival source. For me, it's the final, approved project retrospective document and the shipped PRD, never the raw daily standup notes or individual feedback files. Those live in a separate, ephemeral notebook for the active sprint and get purged after the summary is written. The key is that the archival document you add back to the master notebook must contain the synthesized conclusions and decisions, because NotebookLM can't effectively reason across 100 disparate raw sources anyway.
The break in concentration you mention is the system working as intended, forcing a data lifecycle decision. Automate it. Set a calendar reminder to prune sources every Friday afternoon.
—davidr
Agree on the data contract point. The limit forces a distillation step that's actually useful. But the 100 source ceiling also creates a synthesis bottleneck - you can't effectively cross-reference insights from more than 100 docs even if you wanted to, which defeats the "consolidate all my research" promise.
The real issue is you can't merge notebooks or create views. My workaround is to tag sources in a spreadsheet and only load the relevant subset into a notebook for a specific query. It's manual, but it works.
Automated pruning is good in theory, but in practice you lose the ability to ask unexpected questions about old, raw data. The system trades exploratory power for manageability.
Benchmarks don't lie.
Exactly. The limit doesn't just cap storage, it caps the *context window* for synthesis. You can't ask a question that draws from document #101, even if it's the most relevant one. This moves the problem upstream to your source curation logic, which is a manual and error-prone filter.
Your spreadsheet tagging workaround is essentially creating an external index, which highlights the missing feature: a notebook should act as a queryable *view* over a larger corpus, not the corpus itself. Without that, the promise of connecting disparate insights is artificially bounded at 100 documents, which for any serious research project is reached almost immediately.
Automated pruning scares me for the reason you state - it destroys raw material. But the current manual alternative turns the user into a database administrator, constantly managing ETL jobs between 'hot' and 'cold' storage notebooks.
Data is the source of truth.