Google Capped the Gemini Bill. Provisioned Throughput Keeps Running.

Google will now stop your Gemini calls when the bill reaches a number you set. It will not stop the disk behind those calls, and it will not stop the capacity you already reserved.

Spend caps left preview and went generally available on 30 October, per the Cloud blog. You attach a cap to a Cloud Billing budget, name one eligible service, and the platform pauses new usage for that service when estimated cost crosses the cap. Alerts fire at 50, 80 and 100 percent.

Four services qualify, and the scope is one project each

The eligible list is short. Gemini API, Gemini Enterprise Agent Platform (the former Vertex AI), Cloud Run and Cloud Run functions. The Cloud Billing documentation is blunt about the limits. A cap is scoped to a single project and a single eligible service within it.

That scope is the design. A cap on Cloud Run leaves the rest of the project alone, so nobody should read the announcement as an account level ceiling. Finance teams that do will meet the difference on the next invoice.

Google suggests rolling caps out on developer sandboxes, test clusters and agent playgrounds first. That ordering is the most honest description of the feature. It is a fuse for a workload nobody is watching, not a planning tool.

The meter reads list price, and the reservations never stop

Enforcement runs on gross estimated cost calculated from list price. Committed use discounts, credits and private pricing do not change when the fuse blows, so the cap fires earlier than a settled invoice would suggest. For a safety control that is the right direction. For quarterly modelling it is misleading.

Three exceptions decide whether the cap actually protects you. Requests already in flight are processed to completion and accrue charges. Fixed usage on persistent resources keeps running, so disks and attached compute keep billing while the service is dark. And the blog states plainly that Provisioned Throughput is never halted, which means reserved capacity keeps serving traffic and keeps charging after the cap trips.

If a meaningful share of your AI spend sits in reserved capacity, a spend cap is not a ceiling on that share. It is a ceiling on the rest of it. Measure the split before anyone promises a hard limit to a board.

The API is the part worth deploying this week

General availability added programmatic control. Caps can be created, lifted, updated and deleted through the Cloud Billing Budgets API, which turns a policy into something a platform team can enforce at project creation instead of remembering. Give every new sandbox a small cap in the same workflow that creates it.

Monthly resets are automatic now, and the manual approval step remains for teams that want an audit before traffic resumes. Alert roles matter as much as the threshold. Defaults go to billing administrators and project owners, so check who actually holds those roles before the first trip at 80 percent.

Pair caps with Early Anomalies Detection, Google’s daily predictive alerting, and you get a warning plus a hard stop. Neither replaces a cost model. Both shorten the gap between a runaway job and the person who can kill it. The same arithmetic shows up one layer down, where the KV cache decides who can afford to serve a large model at all.

Three questions for your own estate

Which services on your bill could run away without a human in the loop? Which of your AI workloads buy capacity a cap cannot touch? And who receives the alert at 80 percent, and can that person actually stop the workload?

A fuse on four services is a good answer to an agent that loops overnight. It is a poor answer to a platform budget, and Google’s own documentation stops short of claiming otherwise. Our earlier piece on why the Kubernetes bill is an architecture problem still applies. A cap ends the incident. It does not change the design that caused it.