Spend caps появились в preview раньше и за это время получили три изменения, которые Google называет прямым следствием отзывов клиентов. Главное — лимит останавливает плату за использование, но не удаляет ресурсы: данные и конфигурация остаются на месте.
Что нового
API для spend caps. Управлять лимитами вручную по сотням проектов неудобно, поэтому появился API в составе существующего Cloud Billing Budgets API. Через него можно программно ставить, поднимать, менять и удалять лимиты для поддерживаемых сервисов в проекте — например, автоматически вешать строгий cap на каждый новый sandbox-проект разработчика.
Живые отчёты о стоимости. Для AI-сервисов cap срабатывает через минуты по оценочным текущим расходам. Теперь эти цифры видны в Cost Reports: не нужно ждать, пока стандартный биллинговый конвейер сведёт net-стоимость, чтобы понять, что именно и когда превысило порог.
Автоматический сброс. Раньше после срабатывания блокировка держалась, пока её не снимут вручную. Теперь enforced caps сбрасываются в начале следующего месяца, и заблокированные сервисы возобновляют работу. Ручной override остался для тех, у кого политика требует аудита перед возобновлением.
Что учесть
Алерты по умолчанию уходят биллинг-администраторам и владельцам проекта на 50%, 80% и 100% лимита — стоит проверить, что эти роли заняты нужными людьми. Cap останавливает pay-as-you-go и запросы, покрытые CUD, но не трогает Provisioned Throughput: запросы на резервной ёмкости продолжат обслуживаться. Начинать Google советует с non-production: песочниц, тестовых кластеров и площадок для AI-агентов.
Spend caps arrived in preview earlier and have since gained three changes Google describes as direct responses to customer feedback. The key point: a cap stops usage charges but does not delete resources, so data and configuration stay in place.
What is new
A spend caps API. Managing limits by hand across hundreds of projects is painful, so the capability now sits in the existing Cloud Billing Budgets API. It lets you programmatically set, lift, update and delete caps for eligible services in a project — for example, automatically applying a strict cap whenever a developer spins up a sandbox project.
Live cost reports. For AI services a cap triggers within minutes using estimated live costs. Those figures now appear in Cost Reports, so you no longer wait for the standard billing pipeline to settle net costs before learning what crossed the threshold and when.
Automatic monthly resets. Previously a triggered cap stayed locked until someone lifted it in the UI. Enforced caps now reset at the start of the next month and blocked services resume. A manual override remains for organisations whose policy requires an audit before resuming.
What to keep in mind
Default alerts go to billing administrators and project owners at 50%, 80% and 100% of the cap, so make sure those roles are filled by the right people. A cap halts pay-as-you-go and CUD-covered requests but does not stop Provisioned Throughput: reserved-capacity requests keep serving traffic. Google recommends starting with non-production environments — sandboxes, test clusters and AI agent playgrounds.