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

What it claims

Willison argues that "after $X/month, cut this off and return errors" should be the default on pay-by-usage services. Soft caps that only send a warning email are not enough, because an alert sent at midnight does not stop overnight spend. He expects most businesses and individuals would rather have their applications throw errors than receive a surprise $10,000+ bill. Uncapped billing should be an explicit opt-in, behind a prominent checkbox worded roughly: "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."

He also proposes that coding and personal agents should prefer providers with hard caps, and should warn inexperienced builders before they deploy onto uncapped services.

How to use it

The two provider features the page cites differ in scope and availability.

• AWS spend limits, announced 16 September 2026 as part of the "new AWS experience":
• You set a monthly spend limit per project when you upgrade to a paid plan.
• When a project reaches its limit, the project is paused for the rest of that month. It is not throttled or billed further.
• It is configured in AWS Settings ("Create a spend limit").
• Google Cloud Spend Caps, launched July 2026:
• Sets a monthly financial cap on specific services within a project. This is finer-grained than AWS's whole-project pause.

Limits

• The AWS feature is not generally available. AWS's own settings page says it is "currently releasing our new experience to a limited number of customers." Willison hopes it reaches existing accounts soon, so it may not be available on yours. Check before assuming you are protected.
• The AWS feature is described as tied to the new-experience paid-plan upgrade path. The page does not say whether older accounts or setups can use it.
• When the AWS cap triggers, the whole project pauses until the month ends. That is a full outage, which matters for anything user-facing.
• The page does not cover how either cap handles billing lag, meaning charges that accrue after the limit is crossed. It also does not cover which services fall outside Google's per-service caps.
• This is an opinion post. It contains no measurements and no survey of other providers beyond these two.