Token Anomaly Detection: The Algorithm That Stops Runaway Loops Before the Bill Arrives

The Problem: Why Token Spikes Hide in Plain Sight

Most AI teams monitor agent executions at the binary level: succeeded or failed. The agent gets 200 OK, so it worked. But there's a whole category of failure that standard monitoring misses: the execution that succeeds but consumes 10× its normal token budget in the process.

This happens most often when an agent enters a loop. It calls a tool, checks the result, calls the tool again to refine, checks again—each iteration adds to the token count. Twenty iterations later, an execution that should have cost $0.02 has cost $2.00. And it still returns 200.

By the time you see the spike in your monthly invoice, you've already lost thousands.

The fix isn't to ban loops—sometimes agents need iteration to get the right answer. The fix is to detect meaningful token anomalies before they become expensive—in the first execution, before the cascade.

The Math: Percentile Baselines and Z-Scores

A solid anomaly detector needs two parts: a baseline that captures "normal," and a method to detect when an execution drifts far from it.

Part 1: Build a Percentile Baseline

Don't use the mean. A running average is too easily pulled upward by a few expensive runs, and it doesn't tell you about the shape of your typical behavior.

Instead, track percentiles of token usage over a rolling window (typically 30 days or the last 100 runs, whichever is larger):

p50 = median token count
p95 = 95th percentile token count
p99 = 99th percentile token count

Why percentiles? Because they're robust to outliers. If your agent normally uses 500 tokens but one run uses 50,000 (an anomaly you're trying to catch), the median and p95 stay grounded in typical behavior. The mean would shift.

Part 2: Flag a Token Spike When Z > 2.5

Once you have your baseline (especially p95), check each new execution:

z_score = (tokens_this_run - p95) / standard_deviation

If z_score > 2.5, flag it. (2.5 is a threshold; adjust based on false-alarm tolerance. Higher = fewer alarms but risk missing real spikes; lower = more false alarms but catch edge cases earlier.)

Why 2.5 and not 2? At 2.0 standard deviations, you'd expect ~2.3% of normal runs to be flagged (false alarms). At 2.5, it's ~0.6%. For cost governance, false alarms are cheap (annoying, but you're just investigating); missing a real spike costs money.

The Code Sketch

import numpy as np
from collections import deque

class TokenAnomalyDetector:
    def __init__(self, window_size=100, z_threshold=2.5):
        self.window = deque(maxlen=window_size)
        self.z_threshold = z_threshold

    def record(self, token_count):
        self.window.append(token_count)

    def is_anomalous(self, token_count):
        if len(self.window) < 10:  # Need enough data
            return False

        tokens_array = np.array(self.window)
        p95 = np.percentile(tokens_array, 95)
        std = np.std(tokens_array)

        if std == 0:  # All runs identical (rare, but handle it)
            return token_count > p95 * 1.5

        z_score = (token_count - p95) / std

        is_anomaly = z_score > self.z_threshold

        # Record the run for future baselines
        self.record(token_count)

        return is_anomaly

Record every execution's token count in the window. When a new execution arrives, compute p95 and standard deviation from the window, calculate z_score, and flag if it breaches the threshold. Then add the new execution to the window.

Why Correlate With Latency

Token anomalies often come paired with latency spikes. If an execution took 10× its normal tokens and took 5× longer to complete, it's almost certainly looping or stuck in retry logic.

Add a second signal:

latency_z = (latency_this_run - p95_latency) / std_latency
anomaly = (token_z > 2.5) and (latency_z > 2.0)  # Both must spike

Requiring both signals to spike simultaneously is more conservative—fewer false alarms—but you catch the real culprits: the agent that both burned tokens and took forever. That's a loop.

If you want to catch even fast anomalies (e.g., an agent that made 50 tool calls in rapid succession, token-heavy but latency-OK), track tool-call count as a third signal:

tool_calls_z = (tool_calls_this_run - p95_tool_calls) / std_tool_calls
anomaly = (token_z > 2.5) or (tool_calls_z > 2.5)  # Either signal fires

Now you catch both slow loops (token + latency spike) and fast loops (token + tool-call count spike).

Putting It Together: The Alert

When an anomaly is detected, surface it immediately:

• Which agent: name and framework.
• What spiked: tokens (from 500 to 12,000), latency (from 2s to 15s), tool calls (from 3 to 47).
• The baseline: "normal p95 is 600 tokens; this run was 20× higher."
• The cost: if tokens spike 10×, cost spiked 10×. Show the dollar amount to make it real.
• The action: link to the run's full execution trace so you can see which tool call started the loop.

In the AI Agents Control Tower, this surfaces as a Token Anomaly alert—one of the 12 alert types you can subscribe to. It fires only when a run's token usage jumps far above the agent's baseline, so you catch cost problems before they compound.

Why This Matters

The difference between detecting a runaway loop in its first execution (cost: $0.50, alert received in seconds) and detecting it in your monthly invoice (cost: $5,000, damage already done) is an anomaly detector.

The math is simple. The impact is large.

---

Further reading: If you're building AI agents, set a token baseline from day one. Use percentiles, not averages. And correlate token spikes with latency and tool-call count—multiple signals reduce false alarms and catch real problems faster.