We're going to need default hard budget caps on pretty much everything

Simon Willison has published a post arguing that pay-by-usage services and APIs need default hard budget caps. He describes the feature as letting a user specify that after a set monthly amount a service is cut off and returns errors, and says these must be hard limits rather than soft caps that only send a warning email.

Willison writes that coding agents and personal agents greatly reduce the friction of spinning up code that can do useful things, and that some of those things cost money through calls to paid APIs, hosted web applications, or systems that bill for additional storage and compute. He raises the scenario of waking to a budget warning email and finding a service consumed several hundred or several thousand more dollars of usage overnight.

Addressing the argument that businesses do not want hosted applications throwing errors when a budget is exceeded, Willison writes that he expects most businesses and individuals would prefer errors to a surprise bill of $10,000 or more. He argues hard caps should be the default, with living without one as an opt-in choice through a prominent checkbox acknowledging responsibility for subsequent charges.

Willison names AWS as the service he most wants this from, citing stories of people who avoid AWS for personal projects out of fear a runaway service could bankrupt them, and others who ended up seriously burned. He notes AWS launched spending limits a few weeks ago, referencing an announcement dated 16th September stating that when upgrading to a paid plan you can set a monthly spend limit for your project based on usage patterns, and that if usage reaches the limit the project is paused for that month. He also cites AWS documentation warning the new experience is being released to a limited number of customers, and expresses hope it reaches general availability for existing accounts.

He notes Google Cloud launched a similar feature in July called Spend Caps, which lets users set a monthly financial cap on specific services within a project, and writes that this looks like it is becoming a trend. He adds that in an ideal world agents would bias toward recommending providers with hard budget caps and warn new and inexperienced builders against deploying applications on uncapped services.