TL;DR (June 2026): Since April 1, 2026, every Gemini API billing account has a mandatory monthly spend cap tied to its usage tier: roughly $250/month on Tier 1, $2,000 on Tier 2, and $20,000 to $100,000+ on Tier 3. The caps cannot be disabled, and they are enforced the hard way: hit yours and every Gemini API request on that billing account pauses until the next billing cycle. New users are onboarded onto prepaid billing, tier qualification is based on cumulative Google Cloud spend, and as of June 1 the Gemini 2.0 Flash models are deprecated. If your product runs on Gemini, your tier is now a production dependency, this page is the operating manual.
Google spent 2025 being the generous one: huge free tiers, loose limits, the easiest on-ramp in the business. 2026 Google is running the same playbook as everyone else in the Tokenpocalypse, and its version has a distinctive sharp edge: instead of overage bills, hard stops. The April tier-cap enforcement turned "how much could we spend on Gemini this month?" from a budgeting question into an availability question, and the r/Bard threads of confused developers ("getting Free Tier rate limits on a Tier 1 account") show how few teams have internalized it. Here is the full picture, and the playbook.
The tier system, as it works now
| Tier | Monthly spend cap | How you qualify | What hitting the cap does |
|---|---|---|---|
| Free tier | $0 (no billing) | No billing account attached | Per-model RPM/RPD limits throttle you |
| Tier 1 | ~$250 | Billing enabled | All requests pause until next cycle |
| Tier 2 | ~$2,000 | Cumulative Google Cloud spend threshold | All requests pause until next cycle |
| Tier 3 | ~$20,000 to $100,000+ | Higher cumulative spend threshold | All requests pause until next cycle |
Four mechanics matter more than the numbers:
- The caps are mandatory. There is no toggle, no "raise my limit" checkbox, no credit card you can wave at it mid-month. The cap is a property of your tier, and your tier is a property of your spending history.
- Enforcement is account-wide. The cap applies to aggregate spend across all projects tied to the billing account. Your experimental side project and your production API share one ceiling, which is an architecture decision most teams made before it mattered.
- The failure mode is a pause, not a bill. Hitting the cap stops requests until the next billing cycle. For a hobbyist that is a courtesy; for a production service it is an outage with a calendar-shaped recovery time.
- Tier upgrades follow cumulative Google Cloud spend, not a request form. Qualification counts total spending on the billing account (Gemini and other GCP services), so young accounts with big ambitions are structurally capped until their spending history catches up.
Why Google chose hard stops
Read charitably, this design is consumer protection scaled up: nobody on Tier 1 wakes up to a $40,000 surprise, the failure is loud and bounded, and the budget-bomb stories that haunted 2025-26 cannot happen inside a capped account. Read strategically, it is also revenue discipline: free-and-loose tiers lose money (the same gravity we examined in the subsidy question), and tier ladders that follow demonstrated spend convert enthusiasm into qualification pressure. Both readings agree on the practical consequence: Google has made your spending ceiling part of your application's reliability model.
The production playbook
- Find your tier and cap today. Not when the pause hits. Check the billing account in Cloud Console / AI Studio, and write the number into your runbook next to your rate limits, because it behaves like one: a monthly-granularity rate limit denominated in dollars.
- Alert at 60% and 85% of cap, on a burn-rate basis. A flat threshold alert fires too late if usage is accelerating. What you want is "at current burn we exhaust the cap on the 22nd", which requires daily spend tracking against the cap, exactly the meter-against-budget pattern that every capped resource needs. If your spend lives in a metering layer with webhooks, this is an afternoon of work.
- Decide the pause policy before the pause. When the cap nears: throttle the expensive paths (drop to Flash-Lite, shrink contexts, disable enrichment features) to stretch the remaining budget, or fail over to a second provider for the tail of the month, or accept degradation explicitly. Any of these beats discovering the question at 2 a.m. on the 26th.
- Separate billing accounts by criticality. Because enforcement is account-wide, production and experimentation sharing an account means a runaway experiment can pause production. A dedicated billing account for production Gemini traffic is the single cheapest reliability upgrade this policy offers.
- Plan tier upgrades like capacity, with lead time. If your growth curve crosses your cap in Q3, the cumulative-spend qualification means the upgrade has to be earned in Q2. Teams have started front-loading workloads onto the billed account specifically to build qualification history, legitimate, but only if you plan it.
- Mind the June 1 deprecation while you are in there. Gemini 2.0 Flash and 2.0 Flash-Lite are deprecated as of June 1, 2026; anything still pinned to them needs migrating to 2.5 Flash or 3.1 Flash-Lite, and the migration changes your cost profile (see the cost-quality comparison) which changes your burn rate, which changes your cap math. Do the arithmetic as one exercise.
The free-tier and prepaid edges
Two adjacent changes complete the picture. New users now start on prepaid billing: you load credit before you spend it, which kills the classic "attach a card and discover the bill later" path and means a new project's first scaling moment involves a manual top-up unless you automate it. And the free tier remains its own world, with the per-model rate limits and the enable-billing-loses-free-tier trap we documented in the free-tier guide, still the most-read page on this site, and still the thing most people get wrong first. The combined system is coherent: free tier for evaluation, prepaid Tier 1 for first production dollars, earned tiers for scale, and a hard ceiling at every step.
How this compares to the other providers
The contrast is instructive. Anthropic's tiers raise rate limits with spend but bill overage rather than pausing; OpenAI offers configurable budget caps that you choose; GitHub's AI credits stop service per-seat when exhausted unless overflow is enabled. Google's design is the strictest of the four: involuntary caps with account-wide hard stops. If your stack spans providers, that asymmetry belongs in your failover logic: Gemini is the provider whose failure mode is a scheduled outage, which makes it simultaneously the safest from surprise bills and the most demanding of proactive budget engineering.
The honest take
Mandatory spend caps are the most honest pricing mechanism the AI industry has shipped: the bill literally cannot surprise you. The cost of that honesty is transferred to operations: your budget is now an SLO, exhausting it is an outage class, and the burn-rate dashboard your finance team wanted is now something your on-call engineer needs. Teams that already meter per-task and alert on burn rate will find the caps almost relaxing. Teams that watch the invoice monthly will meet their cap the way everyone meets a hard limit they did not monitor: suddenly, and at the worst possible time of the month.