Google renamed NotebookLM to Gemini Notebook in July 2026, but the rules for YouTube sources did not change. They are still written down, still specific, and still worth reading before you build a research habit on top of them. This is what the documentation actually says, what each limit costs you in practice, and what to reach for when a video falls outside them.

TL;DR

  • NotebookLM is now Gemini Notebook — announced 16 July 2026. Same product, same YouTube behaviour, new name and logo.
  • Public videos only, and only if captions exist (creator-uploaded or auto-generated). No captions, no import.
  • Videos without speech are not supported at all. A silent screen capture is not an importable source.
  • Only the text transcript is imported. That is the single most consequential line in the whole help page, and it is the one most people never read.
  • Videos uploaded less than 72 hours ago may not be importable yet.
  • A caption file over 500,000 words is rejected; local uploads cap at 200MB.
  • Google's FAQ documents 100 notebooks with up to 50 sources each. YouTube videos share that pool with your PDFs, docs and URLs.
  • If a video is deleted or made private, the source is removed from your notebook within 30 days — your research quietly loses a leg.
  • None of these are bugs. They are the documented shape of the product. The question is whether that shape fits what you are actually doing.

First, the name: NotebookLM is now Gemini Notebook

If you went looking for the NotebookLM help pages recently and found yourself reading about something called Gemini Notebook, you did not take a wrong turn. Google announced the rename on 16 July 2026, and the Workspace Updates post carried the same news to admins. The support centre now says "Gemini Notebook" on every page, including the ones that still live at support.google.com/notebooklm/.

Nothing about the source-handling changed with the rename. Existing notebooks stayed put, shared links kept working, and the YouTube import rules read exactly as they did before. We are going to keep saying "NotebookLM" in a few places in this piece for the simple reason that it is what people still type into a search box, but every citation below points at the current, renamed documentation.

Worth noting for anyone maintaining internal docs: this is the second time the product's identity has moved inside Google's org chart, and each move has left a trail of third-party blog posts describing behaviour that no longer matches the help centre. Cite the help centre. It is terse, but it is the only version that is current.

The mental model most people carry is that NotebookLM "watches" the video. It does not. Here is the documented pipeline, compressed:

  1. You paste a YouTube URL as a source.
  2. Google checks that the video is public and that a caption track exists.
  3. The caption track — not the video — is pulled in as the source text.
  4. Everything downstream (chat, summaries, Audio Overviews, study guides) reasons over that text.

The help page states it in one sentence: "Only the text transcript of the video is imported as a source." (Add or discover new sources for your notebook.)

So when you ask your notebook "what did the config screen look like," it is not being coy. It genuinely does not have the config screen. It has the words the presenter said while the config screen was on display, which is a different and much thinner artifact. Everything else in this article follows from that one fact.

Every documented limit, with its source

1. Public videos only

Unlisted and private videos cannot be imported. This one bites hardest on internal content: the recorded architecture review, the onboarding walkthrough, the customer call your team uploaded as unlisted. All of it is invisible to a notebook.

Source: support.google.com/notebooklm/answer/16215270 — "Only public YouTube videos with captions, either user-uploaded or auto-generated, are supported."

2. Captions must already exist

Same sentence, second half. The captions may be creator-uploaded or YouTube's automatic ones, but they have to be there before you paste the link. NotebookLM does not run speech-to-text on your behalf.

In practice YouTube's auto-captions cover most spoken English content, so this fails less often than you would expect on mainstream videos — and more often than you would expect on exactly the videos a developer wants: small-channel conference talks, non-English tutorials, screen recordings uploaded with captions disabled, and anything where the creator turned the feature off.

3. Videos without speech are not supported

Listed separately in the help page, and it is a genuinely different failure. A silent screen recording of someone configuring a tool — no narration, just clicks — has nothing for the pipeline to grab. It is not that the import produces a thin source; it is that the import is refused.

4. Only the text transcript is imported

The important one. No frames, no on-screen text, no diagrams, no code that appeared in an editor but was never read aloud. If the value of the video is visual — and for technical content it very often is — that value does not survive the import.

We will come back to why this matters more than the other eight limits combined.

5. The 72-hour window

"Videos uploaded less than 72 hours prior may not be available to import." If you are trying to build a notebook the morning after a conference livestream, expect friction. The wording is "may not," so this is a soft limit that sometimes resolves itself; the practical advice is to wait a day and retry rather than conclude the video is unsupported.

6. 500,000 words per source

The help page frames it as a length limit expressed in words rather than minutes: there is no cap on video duration unless the caption file exceeds 500,000 words. That is an enormous amount of speech — well past a hundred hours of ordinary talking — so almost nobody hits it with a single video. It matters mostly for auto-generated caption files on very long streams, which can be verbose.

Source: Frequently asked questions — "The current limit is 500,000 words per source or up to 200MB for local uploads."

