Agent Misbehavior Alerts: Issues When an LLM Feature Burns Tokens Out of Pattern

Last verified on Nov 10, 2026.

An agent that misbehaves often does so quietly. It loops on a failing tool call, a prompt gets stuffed with a document ten times the usual size, a user script drives your assistant at machine speed. Each call returns a valid answer. What changes is the bill. The Sazabi agent sets up sensors that read your logs, and for LLM features one of them watches token use.

What is live

One signal feeds this category today: LLM spend spike. Token usage jumps by feature or by customer. The agent reads your logs, finds the events that record model calls, works out which fields carry the feature, the customer and the tokens, and writes and maintains the sensor. It also feeds the cost anomalies category, because the same jump is both a spend problem and a behavior problem.

Nothing else is claimed. An agent that calls an endpoint it has never used, or takes an action outside its job, is not covered today. What you get is the footprint of a runaway.

Example: a loop in a support agent

This is an example, not output from a real project. The service name and IDs are made up. Your support-agent service logs one line per model call:

2026-11-08T11:05:10Z INFO  support-agent llm_call feature=ticket_reply customer=cust_4821 prompt_tokens=3120 completion_tokens=410 tool=search_kb
2026-11-08T11:05:14Z INFO  support-agent llm_call feature=ticket_reply customer=cust_4821 prompt_tokens=3980 completion_tokens=395 tool=search_kb
2026-11-08T11:05:19Z INFO  support-agent llm_call feature=ticket_reply customer=cust_4821 prompt_tokens=4850 completion_tokens=402 tool=search_kb

The question the sensor asks, in plain words: "Tell me when the tokens used per customer for a feature go far above what is usual." Each customer is judged on its own. One customer's loop fires without hiding in the total of everyone else.

The issue could be named "Ticket reply agent looping for cust_4821", with high severity. The analysis notes the same tool called again and again with a growing prompt, and the evidence is the call lines. You start from that instead of from the invoice at month end.

How you get told

The sensor firing records a signal, and an investigation decides whether it is real. A launch that doubles legitimate use may close without an issue. A loop opens one. You see severity, the component and the agent's analysis. You can then ask in the thread whether that customer has done it before.

Delivery rules send the Issue triggered notification to the right place, such as the team that owns the agent. Ignore or mute from the dashboard, Slack, Microsoft Teams or the CLI. Run sazabi signals list --type sensor to see raw firings.

Repeated spikes from the same loop fold into the issue while it is open.

What you need

• One log line per model call, carrying prompt and completion token counts.
• A field that tells groups apart. Feature and customer are the usual two.
• A supported log source; the OpenTelemetry integration is common for instrumented LLM calls.

What it does not cover

• Tool choice, scope or permission problems in an agent. Rogue behavior judged by what an agent did is not covered today.
• Prompt injection. A hijacked agent that stays within its usual token budget will not trip a spend sensor.
• Spend on the provider's side that is missing from your logs. If a call is not logged, it is not counted.

For the vendor-neutral view of how to catch these by behavior, read the guide to agent misbehavior and the LLM spend spikes guide. For metering, see pricing.