Pay-as-you-go cloud services need hard spending limits that are on by default, and AI agents are making that urgent. That’s the argument Simon Willison makes in a new post. He wants services to let you say “after $X/month, cut this thing off and return errors.” He’s clear that a warning email doesn’t count: “Soft caps… will not cut it.”
The big cloud providers seem to agree. AWS and Google Cloud have both shipped hard spending limits in the past few months.
💸 Why this matters now
Coding agents have made it much easier to build software. Willison points out that they also make it easy to spin up things that cost money: calls to paid APIs, hosted web apps, and systems that bill for extra storage and compute.
That changes who’s building. Developers who’ve been burned before have learned to fear runaway bills. Many new builders haven’t. Someone using a friendly personal agent (Willison calls these “coding agents wrapped in a less threatening UI”) may not know that a looping script or a viral side project can run up a five-figure bill overnight.
Willison sums up the risk: “Nobody wants to wake up to an email sent at midnight warning about a budget limit and find that, while they slept, their rogue service had consumed several hundred (or several thousand) more dollars of usage.”
⚖️ The case against, and why it loses
The usual objection is that businesses don’t want their apps throwing errors because they hit a budget line. For a production system serving paying customers, downtime has a real cost.
Willison’s answer is that most businesses and individuals “would prefer errors to a surprise $10,000+ bill.” He isn’t asking anyone to ban uncapped usage. He’s asking to flip the default. If you want to live dangerously, you tick a clear, prominent box that says you accept responsibility for charges past your limit.
That’s the right call. Defaults shape behavior, and right now they protect the provider’s revenue more than the customer’s wallet.
☁️ The hyperscalers are finally moving
AWS was the provider Willison most wanted to see act. He says he’s heard plenty of stories from people who avoid AWS for personal projects out of “justified” fear that a runaway service could bankrupt them. Others found out the hard way.
It turns out AWS has acted:
- AWS (September 16): A new experience lets builders set a monthly spend limit per project. If usage hits the limit, the project pauses for the rest of the month. AWS says it’s still rolling this out to a limited number of customers, so existing accounts may not have it yet.
- Google Cloud (July): A feature called Spend Caps lets you “set a monthly financial cap on specific services within a project.”
These are two of the biggest cloud providers, and both moved within a few months of each other. That looks like the start of an industry trend.
🔮 What the next 1-3 years look like
- Hard caps become table stakes. Once AWS and Google offer them, smaller API and hosting providers will face pressure to follow. Expect “spend limits” to show up in pricing-page comparisons.
- Agents start choosing providers. Willison suggests agents should lean toward recommending providers with hard caps and warn inexperienced builders away from uncapped services. That turns budget safety into a distribution advantage, since providers that agents trust will get more of their recommendations.
- Per-agent budgets follow. Project-level caps are step one. As agents run longer on their own, expect spending limits tied to individual agents, tasks, and API keys.
✅ What to do today
- Audit your accounts. List every pay-per-use service tied to a credit card, including the ones your agents set up.
- Turn on hard caps wherever they exist. Check whether AWS’s new spend limits or Google Cloud’s Spend Caps are available on your accounts.
- Use separate keys with low limits for agent experiments. Don’t let a prototype share billing with production.
- Add a rule to your agent’s instructions: prefer providers with hard spending limits, and flag any service that can bill without one.
Agents make building easier, so they make overspending easier too. Hard caps that are on by default are the guardrail that makes that trade-off safe. Willison’s full post has more detail on the AWS and Google Cloud launches.