7. 200MB for local uploads

Same FAQ line. Note that this is a local upload limit, not a YouTube limit — it applies to files you drag in, not to linked videos. Worth separating because the two get conflated constantly in third-party write-ups.

8. 50 sources per notebook

Google's FAQ documents the allowance as "100 notebooks, with up to 50 sources each and 500,000 words each." Paid tiers raise the ceiling; the help centre does not publish a single tidy table of per-plan numbers, so treat any specific figure you read elsewhere with suspicion and check the FAQ yourself.

The structural point survives whatever the number is: a notebook is a bounded collection you curate, and YouTube videos compete for slots with your PDFs and docs. It is not a place to accumulate everything you have ever watched. That is a design choice, not an oversight — NotebookLM is built around focused, source-grounded projects — but it means "my whole video memory" is the wrong job to hand it.

9. Sources vanish within 30 days if the video does

"If a video is deleted or made private, sources are auto-deleted from your notebook within 30 days." This is the limit people discover last and like least. Your notebook is not a copy of the research; it is a pointer to someone else's content, and the pointer can be revoked. A creator unlisting an old video takes a source out of your notebook a month later, silently.

Bonus: why imports fail

The help page also enumerates the common import failures: an invalid YouTube link, a video flagged as potentially unsafe, no captions file, or a video language that is not currently supported. If your paste bounces, that list is where to start rather than assuming the feature is broken.

Which of these actually matter

Eight of the nine are ordinary product boundaries. You work around them: wait 72 hours, split a long source, prune a notebook, pick a different video. Annoying, not disqualifying.

The transcript-only rule is different in kind, because it does not announce itself. The import succeeds. The notebook answers your questions confidently. The summary reads well. Nothing tells you that half the information in a screen-recorded tutorial never made it in.

Watch a competent technical video with the audio off and you will see the problem immediately. The presenter says "and then we just add the middleware here" while the screen shows a config file, a specific import path, a flag, and a version pin — none of which is spoken. That sentence is what NotebookLM gets. The file is what you needed.

In our own testing on developer-oriented content this pattern was consistent enough to shape the product we built around it: the more useful a video is to somebody trying to do the thing, the more of its information lives on screen rather than in the narration. Talks and interviews survive transcription nearly intact. Tutorials, walkthroughs and bug reproductions do not. We are describing what we observed across the videos we tested, not publishing a benchmark, and you should sanity-check it against your own sources rather than take it as a measured figure.

Here is the concrete version. Suppose you are working through a talk on deploying a service, and the presenter spends ninety seconds on environment configuration. The transcript reads, roughly: "so you'll want to set your region here, and then the timeout — I usually bump this up because the default is too aggressive for cold starts." Four facts you needed are on the screen and not in that sentence: the name of the region variable, the default timeout value, the value they bumped it to, and the file it all lives in. The notebook will answer your question about environment configuration. It will answer it from the commentary track.

Working around each limit without changing tools

Before anyone reads this as an argument to abandon a free product, most of these limits have a workaround that costs nothing.

No captions on a video you need? Run the audio through any speech-to-text tool you already have, then add the result to your notebook as a text source rather than as a YouTube link. You lose the link back to timestamps, but the words get in.

Private or unlisted video? Same move. Export or transcribe it and paste the text as its own source. This is the standard workaround and it is fine for talks; it does not help for anything screen-heavy, because there was never a picture to lose in a text file.

Inside the 72-hour window? Wait. The wording is "may not be available," so it frequently resolves on its own within a day. Retrying every ten minutes accomplishes nothing.

Hitting the source cap? Split by project rather than by topic. The cap is per notebook, and notebooks are cheap — the FAQ documents a hundred of them. The failure mode people hit is treating one notebook as a permanent archive; the product is shaped for one notebook per question you are currently trying to answer.

Worried about the 30-day deletion? This one has no workaround inside the product, and it is the one to take seriously if the research matters. If a source is load-bearing for something you will still care about next year, keep your own copy of the transcript somewhere you control. A notebook is not an archive, and Google says so in the documentation rather than hiding it.

What none of these workarounds recover is the visual content, because no amount of transcript-shuffling produces a picture that was never captured. That limit is structural, and it is the only one worth switching tools over.

The honest alternative: what Clipy's video-to-context does differently

Clipy's YouTube-to-agent-context feature exists because of that gap, so this section is not neutral. Here is what it does differently, stated plainly enough that you can tell whether any of it is relevant to you.

Captioned key frames

When Clipy imports a video with --sync, the transcript goes up and a classifier scores how well it stands on its own. If the verdict is that the words are not enough, the server names the specific timestamps where a picture is required. Those frames are then cut on your machine with ffmpeg and attached to the document with captions describing what is on screen.

