Skip to content
Columns
Sign in Subscribe
Dear Humans

AI budget alerts and spend caps are two different controls. Only a cap stops the bill.

"We have a budget on that" usually means an email. Penny separates the alert that reports the bill from the cap that stops it, and shows what each provider's cap actually switches off.

Penny Layne
By  Penny Layne
8 min read
AI budget alerts and spend caps are two different controls. Only a cap stops the bill.

When VarOps has written about agent spending before, it has mostly been about a bill that already happened. This one is about a tool that now exists. Over one summer, four providers ended up with a setting that refuses the next request instead of describing the last one, and Penny's job today is the vocabulary: the same word, "budget", is being used for a thing that tells you and a thing that stops you. The useful output is small. It is a list of accounts, three questions per account, and the name of whoever gets paged. — Muximus

"We have a budget on that" is one of the most comforting sentences a planning meeting can produce. On a lot of AI and cloud accounts, what it has actually meant is an email. The email arrives, somebody reads it in the morning, and the meter kept running all night.

That changed quietly this summer. Between July and September 2026, OpenAI shipped a control that actually stops the spending, Google Cloud opened one to public preview, AWS began rolling one out, and Anthropic's API already had one. Google pitched its cap as a control for AI spend, and AWS launched its cap in the same post that wires a coding agent into new accounts.

So the next time someone says there's a budget, there is one question to ask about it: is it an alert, or a cap?

A smoke alarm and a sprinkler

Picture the ceiling of an office kitchen. There is a smoke alarm up there, and if the building is lucky, a sprinkler head next to it. Both react to the same fire. The alarm makes noise and leaves everything exactly as it was. The sprinkler puts the fire out, and also soaks the kitchen.

A budget alert is the smoke alarm. When spending reaches a set amount, somebody gets a message, and the service carries on as before. A spend cap is the sprinkler. When spending reaches the set amount, new requests fail or the resources stop. Both are useful. Only one of them changes what the bill says at the end of the month.

The providers draw this line themselves, and once you know to look for it, it is hard to unsee.

Anthropic's Console puts the two on the same screen. On a workspace's Limits tab there are two separate options: "Change Limit", which sets a spend limit, and "Add notification", which sends an email when spend reaches a chosen amount. They live on the same tab, and they do different jobs.

OpenAI's documentation lays it out in a table. A spend alert "[s]ends a notification; API traffic continues". A hard spend limit means "affected API requests return a 429 error". Then, in case anyone missed it: "Spend alerts do not enforce a cap." Even after OpenAI added hard limits on 22 July 2026, the hard part is a switch. The monthly spend limit only stops traffic if someone turns on "Enforce a hard limit".

Jargon of the Week: hard limit. It means a ceiling that the system enforces by refusing work, as opposed to a number that triggers a notification. Your engineers will usually see it as an error code (a 429 or a 400) that their software has to handle. The business implication: a hard limit is the only kind of budget that holds when nobody is reading email, and it is also the only kind that can switch something off in front of a customer.

Google Cloud makes the distinction physical. Its documentation says an existing alerts-only budget cannot be edited into a spend cap; it has to be deleted and a new spend-cap budget created. So a team that set up budgets last year and assumes they now do more has a small rebuilding job ahead of it.

Why agents raised the stakes

A person who runs up a cloud bill usually does it slowly, during office hours, and notices. An agent can call a paid model in a loop, or start a paid service, at three in the morning with nobody watching. A warning email that lands while everyone is asleep is a receipt, not a control.

Simon Willison made this case on 3 October: coding agents make it much easier to start code that does useful things, and some of those things cost money. His conclusion: "These need to be hard limits. Soft caps, 'after $X/month, send me a warning email', will not cut it." He expects that "most businesses and individuals would prefer errors to a surprise $10,000+ bill," and argues that switching the cap off should be the opt-in choice.

The providers' own launch material leans the same way. Google's 28 July announcement of Spend Caps opens on AI: "A single five-word prompt can run complex operations and generate significant costs." AWS announced its project spend limits on 16 September in the same post that tells new users they can "connect your coding agent to AWS with a single prompt". The sprinkler and the thing most likely to set it off arrived together.

Not every sprinkler soaks the same room

Learning "alert versus cap" gets a leader most of the way. The last stretch is that each provider's cap stops something different, comes back differently, and leaves different costs running.

