Hard Budget Caps for AI Agents: Why Warning Emails Aren't Enough

Simon Willison published a short post this week with a clear thesis: we need default hard budget caps on pretty much everything. He means the feature of pay-by-usage services and APIs that lets you say "after $X/month, cut this thing off and return errors." His point is that it has to be a *hard* limit. A warning email doesn't count.

Why agents change the cost equation

Willison's argument is that coding agents, and personal agents (coding agents behind a friendlier UI), greatly reduce the friction of spinning up code that does useful things. Some of those things cost money, such as calls to paid APIs or hosted resources. When the person launching the code isn't reading every line, and the thing keeps running while they sleep, a bug or loop can turn into a very large bill before anyone looks.

That matters for the kind of work we cover. A trading bot, an LLM-in-the-loop workflow or a scraping agent can run unattended by design. The same applies to a vibecoded prototype someone leaves deployed. Spend is one more failure mode alongside bad outputs and bad actions, and it needs a hard stop.

Soft caps don't stop anything

A soft cap relies on a human reading an email and reacting in time. An unattended agent gives no such guarantee. Willison's view is that most people would take a service interruption over a surprise bill above $10,000. Providers worry that hard caps will cause errors for customers, but users fear a ruinous bill more.

What he proposes

Caps should be on by default. Removing one should take a prominent, deliberate step, such as a checkbox that reads:

Remove the budget cap. My application will not be shut down if I exceed the configured budget limit, and I will be responsible for subsequent charges.

— Simon Willison's proposed wording

He also suggests that AI agents themselves should recommend capped providers, and should warn inexperienced developers away from uncapped ones.

The big clouds are moving

Willison points to two recent launches. AWS added project spend limits as part of a new builder experience in September 2026. Per the quoted announcement, when a project's usage reaches its limit, the project is paused for that month. Google Cloud announced spend caps on budgets in July 2026, alongside early anomaly detection. See each provider's documentation for exactly which services a cap covers.

What builders can do today

Provider caps help, but most paid APIs your agents touch don't have them yet. A few habits cover the gap:

• Put a budget check in your own code path. Count spend per run or per day and make the agent fail closed when it passes the limit.
• Give agents scoped, low-limit credentials where a provider allows it, instead of your main account key.
• Set iteration and timeout limits on agent loops so a stuck run ends on its own.
• Prefer providers with real hard limits, and treat warning-only alerts as monitoring, not protection.

None of this is exotic. It is the same principle as a trading system's kill switch: the safety limit has to work without a person watching.