Google Cloud has made spend caps generally available on its Cloud Billing Budgets platform, allowing customers to halt new usage of a service within a project once a monthly budget threshold is reached, all without removing existing resources. The feature, which moved from public preview to general availability this month, adds API access, estimated live costs that activate caps within minutes for AI services, and automatic monthly resets. However, enforcement remains restricted to just four services: Gemini API, the Gemini Enterprise Agent Platform, Cloud Run, and Cloud Run functions.
A spend cap functions as a budget paired with enforcement mechanisms. When estimated spend on the covered service hits the target amount, new requests to that service in that project are blocked, in-flight requests continue to completion and are billed, persistent resources remain active, and nothing gets deleted, according to Google's documentation. Usage covered by committed-use discounts pauses alongside pay-as-you-go usage, though Provisioned Throughput for AI models is never stopped. Billing administrators and project owners receive alerts at 50, 80, and 100 percent of the cap. The scope is highly specific: a cap covers one project and one service for a calendar month, meaning folders, organizations, labels, and multi-service budgets fall outside the feature's reach, as do reseller accounts and subscription charges such as Gemini Enterprise seats.
Google implemented three changes between the July public preview and general availability. Caps can now be created, removed, and deleted through the existing Cloud Billing Budgets API, which the company recommends integrating into project provisioning so a new sandbox receives a cap upon creation. Enforcement for AI services now operates on estimated live costs displayed in Cost Reports rather than on settled billing data, which can delay by hours. A triggered cap resets automatically at the beginning of the next month; during preview, the block remained in place until someone manually lifted it in the console, an option that still exists. The estimate driving enforcement is calculated at list price and excludes credits and discounts, and enforcement isn't instantaneous—the documentation states that "any cost overages are billed as normal" and recommends setting the cap "slightly below your absolute limit."
The limited service eligibility has drawn criticism, particularly because Compute Engine, Cloud Storage, and networking aren't among the supported services, meaning the cap addresses a runaway model or agent loop but not a forgotten GPU instance. 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 pauses the entire project and stops its resources when reached, preserving data for 90 days, though AWS is rolling out the feature to a limited number of customers only. 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. Google positions spend caps alongside early anomalies—a daily baseline model that flags directional cost variances per service and identifies the top SKUs behind a spike—as the detection and control halves of the same loop, both configured from the Budgets and Alerts page in the Billing console or through the Budgets API. The tension between cloud revenue models and customer cost predictability will likely intensify as AI workloads grow more autonomous and unpredictable, forcing providers to choose between protecting margins and preventing customer churn from bill shock.