Spend caps: the safety net your agent needs
A cap that fires before the tool runs is worth more than a dashboard that explains the damage after.
Agents spend money. Left unsupervised, a stuck loop can burn a week of budget in an afternoon. The cheapest fix is also the most effective: a hard spend cap that is evaluated before every action.
Before, not after
Dashboards that report spend after the fact are useful for review, useless for prevention. The cap has to sit in the hot path of execution — the moment the router is about to fire a tool, the runtime checks remaining budget. If the next call would exceed the cap, the call is revoked and an audit event records the reason.
At Refusion every runAgentTask call checks spent_usd against spend_cap_usd. Exceeding the cap returns a 402 and logs a revoked event — the agent stops, the bill stops, the team sleeps.
Make the cap cheap to change
Caps should be per-agent, not global, and adjustable in seconds. A research agent running a long batch needs headroom; a triage agent on a fixed SLA does not. Per-agent caps let you run both without risk.
Treat the cap as production config: versioned, observable, and revoked loudly. The first sign a cap saved you should be a notification, not a surprise invoice.