LLM Spend Spike Alerts: Issues When Token Use Jumps by Feature or Customer

Last verified on Nov 10, 2026.

What it catches

A model bill does not fail loudly. A prompt that grew by a few thousand tokens, a retry loop around a model call, an agent that keeps calling tools because it never reaches a stopping point: all of these work. The answers keep coming back and the bill climbs. The cost reaches a human at the end of the month, and by then the loop has run for weeks.

LLM spend spike is the Sazabi detection for that. The Sazabi agent sets it up for your project: it reads your logs to find where model calls and token counts are recorded, and sets up sensors that ask whether usage jumps by feature, by customer or by job. The agent keeps them current as your system changes, so you do not define budgets per feature.

What the agent's sensors can ask about:

• Token usage for a feature running far above its usual level.
• One customer or tenant consuming a share of tokens out of proportion to its normal use.
• Repeated model calls inside one job, which is the signature of an agent loop.
• A prompt or context that suddenly grew, so each call costs more than before.

Example: an agent that cannot stop

This is an example, not output from a real project. A service called support-agent logs one line per model call with the feature, the customer and the token counts:

2026-11-08T12:00:04Z INFO support-agent llm_call feature=ticket_triage customer=org_204 job=j_9981 step=1 input_tokens=3200 output_tokens=410
2026-11-08T12:00:09Z INFO support-agent llm_call feature=ticket_triage customer=org_204 job=j_9981 step=2 input_tokens=6900 output_tokens=380
2026-11-08T12:00:15Z INFO support-agent llm_call feature=ticket_triage customer=org_204 job=j_9981 step=3 input_tokens=10600 output_tokens=402
2026-11-08T12:00:21Z INFO support-agent llm_call feature=ticket_triage customer=org_204 job=j_9981 step=4 input_tokens=14300 output_tokens=395

Each step carries more input than the one before because the whole history is resent, and the job has no step limit. Many such steps pile up for one customer. The sensor asks whether token use for this feature is far above its usual level, judged per customer, and Sazabi opens an issue. An example of what it could say:

• Name: ticket_triage agent loop consuming tokens for org_204
• Description: One job for org_204 has made hundreds of model calls without finishing. Input size grows with every step, and the feature's token use is far above its usual level.
• Severity: high

The evidence is the repeating call lines with growing input size. The analysis points at the missing stop condition as the likely cause. This is not only a cost issue: it is also an agent misbehaving, which is why the signal belongs to both the cost and agent categories.

Why spend and behavior go together

A loop is the same fault whether you read it as dollars or as steps. The sensor sees the symptom, a jump in token use, and the investigation looks for the cause in the calls themselves. That could be a loop, a prompt that grew, a retry around a failing model call, or a real rise in demand. The issue tells you which, so you can cap the right thing.

How you get told

A new issue sends an Issue triggered notification to in-app, email, Slack DM or SMS, or to a shared Slack or Microsoft Teams channel when a delivery rule matches severity, component or owning team. The team that owns the agent can receive it directly.

You can ask the agent follow-up questions in the issue, such as which other customers were affected. sazabi issues agent-prompt hands the fix, such as a step limit, to a coding agent. Resolve, ignore or mute the issue from the dashboard, Slack, Teams or the CLI. Recurrences fold into an open or ignored issue.

You can ask support for a specific sensor in plain words, for example "tell me when any customer's token use is far above its usual level". sazabi signals list --type sensor lists the sensor signals.

What it needs

Logs that record the model calls with token counts, and ideally the feature and customer. Frameworks log these through their AI framework integrations, and coding agents through the coding agent integrations. Your own code can send them through OpenTelemetry. The sensor can only split by feature or customer if the log lines carry them.

What it does not cover

• Stopping a call or applying a spend cap. Sazabi reports; limits live in your code or your provider account.
• Your provider invoice. It reads token counts in your logs, not billing data, and it does not cover cloud spend anomalies.
• Calls made outside your logging, such as a key used elsewhere.
• Judging whether the model's output was good. Quality shifts are a separate question.

For how to log tokens and price calls, see the LLM cost tracking guide. Issue volume is metered; see pricing.

A noisy deploy that inflates logs, not tokens, is log volume spike.