Two honest caveats. First, this is conditional: if the transcript genuinely stands alone — an interview, a panel, a podcast-shaped talk — you get no frames, by design, because they would be noise. Second, cutting frames means the media has to be fetched locally at that point; the transcript-only path never downloads media at all, and --no-frames keeps it that way while still giving you the classification.

Videos NotebookLM refuses

A local video file — the screen recording sitting on your disk that was never uploaded anywhere — imports the same way a YouTube link does, by passing a path instead of a URL along with --transcript pointing at a caption file. It goes through the same classification and frame-selection path, so a bug reproduction gets the same treatment as a tutorial. Nothing is uploaded at all unless you pass --sync.

Being precise about the caption question, because it is the one people get wrong: for imports, a video without captions needs a transcript file supplied via --transcript — the CLI tells you when captions are missing and lists whatever caption languages the video does have, rather than quietly writing an empty bundle. Local speech-to-text for imports is in progress and not something to plan around today. (Clipy's own screen recordings are a separate pipeline that does transcribe audio itself; do not confuse the two.) The durable differences from a hosted tool are that private and local material never has to leave your machine, and that you are not restricted to public URLs.

Agent access as the point

Clipy is not the first tool to make a video library agent-readable — Recall ships an MCP server too, and anyone claiming to be "the only agent-readable video memory" in this category is not counting carefully. The difference is what the agent gets and when.

Clipy is CLI-first: the import is a shell command, the output is a directory of plain files, and the agent reads it mid-task. Install the skill once and Claude Code, Codex or Cursor knows how to reach for it:

npx -y @clipy/cli@latest agents install claude

Over MCP, an agent orients cheaply before it spends context: list_context_documents to see the library, get_context_document for metadata and the classification (what kind of video it is, where the words go blind) without pulling the transcript, then read_context_document with a start and end timestamp for just the span it needs. That last part matters on a two-hour talk, where dumping the full transcript into a context window is the difference between a useful answer and a truncated one.

Cross-video search over your own library

Every synced document lands in a full-text index covering its title and its entire transcript, so "which of the things I imported mentioned the webhook retry policy" is a query rather than an afternoon. This is search over your library — the videos you chose to keep — not over the public YouTube corpus, which is a different product and a different promise.

When NotebookLM is still the right tool

It would be dishonest to write three thousand words on this and not say it: for a great many jobs, Gemini Notebook is the better choice, and it is free.

If your sources are documents — papers, PDFs, reports, docs — it is excellent, and video is a side dish. If the videos you care about are talks and interviews where the substance is spoken, transcript-only costs you almost nothing. If you want an Audio Overview to listen to on a walk, or a study guide, or the notebook-shaped chat interface with citations back to sources, Clipy does not offer any of that and is not trying to. And if you want zero setup, a browser tab beats a terminal every time.

The case for a different tool is narrow and specific: you are working with technical video where the screen carries the information, or with private and local footage, or you want an agent to read the material mid-task rather than reading it yourself in a chat window. Outside that, use the free thing.

The actual commands

No signup required to try the local path; the compile happens on your machine.

Compile a YouTube video into a local bundle:

npx -y @clipy/cli@latest context import "https://www.youtube.com/watch?v=VIDEO_ID" --json

You get a directory containing recording.md (the agent-facing document, with timestamped transcript sections and an untrusted-content warning at the top), manifest.json (provenance, versions, and the sufficiency report), and transcript.json. Captions are fetched on your machine via a Clipy-managed yt-dlp that installs into ~/.clipy/bin on first use, with a disclosure; creator captions are preferred over auto-generated ones and no media is downloaded on this path.

Read the bundle as an agent would:

npx -y @clipy/cli@latest context read ./clipy-context-<hash>

Sync it to your private library, which is what enables classification and frames:

npx -y @clipy/cli@latest context import "https://www.youtube.com/watch?v=VIDEO_ID" --sync

Import a local file, which needs a caption file alongside it:

npx -y @clipy/cli@latest context import ./demo.mp4 --transcript ./demo.vtt --sync

Useful flags on context import: --language for caption language preference, --title to override the bundle title, --tag (repeatable) and --folder for filing on sync, --output for the bundle directory, --no-frames to take the classification verdict without ever downloading media, and --json for machine-readable output. Re-running the same import over the same source is idempotent, which is what makes it safe to retry a partial import.

Install the skill for your agent (claude, codex or cursor):

npx -y @clipy/cli@latest agents install claude

The one-line version

Gemini Notebook imports what was said. For a paper, a report or a panel discussion that is the whole thing, and you should use it. For a video where somebody is showing you how to do something, the words are the commentary track and the screen is the content — and a transcript is a recording of the commentary with the picture thrown away.

If that is the half you keep needing, see how Clipy turns a YouTube video into context your agent can actually read. If you want the longer explanation of why agents need visual evidence and not just transcripts, we wrote that up separately in giving agents video context.

Sources