Simon Willison: Every Pay-by-Usage Service Needs Default Hard Budget Caps
On October 3, Simon Willison argued that pay-by-usage services and APIs must ship with default hard budget caps — cut the service off and return errors once $X is spent, not send a warning email at midnight. Coding agents have made it trivially easy to burn thousands overnight; the post hit 300+ points on Hacker News. AWS and Google Cloud shipped spend-limit features in recent months, but neither made them the default.
In one line: soft caps notify, hard caps insure
On October 3, Simon Willison — one of the most respected independent observers in the AI builder community — published a short post titled "We're going to need default hard budget caps on pretty much everything." His argument is single-minded and sharp: every pay-by-usage service and API should ship with a default hard budget cap — spend $X in a month and the service stops and returns errors. A "soft" cap that merely emails you a warning, he says, does not count.
Why now? Because coding agents have collapsed the friction of spending money. Burning cash used to require you to click around a console yourself; now an agent can sign up for a hosted database, spin up GPU workers, and call metered APIs at 3am while you sleep. As Willison puts it: nobody wants to wake up to a midnight budget-warning email and discover that a rogue service burned several hundred — or several thousand — more dollars overnight.
He answers the counterargument for you: errors or a surprise bill?
The classic objection to hard caps is that businesses don't want their production apps to start throwing errors because some budget was exceeded. Willison's reply is blunt: he believes most businesses and individuals would rather see errors than a surprise $10,000+ bill.
More important is his insistence on the default: hard caps should be on by default, and removing them must be an explicit, prominent opt-in — a checkbox reading something like "Remove the budget cap. My application will not be shut down if I exceed the configured budget limit, and I will be responsible for subsequent charges." Living dangerously should be a choice, not the default state everyone ships in.
The big clouds are moving — but not as defaults
The service Willison most wants this from is AWS — he says he has heard plenty of stories from people who refuse to use AWS for personal projects out of justified fear that a runaway service could bankrupt them. Fittingly, AWS announced monthly project spending limits on September 16: hit the limit and the project is paused for the rest of the month. Google Cloud shipped per-service Spend Caps in July (still in public preview). But neither provider made it the default, and availability remains limited.
The post reached the top of Hacker News the next day (300+ points, 150+ comments). The most valuable comment was a counterpoint from experience: a former support engineer at a service that did offer hard caps said that whenever a legitimate business got severed mid-viral-moment, it generated nightmare tickets and legal threats — which is probably why the big providers dragged their feet for a decade. Hard caps protect the wallet and hurt availability; every provider has done that math internally.
The takeaway for vibe coders: set the cap before letting agents run overnight
This is directly relevant to vibe coding: our community is the most enthusiastic about letting agents work through the night, and therefore the closest to waking up to a shocking bill. Three practical moves:
First, turn on every spend limit available to you tonight — AWS monthly project limits, Google Cloud Spend Caps, usage caps at every model provider. Don't wait for the first burn to take it seriously.
Second, put spending inside the constraints you give your agent, the same way you specify testing requirements: state a per-run token/call budget in the task description, and require it to stop and ask you when exceeded instead of routing around the limit.
Third, if you're shipping a vibe-built product to users, make hard caps your product's default — Willison's argument reads as product advice in reverse: some of your users will let an agent run wild, and a default hard cap is the cheapest insurance you can give them.
Sources
Related articles
Reported by InfoQ on October 3: a GPT-4 coding agent given CVE descriptions successfully exploited 87% of 15 test vulnerabilities, versus 7% without descriptions. rclone's author received 40+ security disclosures in a single month — more than the project's previous decade combined; QEMU has shortened its embargo period. The vulnerability disclosure timeline is collapsing under agent speed.
On October 7, OutSystems announced Agent Experience is generally available: its low-code platform is now open to any AI coding agent — Claude Code, Cursor, Codex, Kiro — with agents working at the design level, the platform generating code deterministically, and governance built in. This is the "vibe coding goes enterprise" playbook: taming shadow AI with a compliant path. But the 74% rework figure is vendor-survey data — discount it. The real bill is the hidden cost of platform lock-in.
The Zephos team planted 16 launch-killer bugs in Notely, an agent-built Next.js + Supabase + Stripe notes app — two payment-related: unsigned webhooks accepted, pro granted from a self-declared client_reference_id. This guide turns those traps into a playbook: webhook signature verification, a server-side single source of truth, the subscription state machine, test clocks, and a launch checklist. Money logic must be hand-written or audited line by line.