Update, October 11, 2026: Google Cloud caps reset automatically each month and can be lifted earlier. Persistent-resource charges and enforcement delays can still add costs.
What he said
Independent developer Simon Willison published a short post on October 3 with a blunt thesis: “Here’s a product feature which the world is going to need a whole lot more of over the coming months and years: default hard budget caps.”
He defines the term narrowly. A hard cap is a setting that says “after $X/month, cut this thing off and return errors.” He rejects the softer version: “Soft caps, ‘after $X/month, send me a warning email’, will not cut it.”
His reason is agents. In his words, coding agents and personal agents “greatly reduce the friction of spinning up code that can do useful things.” Some of those things cost money: calls to paid APIs, hosted apps, or extra storage and compute. “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.”
He wants the cap switched on by default, with a deliberate way out: “If someone wants to live dangerously they should be able to do that, but it needs to be on an opt-in basis.”
Who he is
Willison describes himself on his about page as working full-time on open source tools for data journalism, built around Datasette and SQLite. He is also on the board of the Python Software Foundation. His posts regularly examine the practical costs and risks of agent-built software.
What he gets right
An email alert needs someone to act on it. An enforced cap can stop new usage automatically, even while you are away. Its effect on the final bill depends on which charges it covers and when enforcement starts. For someone who builds with agents and does not read every line the agent wrote, “default” is the important word, because a limit you never think to set protects no one.
Willison points to AWS project spend limits and Google Cloud Spend Caps. They pause different resources and have different recovery rules.
A cutoff can cause an outage
AWS’s documentation says a project that reaches its limit is paused, which “stops all resources.” Data is preserved, but it also says that if you take no action within 90 days of the pause, AWS permanently deletes the project’s data. The minimum limit is the greater of $20 or an estimate of your likely spend. The feature is also described as rolling out to a limited number of customers, and it needs a paid plan. AWS says it is designed for experimentation and sandbox work, and acceptable for production only when a brief pause is tolerable.
Google Cloud announced Spend Caps in public preview for the Gemini API, Agent Platform, Cloud Run, and Cloud Run Functions. Its current documentation limits each cap to one project and one eligible service. Enforcement pauses new usage, including usage covered by commitments, while requests already running can finish.
The block lifts automatically at the next monthly period, or you can lift it earlier. Fixed charges for persistent resources such as compute and storage can continue, and subscription costs are outside the cap. Enforcement is not instant, so reporting delays can also cause overages. A cap is therefore not a guarantee that your final bill equals the figure you set.
Willison acknowledges the main objection himself: businesses may not want their apps throwing errors. He bets most people prefer errors to a surprise bill of $10,000 or more. That is his judgment, and it is reasonable for hobby projects and early products. It is less clear for a live customer-facing service, where an outage can cost more than the overage.
Why it matters
In July, Willison made a narrower version of this argument about AI model API keys. This post widens it to every pay-by-usage service, and the AWS and Google features it cites are new since then.
What builders should do
Before an agent deploys a pay-by-usage service, read what its spending control stops at the threshold. Enable a cutoff for development or disposable projects where a shutdown is acceptable. For customer-facing production, choose the spending limit and outage response together.
Check whether the limit applies per project, service, or API key, the credential used to make requests. Identify continuing charges and any data-retention deadline after a pause. If recovery requires a manual restart, decide who receives the alert and who restores service.
Alerts alone do not stop spending. Check whether the service offers an enforceable cutoff or whether you need one of your own. Vercel’s AI Gateway budgets block later requests after a threshold is crossed, but the crossing request can finish and exceed it.
Willison also proposes that agents favor providers with enforceable caps and warn newer builders about uncapped services. For your own deployment, verify the cutoff’s scope and recovery procedure before relying on it.
End of article