When LLM Agent Token Spikes Hide Real Failures

Your LLM agent just finished 200 runs. The average was 1,200 tokens per execution. One run used 8,400. Was that normal? Was it a feature, or a bug hiding in plain sight?

Most teams wake up to this question too late — when a single agent run has burned $50 or a tool-use loop has drained a day's budget in an hour. By then, the anomaly has already happened. The question shifts from "how do we catch this?" to "how do we stop it next time?"

Token anomalies in LLM agents fall into two categories. Most of what you'll see is variance — normal, healthy, explainable — a slightly longer context, a retry loop that succeeded, a multi-step reasoning chain that took longer than average. The agent did what you asked; it just needed more fuel this time. But buried in that variance is the second category: runaway patterns — loops that never terminate, prompt injections that balloon context, tool calls that spiral into themselves. These look identical to variance from the inside. To the agent, it's all just tokens consumed. To your cost, it's the difference between a $5 run and a $500 run.

The key is not whether a spike exists. It's whether you can tell the two apart.

Why Static Thresholds Fail

The obvious approach: set an alert threshold. "If a run uses more than 5,000 tokens, page me."

This works until it doesn't. A legitimate multi-step reasoning chain on Monday uses 6,200 tokens. That's normal for your agent's behavior — it was solving a genuinely complex problem. Your threshold fires anyway. You investigate. It's fine. You raise the threshold to 8,000. Then a real runaway hits 7,500 and slides past silently.

Static thresholds have a fundamental problem: they don't know your agent. They don't know what "normal for this agent" means. Normal for an agent that summarizes documents is 800 tokens. Normal for an agent that does multi-step research is 4,000. Normal for an agent that retries on failure can spike to 6,000 on a bad day. A threshold that works for one is noise for another.

Static rules also don't distinguish between kinds of anomalies. A token spike can mean:

1. Legitimate complexity — the agent encountered a harder problem and reasoned longer.
2. Retry loops — the agent failed, tried again, succeeded. Higher tokens, but it worked.
3. Tool spirals — the agent called a tool, got an unexpected response, kept trying, burned tokens chasing a dead-end.
4. Prompt injection — hostile input bloated the context window (less common but catastrophic).
5. Model response degradation — the model started producing verbose outputs (token-wasting, not harmful).

A static "5,000 token" threshold can't tell the difference. It just knows the number exceeded a line.

Baseline-Aware Anomaly Detection

The pattern that actually works starts with this: every agent's token consumption has its own distribution.

Track the tokens for every execution your agent runs — not forever, just the recent history (30 days is typical). This gives you a baseline: the mean, the standard deviation, the shape of the distribution. Now, when a new run comes in, you don't compare it to an arbitrary number. You compare it to this agent's own history.

Here's the math that matters:

• Normal variance: a run that uses tokens within mean + 2σ (standard deviations) is almost certainly explainable — harder problem, more reasoning steps, legitimate retry. These are rare false positives.
• Anomaly threshold: a run that exceeds max(mean + 2σ, 3× the mean) is statistically unusual for this specific agent. Worth investigating, but not necessarily an emergency.
• Runaway zone: a run that hits mean + 4σ or exceeds 10× the mean is very likely a loop or spiral. This one needs a kill-switch.

The threshold adapts to the agent. A research agent that normally runs 4,000 tokens will trigger an anomaly alert at 7,000 (mean + 2σ). A summarization agent that normally runs 600 tokens will trigger at 1,200. Same statistical rule, completely different alert thresholds. Each agent gets the precision it needs.

The Runaway Pattern: How to Spot It

Real runaway loops have a tell: they don't just spike once. They usually exhibit a pattern.

A legitimate spike (legitimate complexity) tends to be isolated. One run uses 8,000 tokens. The next five use 1,200, 1,100, 1,300 — back to normal.

A runaway pattern shows sustained elevation or escalation. You see three consecutive runs at 2.5× the baseline, then the fourth hits 4×. Or token consumption ticks up over five runs: 1,500 → 2,000 → 3,000 → 5,000 → 8,000. The agent is in a spiral; each iteration eats more context than the last.

Some frameworks can catch this with a sustained-anomaly detector: flag a run only if the current execution AND the prior 2–3 executions both exceeded the baseline by 2σ. This kills false-positives from one-off spikes while catching real escalation patterns early.

The cost difference is enormous. Catch a runaway on the second anomalous run, and you've stopped it at maybe $30 overspend. Let it continue until run six, and you've hit $500. Detection speed is the moat.

Actionable Signals: What to Actually Watch

If you're instrumenting token anomalies in your agent, track these:

1. Per-execution tokens — raw count, so you can compute baselines.
2. Token spike ratio — current_tokens / mean_tokens for the agent. A ratio >3 is worth attention.
3. Consecutive anomalies — flag when ≥2 runs in a row both spike. This separates one-offs from patterns.
4. Cost-per-token baseline — some agents might legitimately burn tokens at different rates depending on the model or context. Track cost-to-token ratio too, not just absolute tokens.

The real value comes from tying these to action. An alert on a single spike? That's noise — you'll investigate and find it was legitimate reasoning. An alert on three consecutive spikes, with a cost-per-token ratio 1.5× higher than baseline? That's actionable. Stop the agent. Investigate why it's spiraling. Fix it. Restart.

The Bigger Picture

Most LLM agent monitoring today focuses on whether an execution succeeded (HTTP 200, output generated). Tokens are usually an afterthought — tracked, logged, but not actively watched for anomalies.

That's a gap. Token consumption is one of the few metrics that scales linearly with cost. In a world where one runaway agent run can burn 10× your daily budget, letting token anomalies slip past is betting your infrastructure on luck.

The agents that operate reliably aren't the ones with perfect code. They're the ones with eyes on what actually ran — including the metrics that reveal cost spirals before they become disasters.

A baseline-aware detector won't catch every issue. But it'll catch the ones that matter most: the patterns that repeat, the anomalies that escalate, the loops that hide in the data.

Start with the baseline. Build your agent's token profile from its real history. Then use that profile to see what's normal — and what's not.

The rest is automation: alert on the anomaly, stop the agent, investigate. By then, you'll have kept the damage to a single run instead of watching it compound into a day-long burn.

---

Want to watch token anomalies across your LLM agents in real time? Baseline-aware detection is built into AI Agents Control Tower — no configuration needed. Connect your agent, and we auto-compute its baseline and flag anomalies as they happen. Free tier covers up to 3 agents.