Developer and writer Simon Willison has made the case for a feature he says every pay-as-you-go cloud service and API now needs: a default, hard budget cap that actually cuts off service once a spending limit is hit, rather than just sending a warning email. His post arrives just as both AWS and Google Cloud have quietly rolled out exactly this kind of feature, suggesting the industry may finally be catching up to a long-standing fear among developers—that a single bug or runaway script could generate a surprise bill worth thousands of dollars.

Why this is suddenly urgent

Willison points to the rise of coding agents and “personal agents”—AI tools that can write and run code with minimal human oversight—as the reason this problem is getting worse. These agents lower the friction of spinning up services that quietly rack up costs: calls to paid APIs, hosted web apps, or systems that bill for extra storage and compute. An agent left running overnight, or a misconfigured loop, can consume far more resources than a human would ever authorize in real time.

The nightmare scenario is familiar to many developers: waking up to a midnight warning email saying a budget threshold was crossed, only to discover that by the time you read it, the service had already burned through hundreds or thousands of additional dollars. Soft caps that merely notify you after the fact don’t actually prevent the damage—they just document it.

What a hard cap actually does

A hard budget cap is simple in concept: once usage hits a configured dollar limit for the month, the service stops and returns errors instead of continuing to bill. This is different from the “soft cap” alerts that most cloud providers have offered for years, which only send a notification while usage—and cost—keeps climbing in the background.

Willison argues hard caps should be the default setting, not an advanced option buried in a settings menu. Anyone who wants to disable the safety net and risk unlimited charges should have to actively opt in, for example by checking a box that reads something like: “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 framing flips the current norm, where uncapped spending is the default and protection is something you have to discover and configure yourself.

AWS and Google Cloud have started shipping this

The timing of Willison’s post lines up with real movement from the two largest cloud providers. According to AWS’s own announcement, titled “New AWS experience helps builders get started and ship faster” and published on September 16th, users can now set a monthly spend limit for a project, and “if a project’s usage reaches its spend limit, your project is paused for that month.” AWS has also published documentation on how to create a spend limit, though the company notes this new experience is currently being released to only a limited number of customers rather than being generally available.

Google Cloud moved first, launching a comparable feature called Spend Caps in July. It lets users “set a monthly financial cap on specific services within a project,” giving teams a way to contain costs on a per-service basis rather than capping an entire account or project broadly.

This matters because AWS in particular has a reputation—deserved, according to Willison—for being risky for personal and side projects. He notes he has heard from people who avoid AWS entirely for personal use specifically because they fear a runaway service could bankrupt them, as well as from others who didn’t anticipate the risk and were burned by large unexpected bills.

What it means for developers right now

For developers currently building on AWS or Google Cloud, the practical takeaway is to check whether spend limits or Spend Caps are available on your account and project, and to configure them before deploying anything experimental—especially anything involving autonomous agents or loops that call paid APIs. Since AWS’s version is still in limited rollout, not every account will have access yet, so developers should watch for general availability.

Willison also floats a forward-looking idea: that AI agents themselves could help enforce this kind of safety. He suggests agents could be built to bias toward recommending cloud providers and services that offer hard budget caps, and to actively warn inexperienced builders against deploying on uncapped services where they could end up in financial trouble. This is a speculative suggestion rather than an announced feature from any company, but it points to where the ecosystem might head next—agents that protect users from the very risks that agents themselves helped create.

The broader trend beyond AWS and Google

Willison frames this as a pattern likely to spread well beyond the two cloud giants. Any pay-by-usage API or service—LLM providers, hosting platforms, storage systems—faces the same underlying risk: a user’s code or an autonomous agent can generate usage faster than a human can react to a warning email. As more development work gets delegated to agents that operate with less direct supervision, the argument for hard, default-on spending limits across the broader API and cloud ecosystem becomes harder to ignore.

Frequently asked questions

Is AWS’s spend limit feature available to everyone now?
No. According to AWS’s own documentation, the new experience is currently being released to a limited number of customers, not to all existing accounts.

How is this different from AWS Budgets or Google Cloud billing alerts?
Older budget and billing alert tools typically only notify you by email once you cross a spending threshold, while usage and charges continue. The new spend limit and Spend Caps features actually pause the project or service once the cap is reached.

Does this fully solve the risk of surprise cloud bills?
Not entirely. These features currently apply to specific products and are rolling out gradually, and most other APIs and services still lack a true hard cap. Willison argues it needs to become the default across pay-by-usage services generally, which has not yet happened.

Source: We’re going to need default hard budget caps on pretty much everything