What should happen when we reach it?

Ideally degradation rather than a stop: a cheaper model, a queue for anything not urgent, optional features switched off. That requires deciding in advance which uses are essential, which is the work the cap is really asking you to do.

How high should it be?

At a worst case you could absorb without difficulty, rather than at what you expect to spend. A cap sized to the forecast triggers on any ordinary surprise, and a team that raises it every time has turned a control into a monthly ritual.

Several, split by use. A single ceiling covering experiments and customer-facing work means a runaway test can take the product down, which is precisely the outcome the cap was put in place to prevent, and the split costs nothing beyond deciding where the boundaries are.

Glossary

Spend cap

A hard ceiling on what an account can consume, which turns a bill that could be any size into one with a known worst case.

In plain terms

A limit on how much can be spent before everything stops. The number is the easy part. The question that decides whether it helps or hurts is what happens the moment it is reached, and most people set the first and never ask the second.

Why it matters

Because usage billing has no natural maximum. A mistake in a loop, a burst of traffic or somebody testing enthusiastically can produce a bill nobody budgeted for, and a cap is the only mechanism that puts a number on the worst case in advance.

How it works

It bounds the worst case rather than managing the ordinary one. Alerts tell you what has already happened and budgets describe an intention; only a cap makes a figure impossible to exceed, which is a different kind of control from either.

What happens at the ceiling is the real decision. Stopping abruptly protects the bill and can take a customer-facing feature down without warning, so the cap becomes an outage whose timing is set by a spreadsheet nobody is watching.

The safer design is degrade rather than stop. Falling back to a cheaper model, queueing non-urgent work or disabling optional features keeps the important path alive while the ceiling still holds, and it takes deciding in advance which uses are which.

Set it against a worst case you can survive, not against a forecast. A cap sized to expected use will be hit by any normal surprise, and a team that raises it every time it triggers has converted a control into a monthly formality.

Separate caps by use are worth more than one large one. An experimental workload and a customer-facing one under a single ceiling means the experiment can take the product down, which is exactly the failure a cap was meant to prevent.

A cap is not a rate limit and the two get confused. A rate limit bounds how fast requests arrive, which protects a service and does nothing about a slow steady spend; a cap bounds the total, which does nothing about a sudden burst arriving inside it. Most situations want both.

It changes behaviour by existing. A team that knows a hard limit is in place tests differently, and the discipline that produces is worth more over a year than the money any single stop saves.

Two things to do at the ceiling

The reason stopping is the default is that it requires no decisions: a single number, a single behaviour, and no need to rank anything. Degrading requires somebody to say out loud which uses matter more than others, and that conversation surfaces disagreements about priority that were comfortable while they stayed implicit. It is also a short conversation, and it can be had once and written down. Two questions are enough for most organisations. Which uses can wait a few hours without anybody minding, and which uses would produce a call from a customer within ten minutes. Anything in the first group can be queued or dropped at the ceiling; anything in the second should fall back to something cheaper rather than disappear. What remains after those two questions is a small middle group that genuinely needs judgement, and it is much easier to think about a small group of hard cases than about everything at once.

Seen in the wild

A test loop left running overnight against an account with no ceiling.
OpenRouter
An automation retrying on failure and multiplying its own cost each pass.
Make
A feature falling back to a cheaper model instead of stopping at the limit.
ChatGPT

Common misconceptions

People assume

Alerts are enough.

In fact

An alert reports spending that has already happened, and the expensive cases happen faster than anybody reads notifications. Only a cap makes an amount impossible, which is the property being bought.

People assume

The number is the decision.

In fact

What happens at the ceiling matters more. A cap that stops everything protects the bill and can take a customer-facing feature offline at a moment chosen by accounting rather than by anybody responsible for the product.

Questions

What should happen when we reach it?: Ideally degradation rather than a stop: a cheaper model, a queue for anything not urgent, optional features switched off. That requires deciding in advance which uses are essential, which is the work the cap is really asking you to do.
How high should it be?: At a worst case you could absorb without difficulty, rather than at what you expect to spend. A cap sized to the forecast triggers on any ordinary surprise, and a team that raises it every time has turned a control into a monthly ritual.
One cap or several?: Several, split by use. A single ceiling covering experiments and customer-facing work means a runaway test can take the product down, which is precisely the outcome the cap was put in place to prevent, and the split costs nothing beyond deciding where the boundaries are.