Jorge Turbica / blog · Blog ← All articles ES · Leer en español
Cloud

Google Cloud spend caps hit GA: AI usage stops within minutes, nothing gets deleted

Spend caps are GA with an API and monthly reset: they block one service in one project at the limit. Provisioned Throughput keeps running.

An infinite loop hammering the Gemini API no longer has to end in a surprise bill: since October 30, 2026, Google Cloud Budgets spend caps are generally available and, for AI services, they cut usage off within minutes of hitting the limit. They delete no resources or data, can be managed through an API and now reset themselves every month.

What GA brings

Spend caps were announced in private preview on April 22, 2026 and moved to public preview on July 28. A cap is a budget with teeth: when a service's accumulated spend inside a project reaches the figure you set, Google Cloud blocks billable usage of that service in that project. Other services and projects are left alone.

GA adds three things to the preview:

  • An API: caps are managed through the existing Cloud Billing Budgets API, so you can create, lift, update or delete them in code, for instance whenever a new sandbox project is created.
  • Estimated costs in Cost Reports: AI caps trigger on live estimated costs, and those figures now show up in Cost Reports. You can see exactly which usage tripped the block without waiting hours for billing data to settle.
  • Automatic monthly reset: previously, a triggered cap kept the service blocked until someone lifted it by hand in the console. Now it resets at the start of the month and the service resumes. Teams whose governance requires a manual review before resuming can keep doing that.

During public preview, caps covered the Gemini API, Agent Platform, Cloud Run and Cloud Run Functions; the GA announcement talks about "eligible services" without restating the list, so check the documentation before relying on any other service.

What stops and what keeps billing

The GA announcement spells it out: a cap halts pay-as-you-go requests and CUD-covered ones too. What never stops is Provisioned Throughput: requests using reserved capacity keep serving normally. Fixed commitment fees also keep billing at their contractual rate, since they are a contract rather than usage.

By default, billing administrators and project owners get alerts at 50%, 80% and 100% of the cap. Spend cap permissions can be added to custom roles.

A round-number example: an agent sandbox with a USD 200 monthly cap on the Gemini API alerts at 100, 160 and 200 dollars. If an agent loops on the 12th and burns the budget in an afternoon, its calls start failing within minutes of reaching USD 200, the project stays intact, and on the 1st of the next month it works again on its own.

Setting your first one

From the console:

  1. Open Billing → Budgets & alerts for the billing account.
  2. Create a budget and pick the Spend cap type, scoped to a project and a service.
  3. Set the monthly amount and check who holds the roles that receive the alerts.
  4. If the cap trips and you need to resume before month end, lift it from the same page with Lift spend cap.

At scale, the route is the Cloud Billing Budgets API: the natural place for a cap is the template you use to create development projects, next to the labels and the VPC.

Compared with what came before

Until now Google Cloud would warn you but not stop you. Google itself acknowledged in April that many companies had built their own guardrails out of destructive actions, such as detaching the payment method from the billing account, which takes down the whole project and is slow to undo. A cap is surgical: one service, one project, nothing deleted, one click to reverse. The trade-off is that it only works for eligible services; everywhere else, a classic budget is still just an alert.

Gotchas

  • The automatic reset brings the problem back too. If the cap tripped because of a looping agent or a leaked key, the service and the spend both return on the 1st. In those projects, stick with manual lifting.
  • A cap in production is a scheduled outage. It does exactly what it promises: requests fail. Google recommends starting with sandboxes, test environments and agent playgrounds, and that is the right place.
  • Provisioned Throughput is not a brake. If your big spend is reserved capacity, the cap will not stop it.
  • Minutes apply to AI. Near real-time triggering is announced for AI services, the ones that use live estimated costs.

Sources

Jorge Turbica

Software Engineer and SRE. I write about the real challenges I run into in production.

See portfolio ↗