Google Cloud has made spend caps generally available on Cloud Billing Budgets, letting customers new usage of a service in a project once a monthly budget is reached, without deleting resources. The GA release adds an API, estimated live costs that trigger caps within minutes for AI services, and automatic monthly resets, but enforcement remains limited to Gemini API, the Gemini Enterprise Agent Platform, Cloud Run, and Cloud Run functions.
A spend cap is a budget with enforcement attached: according to the documentation, when estimated spend on the capped service reaches the target amount, new requests to that service in that project are blocked, in-flight requests run to completion and are charged, persistent resources keep running, and nothing is deleted. Usage covered by committed-use discounts is d along with pay-as-you-go usage, while Provisioned Throughput for AI models is never halted. Billing administrators and project owners receive alerts at 50, 80, and 100 percent of the cap.
The company changed three things between the July public preview and the GA release:
- Caps can now be created, lifted, and deleted through the existing Cloud Billing Budgets API, which the company suggests wiring into project provisioning, so a new sandbox gets a cap on creation.
- Enforcement for AI services now runs on estimated live costs shown in Cost Reports rather than on settled billing data, which can lag by hours.
- A triggered cap resets automatically at the start of the next month; in preview, the block stayed in place until someone lifted it in the console, an option that remains.
(Source: Google blog post) The limits are as specific as the features: a cap covers one project and one service for a calendar month, so folders, organizations, labels and multi-service budgets are out of scope, as are reseller accounts and subscription charges such as Gemini Enterprise seats. The estimate that drives enforcement is calculated at list price and excludes credits and discounts. Enforcement is also not instant: the documentation states that "any cost overages are billed as normal" and advises setting the cap "slightly below your absolute limit." Compute Engine, Cloud Storage, and networking are not among the eligible services, which means the cap addresses a runaway model or agent loop and not a forgotten GPU instance.
The narrower scope drew criticism when the preview expanded in October. On a Hacker News thread, one commenter who had asked Google for the capability a year earlier to control AI spend called the result "very crude, not granular like the rich IAM system," noting the four-product, month-only design. Another observed that Cloud Run had been added that morning, so the service list was still growing.
Developer Simon Willison argued in October that pay-by-usage services should default to hard caps, because coding and personal agents make it far easier to spin up code that calls paid APIs, and that "most businesses and individuals would prefer errors to a surprise $10,000+ bill." He cited Google's caps alongside a project-level spend limit in AWS's new account experience, which s the whole project and stops its resources when reached, preserving data for 90 days, and which AWS is rolling out to a limited number of customers. Azure's spending limit remains confined to free accounts and credit-based subscriptions; Microsoft states it isn't available for subscriptions with commitment plans or with pay-as-you-go pricing.
Spend caps pair with early anomalies, a daily baseline model that flags directional cost variances per service and names the top SKUs behind a spike, which Google positions as the detection half of the same control loop. Both are configured from the Budgets and Alerts page in the Billing console or through the Budgets API.