The problem with soft billing alerts is the time gap. An alert fires at midnight saying you’ve hit your threshold. By the time you see it at 7am, eight more hours of a runaway agent have consumed several hundred — or several thousand — more dollars.
Simon Willison’s argument is structural: hard caps, the kind that stop execution and return errors when the limit is hit, should be the default on every pay-by-usage AI API. Uncapped access should require an explicit opt-in with a checkbox acknowledging financial responsibility.
The Mechanism
The distinction matters in practice:
Soft alert: Email or notification fires when spending crosses a threshold. The service continues running. The user sees the alert whenever they check their inbox. The cost continues accumulating until the user acts.
Hard cap: The API returns errors when the spending limit is reached. The service stops. The user wakes up to error logs and a stopped service — not a $10,000 bill.
For a human operator checking email intermittently, the difference between a hard and soft cap is the difference between a bad Tuesday morning and a crisis.
The Layers
The problem is getting worse, not better. AI coding agents and workflow automation reduce the friction for deploying services with external API costs. A developer can ship a personal project on a Friday afternoon that makes thousands of API calls by Saturday morning. Without a hard cap in place, “checking the bill before things get out of hand” requires active vigilance that most people don’t maintain on personal or experimental projects.
Willison’s specific concern: the fear of runaway bills is preventing individuals from using AI services for personal projects entirely. People who would build and experiment are self-selecting out of the ecosystem because the worst-case financial outcome is unbounded. Hard caps as defaults convert an unbounded risk into a bounded one.
Two major cloud providers have recently moved in this direction:
AWS launched spending limits that pause projects when limits are exceeded — a hard stop on overrun.
Google Cloud introduced Spend Caps in July 2026 at the service level, enabling financial limits that stop a service rather than just notifying about it.
Both are moving toward hard-cap defaults, though neither yet requires explicit opt-in for uncapped access in the way Willison recommends.
The Edge Cases
The counter-argument from production engineering teams is that a hard cap on a production service can cause its own outage. If a traffic spike drives API costs above the cap threshold, the service fails. Teams running production workloads typically prefer soft alerts with manual intervention over hard stops that can take down a live system.
Willison’s response to this is implicit in his framing: the problem is specifically the default. Production engineers should be able to opt into uncapped access deliberately. The current defaults — uncapped by default, caps as opt-in — are calibrated for sophisticated engineers who know to set limits. They’re not calibrated for the vast majority of builders who assume the platform would stop them before the bill becomes catastrophic.
The So What
If you’re building AI-powered tools or agents for others — whether internal tooling, startup products, or developer-facing services — the design question worth asking is: what happens if this runs unexpectedly at 100× the intended volume? Does the cost cap before catastrophe, or does the bill accumulate until someone notices?
Willison’s recommendation for AI agents specifically: prefer services with hard caps over services with only soft alerts when the two offer equivalent capability. When advising people newer to the ecosystem, name the cap setup as a required step, not an optional one.
The platforms that build hard caps into their default offering are making a product decision that reduces risk for their users. That’s worth factoring into platform selection when you’re evaluating where to build.
Content created with AI assistance and reviewed for accuracy.
Join the conversation
Stack Insiders is our free community for readers who want to go deeper — share resources, ask questions, and connect with others across every vertical we cover.
Join Stack Insiders →