The case for hard budget caps as a default setting

Simon Willison lays out a demand he expects to grow urgent over the coming months and years: default hard budget caps. He means the feature of pay-by-usage services and APIs that lets you say "after $X/month, cut this off and return errors." The key word is cut off. Soft caps — "after $X/month, send me a warning email" — won't do the job.

Where the risk comes from

Coding agents, and personal agents (coding agents in a less threatening wrapper), dramatically lower the friction of spinning up code that does something useful. Sometimes that useful thing costs money — calls to paid APIs, hosted web applications, systems that bill for extra storage and compute.

Nobody wants to wake to a midnight email warning about a budget limit, only to find that while they slept a rogue service burned through several hundred — or several thousand — more dollars.

Errors beat a $10,000 bill

The standard objection is that businesses don't want their hosted applications throwing errors because some budget was exceeded. But Willison suspects most businesses and individuals would far rather have errors than a surprise bill of $10,000 or more.

So the hard cap should be the default. Anyone who wants to live dangerously should be able to, but only by opting in. He proposes a prominent, plainly worded checkbox: "Remove the budget cap. My application will not be shut down if I exceed the configured limit, and I will be responsible for subsequent charges."

Who's already done it

The provider he most wants this from is AWS. He's heard plenty of stories from people who refuse to use AWS for personal projects out of a justified fear that a runaway service might bankrupt them — and from people who didn't anticipate that and got badly burned.

As it turns out, AWS has finally launched spending limits. A 16 September announcement explains that when you upgrade to a paid plan you can set a monthly spend limit for a project, and once usage reaches it the project is paused for the rest of the month — though the feature is currently rolling out to a limited set of customers. Google Cloud shipped something similar, called Spend Caps, back in July, letting you set a monthly financial ceiling on specific services within a project. It's starting to look like a trend.

Ideally, Willison adds, agents themselves could help: it would be good if they leaned toward recommending providers with hard caps and warned inexperienced builders away from deploying on uncapped services that could land them in trouble.

Source: Simon Willison