Gemini enforces limits along three dimensions at once, and exceeding any one of them produces an error even if you are well inside the others. Google’s documentation lists them as requests per minute, input tokens per minute and requests per day, applied per project rather than per API key, with the daily quota resetting at midnight Pacific time.
Most people who hit a limit unexpectedly have been watching the wrong dimension. Understanding which three exist, and that they are evaluated independently, removes almost all of the surprise.
Key points
- Three limits run simultaneously: requests per minute, input tokens per minute, and requests per day.
- Breaching any one triggers an error, regardless of headroom on the others.
- Limits apply per project, not per key. Adding keys does not add capacity.
- Daily quotas reset at midnight Pacific time, which is worth knowing if you are elsewhere.
- Spend-based limits exist separately, evaluated on a rolling ten minute window and tied to your usage tier.
The three dimensions, and why they behave differently
Each limit constrains a different kind of workload, and knowing which one you are close to tells you what to change.
Requests per minute. Constrains how frequently you can call, independent of size. Applications making many small calls hit this first, and the fix is batching or queueing rather than reducing content.
Input tokens per minute. Constrains total volume. Applications sending large contexts hit this even at a modest request rate, and the fix is trimming what you send rather than calling less often.
Requests per day. A ceiling on total daily volume regardless of how evenly you spread it. This one catches people out because the system behaves normally all morning and then stops.
Google’s own illustration is precise on the interaction: if your per-minute request limit is 20, a twenty-first request inside that minute fails even when your token usage is nowhere near its ceiling. The dimensions do not trade against each other.
Some models add further limits. Image generation models such as Nano Banana are metered on images per minute, conceptually similar to tokens per minute but counting outputs. Certain models also carry a tokens per day ceiling. Experimental and preview models are documented as more restricted than stable ones, which matters if you built against a preview and then scaled.
Per project, not per key
This detail catches teams out regularly and deserves stating on its own.
Rate limits attach to the project, so generating additional API keys within the same project does not increase available capacity. A team that splits work across several keys to avoid throttling will find the limits unchanged, because all those keys draw on the same pool.
The practical implication is that quota planning is a project-level decision. If separate workloads genuinely need separate capacity, they need separate projects, and that has consequences for billing and administration worth thinking about before you need it.
Why three limits instead of one
The design makes more sense once you see what each protects against, and it is a pattern worth recognising because most platforms converge on something similar.
A single limit cannot describe two very different failure modes. A thousand tiny requests per second and one enormous request both strain a service, but they strain different parts of it. Request rate protects the front of the system, where each call carries fixed overhead regardless of size. Token rate protects the expensive part, where cost scales with volume. Neither substitutes for the other.
The daily ceiling serves a third purpose. Per-minute limits stop a burst, but they do nothing about sustained load that stays just under the threshold all day. Requests per day caps total consumption for a tier, which is what makes free and low tiers economically viable to offer at all.
Understanding this makes the limits feel less arbitrary. It also predicts which one you will hit: chat applications with many short exchanges hit the request ceiling, document processing hits the token ceiling, and anything running continuously in the background hits the daily one.
Spend-based limits
Alongside the throughput limits, Google enforces a separate control designed to prevent unexpected charges rather than to manage load.
| Usage tier | Spend rate limit per 10 minutes |
|---|---|
| Free | Not applicable |
| Tier 1 | $10 |
| Tier 2 | $50 |
| Tier 3 | $200 |
These are evaluated on a rolling ten minute window, and whether they apply depends on your billing history and account standing. Exceeding one returns a 429 error with RESOURCE_EXHAUSTED.
The documented remedies are worth knowing, because each points at a different cause. Waiting and retrying handles a transient spike. Making your costly calls less often, whether by cutting the amount of context you send or by capping how long the answers run, addresses a workload that is structurally too expensive for its tier. And if you hit the ceiling repeatedly during ordinary use, that is the situation where asking for an increase is the right move rather than a workaround.
Tiers advance automatically based on cumulative spending across Google Cloud services on the linked billing account, not on the Gemini API alone. That is a useful detail for anyone whose organisation already spends on Google Cloud, because it may place a new project higher than expected.
It cuts the other way too. A team starting fresh with a new billing account begins at the bottom regardless of how much the wider organisation spends elsewhere, and there is no way to shortcut that with a purchase. Anyone planning a launch that needs throughput from day one should establish the billing relationship well in advance rather than discovering the constraint during rollout.
What to know before deciding
Several things affect how you should design around these limits rather than react to them.
The error does not say which limit you hit, at least not in a way that survives casual logging. Recording your own request rate and token volume alongside failures is the only reliable way to know what to fix.
Daily reset timing matters for scheduled work. Midnight Pacific is mid-morning in Europe and afternoon in Asia. A nightly batch job scheduled in local time may land on either side of the reset depending on the season.
Preview models are not a safe base for production. Their limits are documented as more restrictive, and both the limits and the model itself can change.
Smaller contexts help two limits at once. Trimming input reduces token consumption and lowers the cost of each request, which eases both the token ceiling and any spend-based constraint.
Capacity is not something you can buy instantly. Tier advancement follows spending history, so a workload that needs high throughput on day one needs planning rather than a support request.
Practical steps when you are being throttled
- Log all three dimensions yourself. You cannot fix a limit you have not identified, and the failure alone will not tell you.
- Add retry with backoff. Transient throttling is normal at scale and should not surface as a user-facing failure.
- Queue rather than parallelise. Firing many concurrent requests is the fastest way to breach a per-minute ceiling.
- Trim context before adding capacity. It is free, immediate, and frequently sufficient.
- Move tolerant work off peak. Spreading load across the day keeps you under per-minute limits without reducing total volume.
- Check the model you are on. A preview model with tighter limits is a common and easily fixed cause.
Limits inside the Gemini app versus the API
The two are metered differently, and conflating them causes a good deal of confusion.
Everything described so far applies to the Gemini API, where you hold a project, a billing account and a usage tier. The consumer Gemini app works on a subscription instead, with allowances attached to the plan rather than to requests per minute. Google publishes those on its subscription page, and they change often enough that checking directly beats trusting a figure quoted elsewhere.
The practical differences matter if you are deciding which to use. The app handles the interface, conversation history and file handling for you, and the limits are expressed in terms a person can reason about, such as how many of a given kind of request per period. The API gives you control over the model, the context and the cost structure, and the limits are expressed in machine terms.
There is also a difference in how a limit feels when you reach it. In the app you are told you have reached a cap and offered an upgrade or a wait. In the API you receive an error code that your own software has to handle gracefully, which is more work but also more predictable.
Choosing between them is less about capacity than about who handles the complexity. A workflow that one person runs interactively belongs in the app. Anything that runs unattended, at volume, or inside another product belongs on the API, where the limits are documented precisely enough to design around.
Decision framework
Five questions when limits are getting in the way.
- Which dimension are you actually hitting? Requests, tokens or the daily ceiling need three different responses.
- Are you on a stable or preview model? Preview limits are tighter, and switching may resolve the problem outright.
- Is the work time-sensitive? If not, spreading it across the day removes per-minute pressure entirely.
- Can the context be smaller? This helps throughput and cost simultaneously and is usually the cheapest fix available.
- Do these workloads genuinely need to share a project? Since limits are per project, separating them is the structural answer when they compete.
Understanding how a platform meters usage, and designing around it rather than discovering it in production, is a general skill rather than a vendor-specific one. If you want a structured route in, explore Coursiv AI lessons and check current plan details on the official site.
Your next step
Before changing anything, add logging that records your requests per minute, input tokens per minute and daily request count. Then look at what the numbers were in the minute before each failure.
Most throttling problems turn out to be a single dimension, and it is frequently not the one people assume. Teams that guess tend to reduce the wrong thing and keep hitting the same ceiling, while teams that measure usually find a fix that costs nothing.