How many deep research runs you get depends on which Gemini you are using. In the consumer app the allowance comes with your subscription plan, and Google publishes current figures on its subscription page. Through the API there is no separate research quota at all, because the underlying constraints are the standard rate limits: requests per minute, input tokens per minute and requests per day, applied per project.
That split matters more than any specific number, because the two paths fail in completely different ways and need different responses.
Key points
- Two different systems. The app meters research runs against a subscription plan; the API meters tokens and requests against a project.
- API limits are three-dimensional, and breaching any one of requests per minute, tokens per minute or requests per day produces an error.
- API limits apply per project, not per key, so adding keys does not add capacity.
- A research run is token-heavy, which means it presses on the token limit far harder than the request limit.
- Plan figures change. Check the subscription page directly rather than trusting a number in an article.
What a deep research run actually consumes
Understanding the shape of the workload explains which limit you will hit and why the app rations it separately.
A research run is not one call. It plans an approach, issues many searches, retrieves and reads a large number of pages, evaluates what it found, follows up on gaps, and then produces a long structured document with citations. Every retrieved page enters the context, and the reasoning across all of it happens before any output appears.
That produces a very particular consumption profile. The request count stays modest, because a run is a small number of long operations rather than many short ones. The token count is enormous, because a hundred retrieved pages is a great deal of text. On the API this means a research-style workload presses on the tokens per minute ceiling long before it approaches the requests per minute ceiling, which catches out anyone who sized their capacity by counting calls.
It also means the daily request ceiling is rarely the binding constraint for research work, while it frequently is for chat-style applications making many small calls. The same quota structure produces different failure modes depending on the shape of your workload.
The app path: subscription allowances
In the Gemini app the accounting is deliberately simpler, because the audience is people rather than systems.
Deep research runs are counted against your plan rather than metered in tokens, and the allowance resets on a cycle tied to the subscription. Google AI plans sit at several levels, with the Ultra tier offering the highest usage across features, and each plan bundles research alongside other capabilities such as image and video generation. Google lists what each tier includes on the subscription page, and those inclusions have changed several times as the feature developed, which is why quoting a figure here would be unhelpful.
One consequence of that bundling is worth noting. Because a single plan grants access to several features at once, heavy use of one can matter to you even if the quotas are nominally separate: a user who spends their month on image generation is a different user from one who spends it on research, and the plan that suits each is not the same. Working out which capability you actually reach for most is a better basis for choosing a tier than comparing the advertised numbers across all of them.
Two behaviours are worth knowing regardless of the number.
Unused runs generally do not accumulate. A quiet month does not fund a busy one, which argues for using the allowance rather than saving it.
A disappointing run still counts. If the brief was vague and the output missed the point, the budget is spent. That makes the few minutes spent writing a precise question the highest-return effort available, because a better brief costs nothing and a wasted run costs a meaningful share of the period’s allowance.
The API path: three limits at once
For anyone building research-style functionality rather than using the app, the constraints are the standard Gemini API rate limits and they behave independently.
| Dimension | What it constrains | Who hits it |
|---|---|---|
| Requests per minute | Call frequency | Chat applications with many short calls |
| Input tokens per minute | Total volume | Research and document-heavy workloads |
| Requests per day | Daily ceiling | Anything running continuously |
Google’s documentation is explicit that exceeding any single dimension triggers an error even when the others have headroom. Daily quotas reset at midnight Pacific time, and limits attach to the project rather than the API key.
There is also a separate spend-based control evaluated on a rolling ten minute window, set at $10 for Tier 1, $50 for Tier 2 and $200 for Tier 3, with Free not subject to it. Breaching it returns a 429 error with RESOURCE_EXHAUSTED. For research-style work this is a realistic constraint rather than a theoretical one, because the token volumes involved translate into cost quickly.
Worth noting how these interact. A single large research operation can approach the spend ceiling on its own at a lower tier, which produces a confusing symptom: the request fails despite the project sitting well inside its requests per minute and tokens per minute limits. Anyone diagnosing throttling should check the spend window as well as the throughput dimensions, because the error code alone does not distinguish them.
Why the two paths are metered so differently
The contrast is instructive, and it explains a great deal about how these products are built.
A subscription allowance is a product decision. It has to be legible to someone who does not think in tokens, predictable enough to plan around, and generous enough to feel fair while still capping what a single account can consume. Counting runs achieves all three. Nobody using the app needs to know that one research question consumed forty times the compute of another.
Rate limits are an engineering decision. They protect the service from load patterns that would degrade it for everyone, and they have to describe those patterns precisely enough for software to respond. That is why there are three dimensions rather than one, and why they are expressed in requests and tokens rather than in tasks.
The consequence for anyone choosing a path is that the app hides variance and the API exposes it. In the app, an expensive question and a cheap one both cost one run. On the API you pay for what you actually consumed, which is fairer and requires you to think about it.
Neither is better in general. The app is better when a person is deciding what to ask. The API is better when software is, because software can be made to respect a limit and a person mostly cannot.
What to know before deciding
Several things shape whether you get value from a run and which path suits you.
The brief determines the output more than the model does. A question with stated scope, timeframe and purpose produces something usable. A broad one produces a broad survey that answers something adjacent to what you wanted.
It cannot reach what is not published. Material behind logins, paywalls or inside your organisation is outside its scope unless you supply the content directly. This is the most common reason a run returns thin results on a narrow business question: the information exists, but not on the open web.
Prompt quality outweighs plan tier. A well-specified question on a lower plan beats a vague one on a higher plan, and no amount of additional quota compensates for an unclear brief.
Citations speed up verification, they do not replace it. A source that supports a claim only loosely still appears in the list, and the document reads as authoritative either way.
Runs take minutes. Starting one and doing something else is the sensible pattern rather than waiting.
Preview models carry tighter limits. If you built against a preview model, that alone may explain throttling that a stable model would not produce.
Getting more out of each run
- State the decision the research informs. This single sentence changes the output more than any other instruction.
- Give scope explicitly: which markets, which period, which kinds of source you trust.
- Say what you already know so the run does not spend its budget re-establishing your starting point.
- Name the output shape you want, whether a comparison table, a chronology or a set of options.
- Ask for weak sourcing to be flagged. Most people never request this and it is the most useful line in a brief.
- Set a length expectation. Without one you tend to get maximum length rather than maximum density, and a shorter report you actually read beats a longer one you skim.
- Exclude what you do not want. Ruling out whole categories saves budget and sharpens what comes back, and it is easier to specify than what you do want.
Decision framework
Five questions before starting a run or building on the API.
- Would one authoritative source answer this? Vendor documentation and official statistics do not need a research run, and spending one on them is the most common waste.
- Does the answer require synthesis across many sources? That is the case where the cost is justified.
- App or API? Interactive work by one person belongs in the app. Anything unattended, repeated or embedded in a product belongs on the API.
- Which limit will your workload hit? Research-shaped work presses on tokens per minute; chat-shaped work presses on requests per minute.
- Do you have time to verify the output? An unverified research document that reads authoritatively is a liability rather than an asset.
Knowing which tool fits which question, and how to brief it so the result is checkable rather than merely plausible, is a skill rather than a product feature. If you want a structured route in, explore Coursiv AI lessons and check current plan details on the official site.
Your next step
If you use the app, write your next brief in three sentences before starting anything: the decision you are making, what you already know, and what shape of answer would help. Then ask whether one well-chosen search would answer it, because a surprising share of the time it would.
One habit worth adopting either way. Keep the briefs that produced good results. Research questions repeat more than people expect, and a brief that worked once is a template for the next one in the same shape. Teams that do this build up a small library within a few months and stop rewriting the same instructions from scratch, which raises the average quality of every run rather than just the ones where somebody was being careful.
If you are building on the API, add logging for tokens per minute specifically. Teams sizing research workloads by counting requests consistently underestimate what they need, and the failure arrives in production rather than in testing.