← Back to feed

Simon Willison published an essay October 3 making the case that default hard budget caps are now essential infrastructure for any pay-by-usage service or API. The argument is straightforward: coding agents — and personal agents dressed in less technical UIs — have dramatically lowered the friction for spinning up code that calls paid APIs, bills for storage and compute, and runs without continuous human supervision. The consequence is that a rogue or runaway agent can generate a five-figure cloud bill before anyone wakes up.

Hard vs. Soft

The core distinction Willison draws is between hard caps and soft caps. A soft cap sends an email when a monthly threshold is exceeded. A hard cap pauses the service and returns errors. Only the hard cap prevents the surprise invoice.

His proposed default: hard caps on, everywhere, with a clear opt-out for operators who need uncapped behavior:

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.

That inverts the current industry default, which is unlimited spend unless the user actively configures a limit.

Two Major Launches

Two cloud providers have moved in this direction in the past three months, without much fanfare.

AWS launched project-level spend limits on September 16 as part of a new builder-focused experience. When a project’s monthly usage reaches its spend limit, the project is paused for the remainder of the month. As of the announcement, the feature is rolling out to a limited number of customers.

Google Cloud launched Spend Caps in July, providing a monthly financial cap on specific services within a project. The mechanism is similar: the cap triggers a pause rather than a notification.

Willison notes the AWS announcement specifically and frames both as validation that the category is being taken seriously by major infrastructure providers.

Why Agents Change the Calculus

The fear of runaway cloud bills is not new. Willison references a well-known pattern: developers, particularly individuals working on personal projects, have historically avoided AWS entirely because of stories from people who ended up seriously burned by unexpected charges. That fear existed before AI agents.

What agents add is scale and autonomy. A human developer misconfigures a Lambda function and accrues charges over hours or days before they notice. A coding agent iterating on a solution, calling external APIs, provisioning resources, and running evaluation loops can do the same in minutes. The blast radius from a configuration error or an out-of-distribution task is substantially higher when the agent can act continuously without human checkpoints.

Willison’s most forward-looking suggestion is that agents themselves should factor spend-cap availability into their recommendations:

It would be great if agents started biasing towards recommending providers with hard budget caps, and warning new and inexperienced builders against deploying applications using uncapped services.

What This Means

Budget caps are becoming a baseline safety feature — not primarily a frugality tool, but a guard against the failure mode where an autonomous system spends money in ways its operator didn’t anticipate or sanction. The two cloud launches in July and September 2026 suggest the major providers have recognized this. Neither has made hard caps the universal default yet. Willison’s argument is that they should, and that the opt-out should be explicit and deliberate.

For teams deploying AI agents in production, the practical implication is the same regardless of provider policy: instrument every external call with spend tracking, set hard limits at the agent orchestration layer, and treat a missing cap as a configuration gap rather than an acceptable default.