Why velocity, not volume
A monthly budget catches a runaway after it has spent the month’s money. The signature of an agent loop is not volume, it is speed: token consumption no human produces, from one account, in minutes. That is why detection keys on tokens per user per window, and why the default, 50,000 tokens in 5 minutes, is set well above any human usage pattern and well below an overnight disaster. Both numbers are configurable per project in settings. The wider failure pattern is covered in AI agent loop detection.
The flow, step by step
- The burst begins. An agent retries in a loop, a user scripts your endpoint, an integration goes wrong. Each call is logged as usual: user, feature, tokens, cost.
- The window trips. After each logged event, the rolling window for that user is checked server side, as fire and forget background work that never blocks your request path.
- The alert fires. Slack (via the incoming webhook you pasted in settings, no OAuth) and email, naming the user id, the token volume, and the window. A per user cooldown prevents repeat spam from the same burst.
- The history records it. The Alerts page keeps every firing with expandable raw metadata, plus a top burners table for the last hour, so the 2am incident is reconstructable at 9am.
- The cap bounds the damage.Independent of alerting, if the user’s plan has a spending cap, the pre call check blocks or silently downgrades them to a cheaper model once their monthly budget is spent. Alerting tells you; caps guarantee the ceiling. Choosing between block and downgrade is its own decision.
The verification, honestly reported
This flow is not a diagram of intentions. Our release verification runs the published SDKs against production with a mock LLM backend and drives every path, including this one: a synthetic runaway burst for a test user tripped the velocity window, the alert fired with the correct user and token count, and the history row appeared with the raw metadata. The same suite verified cap blocking (the SDK throws WeckrCapError before any spend) and downgrade (the call silently proceeds on the cheaper model) at their exact thresholds. Two honest footnotes from testing: a single sustained burst can write several history rows instead of one, cosmetic duplication we have logged as cleanup, and that same verification round caught two real billing bugs elsewhere which we fixed and shipped the same day. That is the standard this feature has been held to.
Seeing it without an incident
The live demo includes the Alerts page on seeded data, thresholds, history, and the top burners table, so you can walk the exact screens this article describes with no signup. Wiring your real project takes the ten minute integration plus pasting a Slack webhook URL.
FAQ
How does Weckr detect a runaway agent?
By velocity, not volume. Every logged call updates a rolling window per user, and when one user burns more than the threshold, 50,000 tokens inside 5 minutes by default, configurable in settings, a velocity alert fires. Volume thresholds catch runaways at the end of the month; velocity catches them in the minutes they are actually running.
What happens the moment the threshold is crossed?
The alert fires through your configured channels, a Slack message via your incoming webhook and an email, naming the user, the token volume, and the window. It is recorded in the alert history on the Alerts page with the raw metadata attached, and a per user cooldown stops the same burst from spamming you with repeats.
Does detection stop the agent or just tell me?
Detection alerts; enforcement is the spending caps layer. If the user is on a plan with a cap, the cap check before each call blocks or downgrades them once their monthly budget is exceeded, independent of alerting. The pair is deliberate: velocity tells you something abnormal is happening now, caps guarantee a ceiling on the damage either way.
Has this actually been tested end to end?
Yes, against production. Our release verification drives a synthetic runaway, a burst of real API calls through the published SDK for one test user, and the velocity alert fired within the window with the correct user and token count. The same run verified cap blocking and model downgrade at their exact thresholds. One honest footnote from that test: a single sustained burst can write several alert history rows rather than one, a cosmetic duplication we have logged.
What does a runaway actually cost without detection?
The arithmetic is unforgiving: an agent looping on a mid tier model can burn 50,000 tokens in minutes, and left running overnight that is millions of tokens, tens to hundreds of dollars, from one user, invisible until the invoice. The detection threshold exists precisely because this failure mode is fast, silent, and always attributed to one account.
Keep reading
The alert you want to never need
Runaway detection is insurance: invisible until the night it pays for the whole subscription. It is on by default from the moment you integrate, free for 50,000 requests a month. See the alert screens on the demo, or start with the ten minute integration.