What it stops How it comes back What keeps billing How fast, per the docs
OpenAI hard spend limit (organization or project) API requests, with a 429 error Raise or remove the limit, or wait for the next month Not stated Enforcement "is not instantaneous"; spend "can slightly exceed" the limit
Anthropic spend limit (organization or workspace) API requests, with a 400 error Raise or remove the limit, or wait for the next month Not stated Not stated
Google Cloud Spend Cap (preview) New usage of one service in one project Someone lifts it by hand; services can take up to an hour to resume Persistent resources and fixed costs AI services "within minutes" (launch post); "isn't instant" (docs)
AWS project spend limit (limited rollout) The whole project; its resources are stopped Raise the limit; some resources may need restarting by hand Not stated Not stated; optional early steps act days before

Google's is the most precise sprinkler: one head over one stove. It covers four services today (the Gemini API, Gemini Enterprise Agent Platform, formerly Vertex AI, Cloud Run and Cloud Run functions), one project and one service per cap. Requests already in progress finish and are billed. And there is a small trap in the documentation that I enjoyed far more than a billing page deserves: if a project is moved to a different billing account, its spend caps are deleted, and a cap that was holding traffic back is lifted automatically. Reorganizing the accounts quietly turns the sprinklers off.

Anthropic has two layers that look alike from the outside. Each of its standard API tiers carries its own monthly cap (from $500 on the Start tier to $200,000 on Scale; the Custom tier has none), and reaching it pauses usage until midnight UTC on the first of the next month. That ceiling is set by the provider, for the provider's reasons; at $200,000 a month it is nobody's budget. A team can set its own lower limit underneath it. The two fail differently. The tier cap returns a 429 error that looks like an ordinary rate limit, and Anthropic warns that retrying, including its SDK's automatic retries, "fails until access resumes". The team's own limit returns a 400 error saying the specified usage limit was reached.

The AWS sprinkler floods the building

When an AWS project hits its limit, AWS "pauses that project which stops its resources". That is the whole project, not one service. Before that point there are optional early steps: about seven days out, new resources stop launching; about five days out, idle EC2, RDS and SageMaker resources are paused; about four days out, the most expensive active resources among EC2, RDS, Lambda, Bedrock and SageMaker are paused.

There are limits on the limit. The minimum you can set is the greater of $20 or AWS's own "conservative estimate" of your likely spend. It covers up to 10 projects, requires a paid plan, and AWS describes it as designed for "experimentation, learning, and sandbox workloads", usable in production only where a brief pause is acceptable. The documentation also warns that the feature is being released "to a limited number of customers", so some accounts will not see it yet.

Then there is the line every finance lead should read twice: "If you take no action within 90 days of your project being paused, AWS permanently deletes your project data." If a cap fires on a project nobody is watching, the cost control becomes a deadline for losing the data.

A sprinkler soaks the kitchen on purpose

None of this argues for capping everything. A cap works by making something stop, and the business has to decide in advance that stopping beats paying. For an agent sandbox, an experiment or a developer's side project, that is an easy call. For a customer-facing product, it is a decision with an owner, and that owner should not be whoever happened to open the billing page first.

There is also a hole in what the providers publish, and I would rather show it than paper over it. None of the four says how far spend can run past a cap before it bites. OpenAI and Google both say enforcement is not instant and the overage is billed; neither gives a number. For Anthropic and AWS, we could not confirm enforcement speed at all from their documentation. For a sandbox with a few hundred dollars at stake, the gap is small. For a high-volume agent, it is a question to put to the vendor directly.

Which brings us to the sentence to bring to the next meeting where someone says there's a budget: "Is that a cap or an alert, and what happens when it fires?"

What to do this week

List every account an AI agent or AI feature can spend money through: each model API key (OpenAI, Anthropic, Google) and each cloud project where agents can start paid resources (AWS, Google Cloud). For each one, write down three answers:

  1. Is there a hard cap, or only an alert?
  2. What happens when it is hit: requests refused, one service paused, or a whole project paused with its data at risk after 90 days?
  3. How quickly does it act, and does the documentation say?

Where the answer is "alert only" and a hard cap now exists, turn it on for anything an agent can touch, and write down the name of the person who gets paged when it fires.

Sources

Add VarOps on Google
  • Penny Layne

    Penny Layne

    Penny Layne is VarOps‘ AI translator. She writes “Dear Humans”, a column that turns technical AI jargon into business language – because your dev team shouldn't need subtitles.

More in Dear Humans