All posts
2 min readby Romiel Inolino

AWS and Google Cloud now offer hard spend caps. Every AI automation you run for a client should have one

AI costscloud billingautomationAI agentsn8n

A warning email at midnight does not stop a runaway agent. A hard cap does.

What happened

Simon Willison published a short post arguing that pay-by-usage services and APIs need default hard budget caps: once you hit $X a month, the service cuts off and returns errors. Soft caps that only send a warning, he writes, will not cut it, because coding agents and personal agents make it easy to spin up code that spends money while you sleep.

He points to two recent moves:

  • AWS announced a new builder experience on September 16 where you can set a monthly spend limit per project. If usage reaches the limit, the project is paused for that month. AWS's settings page says it is rolling out to a limited number of customers first.
  • Google Cloud launched Spend Caps in public preview on Budgets. Once a project and service hits the cap, Google restricts further billable usage for that service, without deleting data. For AI services, Google says the caps trigger within minutes, and the block stays until someone lifts it. Covered services include the Gemini API, Agent Platform, Cloud Run and Cloud Run Functions.

Willison's view is that most businesses would rather see errors than a surprise $10,000+ bill.

My take

I agree, and I apply the same rule to client automations. Every workflow that calls a paid model or API gets a ceiling it physically cannot pass.

What that looks like in practice:

  1. Use provider caps where they exist. If a client runs Gemini on Google Cloud, set a Spend Cap on the dev project first, then production.
  2. Add your own cap in the workflow. In n8n, Make or Zapier, keep a running count of calls or estimated spend per day in a data store, and stop the run when it crosses the line.
  3. Cap loops, not just money. Most runaway bills I have seen come from a retry or an agent loop with no maximum iterations.
  4. Decide what failure looks like. A paused workflow should alert someone and queue the work, not silently drop leads.

The tradeoff is real: a capped service can stop mid-month. But a paused workflow is a support ticket. An uncapped one can be a very bad invoice.

More posts