Pay-as-you-go services should default to hard budget caps, Willison says

Hard limits for usage-based services

Simon Willison says pay-by-usage services and APIs should offer default hard budget caps that stop usage after a set monthly amount and return errors. He argues that soft caps, which only send warning emails, are insufficient because a service could continue spending after an alert arrives while its user is asleep.

His concern is especially relevant to coding agents and personal agents, which make it easier to spin up code that calls paid APIs, hosted web applications, storage and compute systems. These services can create additional charges. Willison says most businesses and individuals would prefer errors to a surprise bill of $10,000 or more, although some hosted applications may not be able to tolerate being shut down when a budget is exceeded.

AWS introduces project spending limits

AWS announced on September 16 that customers upgrading to a paid plan can set a monthly spending limit based on their expected usage. When a project's usage reaches the limit, the project is paused for that month. The cited AWS Settings page says the new experience is initially being released to a limited number of customers.

Willison identifies AWS as the provider he most wants to offer hard budget caps. He says he has heard from people who avoid AWS for personal projects because they fear a runaway service could create severe costs. He also reports hearing from people whose cloud bills were seriously affected by usage they had not anticipated.

Google Cloud offers service-specific caps

Google Cloud launched a comparable feature in July called Spend Caps. It allows customers to set a monthly financial cap on specific services within a project. Willison presents the AWS and Google Cloud releases as evidence that spending controls are becoming a wider industry trend.

He also suggests coding and personal agents could help protect budgets. Agents could favor providers with hard caps and warn new or inexperienced builders about deploying applications on uncapped services. Willison says users should still be able to remove limits, but only through an explicit opt-in that makes clear the application will not be shut down after exceeding the configured budget and that subsequent charges will remain the user's responsibility.