The Urgent Necessity for Default Hard Budget Caps

Originally published by Simon Willison on October 3rd, 2026

In the coming years, there is one specific product feature that will become absolutely essential for the digital ecosystem: default hard budget caps.

What is a Hard Budget Cap?

When dealing with APIs or services that operate on a pay-as-you-go model, a hard budget cap is a mechanism that allows a user to specify a maximum spend. Once that limit is reached, the service simply stops.

"After spending $X per month, terminate the service and return error messages."

Soft caps (which merely send a notification email once a threshold is hit) are fundamentally inadequate for the modern era.

---

The Catalyst: The Rise of AI Agents

The proliferation of coding agents—and their more user-friendly cousins, personal agents—has drastically lowered the barrier to deploying functional code. While this is empowering, it introduces a significant financial risk.

These agents can easily spin up infrastructure that incurs costs via:

• Paid API calls
• Hosted web applications
• Compute and storage scaling

The mathematical risk can be expressed as: $\text{Total Cost} = \sum (\text{Unit Price} \times \text{Unexpected Usage})$

If the $\text{Unexpected Usage}$ spikes due to a loop or a bug, the $\text{Total Cost}$ can skyrocket while the developer is asleep. No one wants to wake up to a midnight alert only to discover their bank account has been drained by several thousand dollars.

Hard Caps vs. Soft Caps

The "Downtime" Argument

Some argue that businesses cannot afford for their applications to crash just because a budget was hit. However, for the vast majority of individuals and companies, a service error is infinitely preferable to a surprise \10,000$ invoice.

The Proposed Solution: Opt-In Danger

Safety should be the default. If a user wishes to "live dangerously," they should have to explicitly choose to do so via a prominent interface:

• Remove the budget cap
  • By checking this, I acknowledge that my application will not be shut down upon exceeding the limit, and I accept full responsibility for all subsequent charges.

Example Configuration

A developer might define their budget in a config file like this:

{
  "billing": {
    "monthly_hard_limit": 50.00,
    "currency": "USD",
    "action_on_limit": "RETURN_ERROR_402_PAYMENT_REQUIRED"
  }
}

Industry Progress

Many developers have historically avoided AWS for personal projects due to the very real fear of accidental bankruptcy. Fortunately, the tide is turning.

AWS recently introduced spending limits (announced September 16th). According to their update:

"When you’re ready to upgrade to a paid plan, you can set a monthly spend limit... If a project’s usage reaches its spend limit, your project is paused for that month."

Similarly, Google Cloud debuted "Spend Caps" in July, allowing users to cap specific services within a project.

The Logic Flow of a Safe Deployment

Final Thoughts

As we move forward, we should hope that AI agents begin to:

1. Prefer providers that offer hard budget caps.
2. Warn novice builders against using uncapped services.

Current Goals for Cloud Providers:

• Implement basic billing alerts.
• Make hard budget caps the default for all new accounts.
• Provide granular caps per service.