Open your company's cloud billing dashboard. Find the line item for LLM API usage. Now try to answer: which team spent the most? On what tasks? Was it worth it? If you can't answer any of these, you're in the majority. Most engineering organizations treat token spend the way they treated cloud compute in 2014 -as an opaque, growing number that nobody owns.

The difference is that token costs scale with activity, not infrastructure. Every time an agent runs, it consumes tokens. Every time it sends too much context, it consumes more. And unlike a VM that sits idle, an overactive agent can burn through thousands of dollars in a single afternoon if it's stuck in a retry loop with your entire repository in its context window.

Why coding agents over-consume tokens

The root cause is coding agent context management. When a coding agent needs to understand your codebase, it has two options: send everything, or send the right things. Most agents default to sending everything -or at least, as much as they can fit in the context window. When the AI agent context window is too small, agents compensate by cramming in whatever fits.

Consider what happens when a developer asks an agent to "add error handling to the user service." The agent needs to understand the user service, the existing error handling patterns, the error types, the logging conventions, and probably the test patterns. Without intelligent retrieval, the agent might stuff 80,000 tokens of context into the request -the entire service file, related files, and whatever else it can grab -when it really needed 12,000 tokens of targeted context.

That's a 6.5x multiplier on a single request. Multiply by 40 developers making 15 agent requests per day, and you're looking at a significant cost difference between "send everything" and "send the right things."

The three sources of token waste

1. Redundant context loading

Coding agents without memory reload the same context on every request. The AI coding agent keeps forgetting what it already processed. A developer working on the same feature for three hours might make 20 agent calls. Each one re-reads the same files, re-parses the same types, re-ingests the same patterns. An indexed approach loads this context once and references it across the session, cutting input tokens by 40-60% for sustained work.

2. Retry spirals

When an agent produces code that fails a check -a type error, a failed test, a lint violation -it retries. Each retry includes the original context plus the error message plus the failed attempt. Three retries can cost more than the original request. With proper governance rules fed to the agent upfront, most of these failures never happen. The agent knows the constraints before it writes the first line.

3. Wrong-model routing

Not every task needs the most expensive model. Renaming a variable, adding a log statement, or formatting a file doesn't require the same model that architects a new service. Teams without model routing use the most capable (and expensive) model for everything, including tasks where a smaller model would produce identical output at a fraction of the cost.

Measuring what matters

Token spend is only meaningful when you can attribute it. "We spent $14,000 on Claude API calls last month" is useless information. "$3,200 of that was retry spirals caused by agents not knowing our test patterns" is actionable.

Useful token metrics include:

  • Cost per accepted line of code. How many tokens does it take to produce a line that actually ships? This normalizes for productivity and catches teams where agents are generating code that gets deleted.
  • Retry ratio. What percentage of agent requests are retries from failed previous attempts? A retry ratio above 20% signals missing context or unclear rules.
  • Context efficiency. Of the tokens sent as context, what percentage was actually referenced in the agent's output? Anything below 30% suggests the agent is being given irrelevant information.
  • Cost per developer per day. Not as a budget target, but as a variance detector. If one developer's agent spend is 5x the team average, they either found something valuable or their workflow is wasteful.

Indexed retrieval vs. stuffing the context window

The fix is simple: index your codebase so agents can retrieve exactly what they need instead of loading everything. This means building a structured map of your code -functions, types, dependencies, patterns, conventions -and letting the agent query it.

When a developer asks the agent to add error handling, an indexed system retrieves the existing error handler base class, two examples of how other services implement it, the relevant test helper, and the logging format. That's 12,000 tokens of precisely targeted context instead of 80,000 tokens of "here's everything in the directory."

The difference compounds. Over a month, a 50-person team with indexed retrieval will spend 40-60% less on tokens than the same team stuffing context windows. And the code quality is often better because the agent has relevant examples instead of noise.

Making token spend visible

The first step is attribution. Every agent request should be tagged with the developer, the project, the task type, and the outcome (accepted, rejected, retried). This turns an opaque API bill into an engineering metric you can manage.

The second step is setting baselines. Once you can see where tokens go, you can identify the patterns that waste them and the workflows that use them efficiently. Some teams discover that 30% of their token budget goes to a single workflow that could be restructured.

The third step is optimization -indexed retrieval, model routing, and governance rules that prevent retry spirals. These aren't one-time fixes. As your codebase evolves and your team's agent usage matures, the optimization needs to evolve too.

Token costs don't have to be a mystery. They just need the same instrumentation and discipline that engineering teams already apply to every other resource they consume.