Why we need strict spending limits by default in pay-as-you-go services

The article, published by Simon Willison on his blog on October 3, 2026, raises a simple idea with far-reaching implications for the whole of internet infrastructure: usage-billed services —paid APIs, hosted applications, systems that charge for additional storage or compute— should include hard budget caps by default, instead of the soft alerts that are standard today. A soft cap merely sends a warning email when a given monthly spending threshold is crossed; a hard cap cuts off the service and starts returning errors. Willison argues that only the second type is genuinely useful, because an alert that arrives at midnight does not stop a runaway service from racking up hundreds or thousands of dollars of consumption while someone is asleep.

The context driving this proposal is the rise of coding agents and "personal agents" (which the author describes as coding agents wrapped in a less intimidating interface). These tools drastically reduce the friction of getting code running that interacts with paid services: calls to external APIs, deployment of web applications, or systems billed by resources consumed. That ease of creating things that cost money is precisely what, according to the article, multiplies the risk of surprise bills when something fails or behaves unexpectedly and nobody is watching in real time.

Willison anticipates the typical objection from companies: nobody wants their production application to start returning errors because an arbitrary budget has run out. His answer is that, for the vast majority of users and organizations, it is preferable to deal with controlled errors than to wake up to a bill of 10,000 dollars or more. That is why he proposes that the hard cap be the default option, with the possibility of disabling it only explicitly and deliberately: a visible checkbox that says, in essence, "remove the spending cap; my application will not stop if I exceed the configured budget and I will take responsibility for the resulting charges". In other words, reversing the burden of proof: whoever wants to take on the risk of unlimited spending should have to say so expressly, rather than the risk falling by default on any user who has configured nothing.

The article points to AWS as the service where this feature would be most urgent, citing the phenomenon —widely known in the developer community— of people who avoid using AWS for personal projects out of a justified fear that a runaway service will ruin them financially, and of others who have indeed been badly hit for not having anticipated it. On this point, Willison notes a recent development: a few weeks before his post, on September 16 to be precise, AWS announced a new developer experience that allows a monthly spending cap to be set for a project; if usage reaches that limit, the project is paused for that month. The article itself qualifies that, according to AWS documentation, the feature is for now being rolled out to only a limited number of customers, so it is not yet generally available to all existing accounts.

It also mentions that Google Cloud launched an equivalent feature in July, called "Spend Caps", which allows a monthly financial ceiling to be set on specific services within a project. For Willison, the fact that both announcements came within a short span of time suggests this is becoming a trend.

Finally, the article points to an additional role that AI agents themselves could play in this problem: in an ideal scenario, these agents would actively help mitigate the risk, recommending by default providers that offer hard spending caps and warning new or inexperienced developers when they are about to deploy applications on services without that kind of protection. The idea rounds out the text's reasoning: if AI agents are part of what has made it so cheap to create systems that can spend money without constant human supervision, they should also be part of the solution, acting as an extra layer of prudence against their own side effects.