Friday, 16 October 2026
1 agent hack today▼ 7 vs yesterday (8)

Runaway agents revive the case for hard spending caps

A widely read developer blog argues cloud providers should cut off usage by default once a budget is hit, as coding agents make it trivial to spin up costly services.

By The Agentic Times ·

A robot's mechanical arm spins dials frantically, stacking gold coins higher and higher until a steel wall slams down, halting it mid-motion.
A robot's mechanical arm spins dials frantically, stacking gold coins higher and higher until a steel wall slams down, halting it mid-motion. · Illustration: The Agentic Times

Cloud and API providers should make hard spending limits the default, according to a post published on 3 October 2026 on simonwillison.net, which argues that AI coding agents have made it far too easy to deploy services that quietly rack up large bills.

The post draws a distinction between soft and hard caps. A soft cap sends a warning email when spending passes a threshold. A hard cap stops the service and returns errors. The author argues that only the second is useful, writing that nobody wants to wake up to a midnight warning email and discover that a rogue service consumed several hundred or several thousand dollars of usage overnight.

The link to AI agents is about friction. Coding agents, and what the post describes as personal agents — coding agents wrapped in a less threatening interface — sharply reduce the effort needed to stand up code that does useful things. Some of those things cost money: calls to paid APIs, hosted web applications, and systems that bill for extra storage and compute. The implication is that more people are now deploying billable infrastructure without the experience to judge what it might cost if something goes wrong.

The post acknowledges the counter-argument, that businesses do not want production applications throwing errors because a budget was exceeded. Its response is that most businesses and individuals would still prefer errors to a surprise bill of $10,000 or more. Customers who want to run without a cap should be able to opt out through a clear and prominent checkbox that makes them responsible for the resulting charges, the post says.

Two major providers have moved in that direction. Amazon Web Services announced a new builder experience on 16 September, which includes the option to set a monthly spend limit for a project when upgrading to a paid plan. According to the announcement quoted in the post, if a project's usage reaches its spend limit, the project is paused for the rest of that month. AWS documentation on creating a spend limit warns that the new experience is being released to a limited number of customers, so it is not yet generally available to existing accounts.

Google Cloud launched a comparable feature in July, called Spend Caps, which the post says allows customers to set a monthly financial cap on specific services within a project.

AWS is singled out as the provider the author most wants to see offer this by default. The post says it has heard from people who refuse to use AWS for personal projects out of what it calls justified fear that a runaway service could bankrupt them, and from others who did not anticipate the risk and were seriously burned.

The post ends with a suggestion aimed at the agents themselves. In an ideal world, it says, agents would bias towards recommending providers that offer hard budget caps, and would warn new or inexperienced builders against deploying applications on uncapped services that could get them into trouble. That would make cost control part of the agent's default behaviour rather than something the user has to remember to configure.

Sources

  1. simonwillison.nethttps://simonwillison.net/2026/Oct/3/default-hard-budget-caps