Gemini rate limits span three dimensions plus a spend-based layer most teams miss. Here is how RPM, TPM, RPD, and per-tier spend caps actually work.
Google does not publish a static table of per-model Gemini rate limits. The numbers live inside Google AI Studio, they shift as your tier and account status change, and the documentation states plainly that "specified rate limits are not guaranteed and actual capacity may vary."
That alone causes confusion. But the bigger problem is the limit that is easy to miss when planning: a spend-based rate limit, assessed over a 10-minute period, that can return a 429 before you come anywhere near your RPM or TPM ceiling. Understanding how these layers interact is what separates a smooth production integration from one that hits RESOURCE_EXHAUSTED errors on its first real traffic spike.
Gemini rate limits are measured across three independent dimensions: requests per minute (RPM), tokens per minute for input (TPM), and requests per day (RPD).
The key word is independent. Exceeding any single dimension triggers a rate limit error, even if the other two are well within bounds. If your RPM limit is 20 and you make 21 requests in a minute, you get an error regardless of your token usage.
RPM is the dimension you notice first. TPM and RPD are the ones that surprise you, because RPD quotas reset at midnight Pacific time. For teams east of UTC that reset lands in the local afternoon or evening, so plan your daily allocation around the reset point, not your local midnight.
On top of RPM, TPM, and RPD sits a fourth constraint that does not fit neatly into the "requests and tokens" mental model. The Gemini API enforces spend-based rate limits to protect against unexpected charges, assessed over a 10-minute period.
The caps per tier:
| Usage tier | Spend rate limit (per 10 min) |
|---|---|
| Free | N/A |
| Tier 1 | $10 |
| Tier 2 | $200 |
| Tier 3 | $200 |
If you hit this limit, the API returns a 429 RESOURCE_EXHAUSTED error. Unless you are tracking your spend separately, a spend-cap 429 is easy to misattribute to request volume.
Long-context calls with large input payloads are the fastest way to approach a $10-per-10-minute ceiling on Tier 1; check current token pricing against your payload sizes. If you are seeing intermittent 429s that do not correlate with your request volume, this is the first thing to rule out. For a breakdown of what those calls actually cost, see Gemini API pricing.
A common workaround attempt: generate multiple API keys and distribute requests across them. It does not work. Rate limits are applied per project, not per API key. Every key within a Google Cloud project shares the same quota pool. Creating five keys gives you five credentials pointing at the same counter.
The only way to get separate quotas is separate projects. That comes with its own overhead (billing accounts, IAM configuration, key management), and you still share the same tier qualification across a billing account.
Gemini structures access into four tiers. Each tier unlocks higher rate limits and a higher billing tier cap.
| Tier | Qualification | Billing tier cap |
|---|---|---|
| Free | Active project or free trial | N/A |
| Tier 1 | Link an active billing account | $250 |
| Tier 2 | $100 cumulative paid + 3 days since first payment | $2,000 |
| Tier 3 | $1,000 cumulative paid + 30 days since first payment | $20,000 to $100,000+ |
Two details that matter here.
First, the qualification thresholds for Tier 2 and Tier 3 are based on total cumulative Google Cloud spending, not just Gemini API spend. Compute Engine, BigQuery, Cloud Storage: it all counts. A team already running GCP infrastructure may qualify for Tier 2 or 3 immediately.
Second, upgrades happen automatically as your spending increases. No form to fill out, no sales call. Though the documentation notes that "in rare cases an upgrade request may be denied based on other factors identified during the review process."
If you have looked for a table listing "Gemini 2.5 Pro: 1,000 RPM, 4M TPM" and come up empty, that is by design. Google's documentation states that rate limits depend on a variety of factors including your usage tier, and can only be viewed in Google AI Studio. They update automatically as your tier changes.
Experimental and preview models get tighter limits than stable models. If you are testing a newly released model, expect lower ceilings than what you see on the stable variant.
The practical consequence: you cannot plan capacity from documentation alone. Log into AI Studio, check your current limits for each model you use, and build your retry logic around those numbers, not around figures from blog posts or community forums that may reflect a different tier or a different point in time.
Two additional rate limit regimes apply to specific access patterns.
Priority inference carries its own rate limits at 0.3x the standard rate limit for each model and tier. If your standard RPM is 1,000, priority inference caps at 300 RPM. Priority consumption counts towards your overall interactive traffic limits, so it also eats into your standard quota.
Batch API has entirely separate limits: 100 concurrent batch requests, a 2 GB maximum input file size, and 20 GB of file storage. Batch also enforces per-model enqueued token caps. These limits do not interact with your interactive rate limits, making batch a viable path for high-volume offline workloads that do not need real-time responses.
Three paths, in order of effort.
Wait and retry. The simplest response to a 429. Implement exponential backoff. The short windows (per-minute, per-10-minute) mean a brief pause is often enough.
Reduce per-request cost. Smaller context windows and shorter outputs reduce both your token consumption and your spend velocity. If you are sending 100K-token contexts when 20K would suffice, you are burning through your spend-based rate limit four times faster than necessary.
Spend into a higher tier. Tier upgrades are automatic. If you are on Tier 1 and consistently hitting the $10/10-minute spend cap, reaching $100 in cumulative GCP spend and waiting 3 days gets you to Tier 2 with a $200/10-minute cap. Reaching $1,000 cumulative and 30 days gets you Tier 3. For teams already committed to GCP, this is the most reliable path to higher throughput.
If none of these resolve your constraints, the documentation links to a rate limit increase request form for paid tiers. No guaranteed outcome, but it exists as an option for production workloads that have outgrown the tier system.
shim preserves Gemini's native request and rate-limit behavior. It does not pool provider capacity, add semantic caching, or fall back to another provider on a 429; handle those policies in the application.