The Budget Enforcement Playbook

I. The lagging indicator problem

A monthly spend cap answers one question well: are we on pace to overspend this billing cycle. It answers almost nothing about a fast-moving problem — a $50-a-month agent that starts an infinite loop at $500 an hour will not trip a monthly budget for many hours, because the math simply hasn't accumulated to a meaningful fraction of the ceiling yet, even though the rate of spend is already ten times normal. Preventing overspend, rather than just measuring it after the fact, requires controls built on faster and more specific timescales than a monthly total — enforcement mode, hierarchy, rate, and per-run scope, each closing a gap the others cannot see.

II. Choosing an enforcement mode

“Enforce a budget” is not one behavior. A budget that always hard-blocks becomes a production outage the first time the limit is set a little too tight. A budget that only alerts never actually stops anything — a useful smoke detector, not a control. Three distinct modes exist because different calls need different answers to what happens when the limit is hit: Alert tracks spend and notifies without ever blocking a call — the right starting point for any new budget, before real traffic has proven the threshold is set correctly. Degrade automatically routes calls to a cheaper model once a configurable threshold is crossed, so the call still succeeds — at lower cost — rather than failing outright. Block rejects the call before it reaches the provider once the limit is reached, for the ceilings where continuing to spend past the line is a worse outcome than a failed call.

One exception applies regardless of configured mode: a call tagged as an agentic write operation — one that mutates external state, sends an email, executes a trade — gets a hard stop even under a degrade-mode budget, because a degraded model producing a subtly wrong write is a worse outcome than a blocked call. Read operations remain safe to degrade, since a lower-quality read is recoverable in a way a bad write often isn't.

III. The hierarchy that actually holds

A budget set independently at every level — one per run, one per feature, one per department — looks like protection but isn't, because none of those checks has visibility into what the others already spent. Fifty agent runs at $0.49 each all pass their own $0.50 per-run limit individually; their combined $24.50 total still blows through a $20 department budget, because nothing was checking the department total against each run as it happened. A real hierarchy evaluates every matching level together, atomically, on every call — so the parent ceiling always wins even when every child budget underneath it still technically has room.

IV. Catching a spike in under a minute

Hierarchy protects against sustained overspend across many calls. It doesn't, on its own, catch a sudden burst — a retry loop with no backoff that starts hammering a key at ten times its normal rate. That requires a check on a completely different timescale: a token-velocity circuit breaker that tracks tokens-per-minute per API key on a sliding 60-second window, and trips when the current rate crosses roughly ten times the key's own established baseline — catching the spike within the same minute it starts, not hours later once a monthly total would notice.

A brand-new key with no baseline yet is still covered by a fixed cold-start ceiling until enough history accumulates to calculate one, and the check itself runs on the same infrastructure already used elsewhere in the request path — sub-millisecond overhead on the normal case, and fail-open if the check itself becomes unreachable, so a rare infrastructure hiccup never blocks legitimate production traffic.

V. Capping a run, not just a call

Multi-agent workflows introduce a failure mode none of the above fully catches: ten subagents fanning out concurrently, each making calls that individually look completely reasonable, while the run as a whole quietly blows past any sane ceiling — because no per-call check has visibility into what other subagents in the same run have already spent. The fix is a shared, run-scoped counter every call in that run reserves against atomically, regardless of which subagent made it, so two subagents checking the budget at the same instant can't both see room available and both proceed past the limit.

None of this is achievable by reading billing data after the fact — atomic pre-call reservation is only possible from inside the request path, which is the same architectural reason enforcement in general requires a proxy rather than a read-only integration.

VI. The enforcement chain, together

Enforcement mode decides what happens when a limit is hit. Hierarchy decides which levels are checked at once. Velocity decides how fast a rate-based spike is caught. Run-level ceilings decide how a concurrent multi-agent execution is capped as a whole. None of the four is optional and none substitutes for the others — a hierarchy with no velocity check misses a fast burst; a velocity check with no hierarchy misses a slow, sustained overrun spread across many compliant calls. Run together, as one enforcement chain evaluated on every call, they close the gaps a single monthly total never could.