Your AI kill switch is on the invoice. It belongs on the request path.
A FinOps engineer posted a question that quietly names the entire problem with controlling agent costs: how do you catch the large share of a failed agent run’s tokens that burn after the first failure signal has already fired? Citing an agent-trace study, they put that share around 58%. And they pointed at the scale that makes it dangerous — some orchestration frameworks fan out to many subagents at once (they cited a ceiling of 16 concurrent and 1,000 total calls in a single run). If your only backstop is a monthly, or even daily, bill-anomaly rule, that ceiling can produce a very expensive Wednesday afternoon long before anyone reads the alert.
Attribution is the easy half
The FinOps world says “attribution” as if the hard part is knowing who spent the tokens. It isn’t. The hard part is knowing when to trip the breaker — mid-run, while the money is still going out the door. The trace shows the signal is there: the repeated call, the failure marker, the loop. The tooling to act on it in real time usually isn’t, because the tool is a dashboard — and a dashboard is a reporting tool, not a kill switch. It tells you tomorrow what you spent today.
Put the breaker on the request path, not the invoice
The best answer in the thread is also the whole thesis of this series: you can cut a run off mid-flight — but only if the breaker sits on the request path, not the invoice. Route every model and tool call through one gateway (LiteLLM, Helicone, or your own) and enforce per run there.
Most of the burn happens after the warning fires — cut it mid-run.
And this dissolves the attribution-vs-enforcement gap people keep tripping over. Once every call carries
a run_id and an owner tag through the gateway, attribution and enforcement share the same key.
You don’t build attribution first and bolt the breaker on later — the tag that tells you who spent the
money is the exact tag the breaker trips on.
Cheap signals worth tripping on, mid-run
Because everything flows through one door, these are configuration, not a research project:
- Identical tool call. Hash
tool_name + args; if the same hash repeats N times in a run, halt. That “burns after the first warning” number is mostly this — the repeated identical call is the warning. Trip on it directly. - Per-run budget. A hard token/dollar ceiling per run, not per month. A month is thirty days too late; a run is the unit that actually goes rogue.
- Fan-out and depth cap. Max concurrent subagents and max total calls per run, so a single run can’t recruit a thousand helpers before anyone notices.
- Step / wall-clock cap. A run that’s been going too long, or too many steps, is usually stuck — not working.
The production caveat: cancel the run, not the service
The reason teams don’t wire a hard kill switch is real: high-availability production. A global stop is its own outage. But the breaker here isn’t global — it’s scoped to the run (and the key). You cancel the one runaway workflow, not the service. That’s the same fail-closed-vs-degrade decision from the spend-cap post, one level down: per run, do you hard-stop or degrade?
This is exactly why “we’ll catch it in tomorrow’s cost review” loses — and it loses hardest on platforms with no real-time AI cost reporting (Azure came up in the thread), where the next-day dashboard is the only tool many teams have. By next day, the Wednesday-afternoon burn already happened.
It’s the same pattern, one grain finer
Gateway → per-key caps and quotas → per-run breaker. Each is the identical idea at a finer resolution: enforcement belongs on the request path, where you can still do something about the spend — not on the invoice, where all that’s left is to read about it. The uncapped meter doesn’t get capped by watching it more closely. It gets capped by putting a switch in the wire.
If you’re running agents and your only cost control is a bill alert, there’s a runaway run with your name on it somewhere in the next few months. Wiring the breaker onto the request path is the gap I close. Every message comes straight to me — I read and reply to each one myself, usually within a day, and what readers send shapes what I build next. It’s just me for now, so that’s genuinely true; it won’t be forever. Send me your agent setup and I’ll tell you where a run can still go unbounded — free, within a business day.