Your Questions With Gemini Notebook Just Got a Meter

As of today, Google charges Gemini Notebook (formerly NotebookLM) users per question. On September 2 the app moved from daily per-feature counts to a compute quota that resets every five hours and is consumed by prompt complexity, chat length, the number of sources, and the features you use (blog.google, August 27). Plus gets 2x the standard quota, Pro 4x, Ultra 5 to 20x.

This is not the first time Google is making such a change. The Gemini app made the same change in May. Users hit the limits inside single prompts, Google adjusted within about nine days, and the metering stayed. And in the threads about this week's change, the top comment on the NotebookLM subreddit says transparent limits beat silent model downgrades, and it is right. Metering is not the villain of this story.

The unit is.

What the meter actually measures

Gemini Notebook indexes your sources once, when you upload them. It chunks and embeds them and builds a passage index. Each question then retrieves the matching passages and sends those to the model. The work of understanding your material happens once. But the quota is consumed partly by the number of sources and partly by the length of the conversation, so a question over a bigger notebook costs more than the same question over a smaller one, and the tenth question in a session costs more than the first, not because the material changed, but because the amount of information processed per question grew, and more tokens got consumed. That is Prompt Debt with a price tag on it, and the price tag is the honest part. I wrote about Prompt Debt in Nadella Says You're Paying Twice: the hidden tax of re-feeding the same context every session. Google has now priced that tax explicitly, per five hours, with source count as a cost input.

I have felt this from the other side. Over my two decades of career, I have a few hundred PDFs, notes, and client briefs, MBA class notes, etc. scattered across folders. Every new session meant dragging in the same ten files, pasting the same preamble, and hoping the model remembered what mattered. It never did. The re-feeding was not a one-time setup cost. It was the whole way of working, repeated every time I opened a chat window. The tokens were the visible part. The attention I spent reconstructing context I already owned was the part nobody put on an invoice. Tools like Gemini Notebook or Claude Projects simplify this to an extent, but I needed to be aware of how large the data set would be or identify the specific files I could upload.

The other unit

The alternative unit is the archive. Process the material once. Reconcile the vocabulary that drifted across years of your own writing and build the knowledge layer. Then the price of a question is the price of a lookup, not the price of re-reading everything you have ever written. And a question can reach the whole archive, not just one notebook.

That is the unit Elicana is built on. Let me be precise about what it does and does not buy.

With local models, the only quota is your own hardware. A big archive compiles slowly, and that is the trade you make. With a frontier model on your own key, you pay your provider per token for the question, and the compile costs tokens once; the price is flat on your hardware or your key, not metered by the number of sources. Elicana is in beta right now and it is $20 a month flat. There are no source caps, because sources are compiled, not re-read. And the answer comes from your documents with the passage cited.

Google is not wrong. The unit is.

I am not arguing that Google got this wrong. Transparent limits are better than silent downgrades, and the "generate later" option is a reasonable concession. The complaint is not that they meter. It is that they meter the wrong thing. They are charging for the size of the archive because the archive has to be accounted for, in compute, during every interaction. The better unit handles the archive once.

Think about what the metering actually rewards. A notebook that prices each question partly by the number of sources makes a big notebook expensive to ask, even though the material was indexed once and nothing about it changed between questions. The documents did not get harder to read. The model did not get slower. The only thing that changed is that you asked again, over a larger archive. A pricing model built on that is pricing the repetition, not the knowledge. The knowledge was already there, compiled or not; the repetition is the part that should be free. None of this makes Google irrational. On my consulting blog I mapped why every AI feature carries a recurring cost that grows with something, usage, seats, data, or session length, and why vendors eventually have to meter it (The AI Cost Stack Nobody Maps). Google is doing what the cost stack forces. The question for you is only whether the thing that grows should be your bill.

So the decision is yours, and it is narrower than it looks. For a quick question over a single paper, a notebook is still the right tool. For years of your own documents, the question is the wrong unit to price.

Related

• Nadella Says You're Paying Twice, the Prompt Debt argument this builds on
• The AI Cost Stack Nobody Maps, the vendor-side economics that force metering (my consulting blog)
• Why AI Tools Fail at Your Document Archive, why retrieval breaks on real archives, and why the problem lives upstream of the model