The four spike patterns
- The loop: an agent or retry cycle stuck on one user, the fastest and most expensive pattern, burning continuously until something stops it. Anatomy and real cases in the runaway detection flow.
- The abuser: someone scripting your free tier as a free API, machine volume from a single account, per the free tier survival guide.
- The misconfiguration: a deploy that points traffic at a far more expensive model. This one is a step change across all users, and per feature breakdown plus the model column is what makes it diagnosable in minutes.
- Prompt growth: conversations and context accumulating until every call carries more input, the slow spike, the compounding described in conversation cost math.
Why per user windows beat aggregate monitoring
The loop and the abuser, the two patterns measured in dollars per hour, are single user phenomena. Averaged into org wide spend they disappear: one user at 10,000 tokens a minute inside a thousand normal users moves the aggregate a few percent while quietly costing more than whole plans earn. A 5 minute window per user has no such dilution, the outlier diverges from its own baseline immediately, and the alert names the user, so the response (cap them, ban them, fix the retry logic) starts with attribution instead of an investigation. This is the same reason margin work needs per user data at all, the argument of finding your first unprofitable user.
Detection informs, enforcement guarantees
The alert lands in Slack or email within minutes (setup here), and that is enough at 2pm. At 2am, the layer that matters is spending caps: per plan monthly budgets checked before every call, blocking or downgrading the spiking user while everyone else proceeds untouched. The two layers read the same stream, so a spike becomes a bounded, alerted, attributed event: the alert tells you it happened, the cap decides how much it could possibly cost, and the loops page keeps the history for the postmortem.
FAQ
How do I detect an LLM cost spike before the bill arrives?
Watch token velocity per user in short windows, not aggregate spend per month. Weckr evaluates each user’s burn over a rolling 5 minute window as calls are logged and alerts when it crosses the threshold (50,000 tokens by default), which catches the fast spikes, loops, abuse, misconfiguration, within minutes of starting. Monthly aggregates detect the same events weeks later, as invoices.
What causes LLM cost spikes?
Four patterns cover most incidents: an agent or retry loop burning at machine speed on one user, abuse of a free tier by someone treating your feature as a free API, a deploy that accidentally routes traffic to a much more expensive model, and organic growth in prompt size as conversations or context accumulate. The first two are per user and fast; the second two show up as a step change across all users.
Why does spike detection need per user attribution?
Because the fastest, most expensive spikes are concentrated in one user, and aggregate monitoring dilutes them. A single loop burning 50,000 tokens in 5 minutes can hide inside normal looking org wide totals until it has run for hours. Per user windows make the outlier unmissable the moment it diverges, and tell you who to act on, not just that something happened.
What should happen automatically when a spike is detected?
Two layers: the alert (Slack or email, naming the user and the burn) for human judgment, and spending caps for guarantees, per plan monthly budgets checked before every call that block or downgrade the spiking user without touching anyone else. Detection without enforcement still depends on someone being awake; the cap is what bounds the 2am incident.
Can I tune the spike threshold?
Yes, the velocity threshold is configurable per project in the dashboard, no code change. The 50,000 tokens in 5 minutes default is calibrated to sit above any plausible human usage burst while catching machine speed loops early; products with legitimately heavy bursts (large document processing, long agent runs) can raise it to fit their normal.
Keep reading
Minutes are cheap, invoices are not
Every spike pattern above is detectable in its first minutes with per user velocity, and bounded automatically with caps. Both are included from the ten minute integration, free for 50,000 requests a month, with the loops and alerts views live on the demo.