How do you put a hard cap on runaway agent spend?

A developer built a provider-agnostic circuit breaker that vetoes agent calls to Anthropic and OpenAI before they fire once a budget is exhausted, with budgets scoped globally, per-provider, per-agent, or per-session on either dollar cost or call count, and is asking for feedback on how others cap runaway agent spend. The developer argues existing cost tools such as Langfuse, LangSmith, Portkey and Helicone only report spend after the fact, and that a check-then-veto design leaks under retry loops because ten in-flight retries can all pass the budget check before any lands in the ledger. The proposed fix is to make the pre-call step an atomic reservation of the call's worst-case cost (max tokens at the model's price), settle to actual cost or release on failure, fail closed when the ledger is unreachable, and test with 50 parallel calls against a nearly exhausted budget.

Genuine question for people running agents in production: if one of your agents got stuck in a retry loop overnight, what actually stops it before morning? Most cost tools I’ve looked at Langfuse, LangSmith, Portkey, Helicone are great at showing you what you spent — but that’s a dashboard you read the next day, after the money’s gone. I kept wanting the thing one layer earlier: something that vetoes the call before it hits Anthropic/OpenAI once a budget’s blown. So I built it — a circuit breaker with budgets scoped globally, per-provider, per-agent, or per-session, on either dollar cost or call count. Provider-agnostic adapter pattern, spend ledger, forecasting dashboard. Curious what everyone else is doing here — rolling your own caps? Trusting provider-side limits? Just eating the occasional surprise bill? What’s worked? Happy to share what I built if it’s useful — don’t want to turn this into an ad, so just say the word. The check-then-veto step has a race in it: ten retries in flight can all pass the budget check before any of them lands in the ledger, so the cap leaks exactly in the loop it is built for. Make the pre-call step a reservation instead — atomically hold the call’s worst-case cost max tokens at the model’s price against the budget before it fires, then settle to the actual cost or release it on failure — and fail closed when the ledger itself is unreachable. Test it by firing 50 parallel calls at a nearly-exhausted budget: a hard cap lets through only the ones the remaining budget can fully reserve.