Every AI agent monitoring tool will tell you when you've gone over budget. Almost none of them will actually stop it from happening again five minutes later.
That's the gap between an alert and a kill switch, and it's the reason we built one.
The problem with alert-only budget monitoring
Here's the typical flow: your agent racks up an unexpected cost spike — a bad prompt loop, a retry storm, a runaway multi-agent chain calling itself in circles. Your monitoring tool notices, sends you an email or a Slack ping, and... that's it. The agent keeps running. It keeps spending. You find out you're over budget at the exact same moment your bill does.
An alert is a notification. It's not a brake pedal.
What the kill switch actually does
The kill switch is a monthly budget threshold, set per organization, with real enforcement:
- Cross the threshold, and every agent in the org auto-pauses — not "gets flagged," actually pauses.
- For SDK-integrated agents (
wrap(),monitor(), and nowwrapLangChain()/wrap_langchain()), the enforcement happens before the API call — the wrapped client throws a typedOpsVeritasKilledErrorinstead of ever reaching OpenAI, Anthropic, or Gemini. The cost genuinely stops, not just the notification. - One-click restart from the dashboard, with the same actionable guidance whether you restart one agent or all of them: raise the budget or disable the kill switch first if you want it to actually keep running past the next paid call.
- It resets monthly, with rollover — this is a recurring monthly cap, not a permanent lifetime ceiling you cross once and stay crossed forever.
- The SDK polls for kill state in the background (every 3 minutes), gated entirely on whether your org has opted in — if you never enable it, your agents generate zero extra background traffic. And if the poll itself fails for any reason (network blip, backend hiccup), it fails open — a transient monitoring issue should never be the thing that breaks your production agent.
The one honest limitation
This only works for agents integrated via the SDK. If your agent only sends telemetry over the generic webhook (the zero-code path for n8n, Make, or any custom script), you still get the alert — but there's no OpsVeritas code running inside your process to actually gate the call, so nothing stops running. We'd rather tell you that plainly than let you assume enforcement exists where it structurally can't.
Why this matters more than it sounds
The real cost of a runaway agent isn't usually the first spike — it's the one that keeps compounding while nobody's looking, because "I'll check the dashboard later" is exactly the gap a kill switch is built to close. An alert assumes a human is watching. A kill switch doesn't need one to be.
Available now on both SDKs (opsveritas-sdk on npm, opsveritas on PyPI). If you're already instrumented with wrap() or langchain(), enabling enforcement is a one-line addition — no re-architecture required.
Top comments (0)