We're going to need default hard budget caps on pretty much everything
- ID
- 31561
- Status
- summarized
- Published
- 04 Oct 2026, 7:34 AM
- Fetched
- 04 Oct 2026, 7:36 AM
- Provider
- Simon Willison
- Category
- developer-ai
- Original URL
- https://simonwillison.net/2026/Oct/3/default-hard-budget-caps/
- Source URL
- https://simonwillison.net/atom/everything/
Summary
- Score
- 7.5
- Created
- 04 Oct 2026, 7:36 AM
- Tags
- Audience
- developersvibe_codersai_agent_userssaas_founders
What happened
Simon Willison argues that pay-by-usage APIs and services need default hard budget caps — the kind that cut off usage and return errors once a monthly limit is hit — rather than soft caps that only send a warning email. He points to AWS, which on 16 September launched a new experience where a project that reaches its monthly spend limit is paused for the rest of the month, and notes Google Cloud shipped similar 'Spend Caps' in July. Willison wants hard caps to be the default, with an explicit opt-in checkbox to remove them for people who accept the risk of a runaway bill.
Why it matters
If you let coding agents or personal agents spin up paid APIs, hosted apps, or storage/compute on your behalf, check today whether your provider's cap is hard or soft — a warning email at midnight does not stop the meter. AWS's new spend limit pauses the project for the month, which protects your wallet but breaks your app, and the settings page warns the feature is only being released to a limited number of customers, so existing accounts likely cannot rely on it yet; Google Cloud's Spend Caps can be set per service within a project. Decide per project which you want: a hard stop, or an uncapped account you actively monitor.
Discussion angle
Hard caps trade a surprise bill for a paused project — which failure mode would you pick for a client-facing SaaS running on AWS or GCP, and does anyone here actually have a hard cap configured right now?