Agents Waste Millions of Tokens Before a Bad Line

Q: What did Sonar’s trace of an AI coding agent actually show?

On one roughly 800-line pull request in Sonar’s own codebase, the agent made 512 model round trips, reached a peak context window of 458,700 tokens, and accumulated 152.8 million cache-read tokens. Across 18 comparable pull requests, the average cost was around $65. Most of that volume came from re-reading the same code over and over.

Q: Why is token waste a reliability signal and not just a cost problem?

Because repeated reads, unnecessary tool calls, and a steadily growing context are symptoms of an agent that is struggling to find, retain, or use the information it needs. The same behavior that inflates the bill is the behavior that leads to missed dependencies and failed builds. Treating tokens purely as a cost metric throws away that evidence.

Q: Don’t observability dashboards already cover this?

Dashboards show that something happened: latency, token consumption, error rates. They don’t show why. The explanation lives in the sequence of what the agent saw, what it decided, which tools it called, what came back, and where its behavior changed. That requires examining the execution itself, not just monitoring it from the outside.

Q: What should an agent trace be used for beyond debugging?

It should serve as evidence for an AI outcome, not only as a tool engineers open after something breaks. A good trace makes wasteful behavior obvious while it is happening, lets engineers follow the path that led to a miss, and lets a team prove what happened between the first input and the final result rather than guess from the final response.

Sonar recently traced an AI coding agent working through an approximately 800-line pull request in its own codebase. The agent made 512 model round trips, reached a context window of 458,700 tokens, and accumulated 152.8 million cache-read tokens. Across 18 comparable pull requests, the average cost was around $65.

Most of the conversation around this will probably focus on the bill. But we should be paying more attention to the behavior that created it.

Token waste is telling you something

An agent reading the same 600 lines hundreds of times isn’t just an expensive agent. It’s an agent struggling to navigate the task.

That distinction matters. If we treat token consumption as nothing more than a cost metric, we miss one of the most useful signals about how an agent is actually behaving. Repeated reads, unnecessary tool calls, growing context, and long execution paths can tell us that the system is having trouble finding, retaining, or using the information it needs.

In other words, the waste is evidence.

The question shouldn’t simply be, “How do we make the agent use fewer tokens?” It should be, “Why did the agent behave this way?”

The final answer doesn’t tell you enough

This is where evaluating agents gets fundamentally different from evaluating traditional software.

A conventional application either produces the expected result or it doesn’t. When something breaks, engineers can generally work backward through logs, errors, and application state.

Agents introduce another layer: the system is making decisions about what to do next.

An agent can search the wrong file, miss a dependency, make an incorrect assumption, repeat a tool call, or carry irrelevant context forward for dozens of turns. The final output may be where the failure becomes visible, but the actual problem happened much earlier.

Looking only at the final result means you’re looking at the end of the story.

The trace is the story.

A failed build might have started hundreds of steps earlier

Sonar also found that grep missed call sites reaching through interfaces and across languages. That is particularly interesting because it shows how the cost problem and the reliability problem are connected.

The agent wasn’t simply spending too many tokens. It was navigating an imperfect understanding of the codebase. That navigation eventually contributed to a failure.

This is exactly the kind of problem that gets harder to diagnose as agents become more capable and autonomous.

When an engineer misses a dependency, you can ask them what they were looking at and why. When an agent does it after hundreds of model and tool interactions, you need evidence of that execution path.

Without it, engineers are left staring at that final failure and trying to reconstruct what happened from fragments.

More autonomous means more history to understand

This problem gets even more significant as systems move from single-agent interactions to multi-agent workflows.

One agent might retrieve information. Another might analyze it. A third might use a tool to take an action. The final outcome may look perfectly reasonable, or completely wrong, without making it obvious where the deviation started.

Adding more agents doesn’t just add more capability. It adds more execution history. That history needs to be understandable.

Otherwise, we’re building systems that can take increasingly complex actions while making it increasingly difficult to determine why they took them.

Observability isn’t the whole answer

There’s a temptation to solve this by adding another dashboard.

Dashboards are useful for seeing that something happened. They can show latency, token consumption, error rates, and other important metrics.

But knowing that an agent consumed 150 million tokens doesn’t tell you why it did.

The important information is buried in the sequence: what the agent saw, what it decided, which tools it called, what those tools returned, what context carried forward, and where its behavior started to change.

That’s why agent reliability requires more than monitoring the system from the outside. You need to be able to examine the execution itself.

The trace should be evidence, not just telemetry

This is the shift I think the industry needs to make.

An agent trace shouldn’t just be something engineers look at when a system is already broken. It should provide the evidence needed to understand an AI outcome.

If an agent spends hundreds of turns repeatedly reading the same code, the trace should make that behavior obvious. If it misses a dependency, engineers should be able to follow the path that led to the miss. If an agent produces an unexpected outcome, the goal should not be to guess what happened based on the final response.

We should be able to prove it.

Because the real problem with an unreliable agent isn’t that it used too many tokens or made one bad decision.

It’s that we don’t know what happened between the first input and the final outcome.

Sonar’s analysis makes the cost of that problem visible. The bigger opportunity is recognizing that the same trace that explains the bill can also explain the failure.

And as agents take on more responsibility, that may be the more important thing to measure.