High Token Usage Is Not Waste. Unaccepted Output Is.

The second run has the smaller token bill. It is the more expensive piece of engineering.

Every efficiency programme that measures tokens will reward the second run and penalise the first. That is the problem.

Efficiency is a ratio, and the argument above is really an argument about which denominator to use. Cost per token is a vendor metric: it describes the meter, not the work. It is available, precise, and almost useless for deciding anything.

The useful denominator is output that survived. A change that was accepted in review, merged, released, and still standing a month later. Measured that way, the second run in the example costs a premium model’s worth of retries, plus several hours of senior review, plus a defect fix – divided by one change of routine value. The first costs more tokens divided by one migration that shipped clean.

This reframing matters because the two metrics move in opposite directions more often than teams expect. Cheaper models shift cost from the meter to the reviewer. Smaller context windows shift cost from the meter to the retry count. Neither shift shows up on a bill, and both are frequently celebrated as savings.

Before any of this can be measured, it helps to be honest about why the bill moves the way it does. The first generation of enterprise AI purchasing was predictable: a company selected a coding tool, bought seats, assigned licences, and reviewed utilization before renewal. That model has not disappeared. It is simply no longer the whole cost.

The billing mechanics also differ between vendors, which means a portfolio does not have one behaviour. GitHub Copilot combines assigned licences with pooled AI credits and additional usage beyond the pool. Claude Code costs move with model selection, codebase size, context, automation, and parallel agent activity. OpenAI API pricing distinguishes between input, cached input, output, and tool-related usage.

The published figures show how wide the resulting range runs. Anthropic’s own cost guidance for Claude Code puts average enterprise usage at roughly $13 per developer per active day and $150 to $250 per developer per month, with 90 percent of users staying under $30 on an active day. A tenfold spread between a normal day and a heavy one is not an anomaly in that model. It is the model.

A single developer may use an IDE assistant, a command-line coding agent, an internal AI workflow, and a direct model API inside the same delivery cycle. Each system calculates usage differently, resets allowances on a different schedule, and reports at a different level of detail. Forecasting the total is difficult. Forecasting whether the total was well spent is a different exercise entirely, and it is the one that matters.

High token usage is not automatically a problem. A team may use a capable model to complete a difficult migration, investigate a production incident, generate a meaningful test suite, or accelerate an important feature. The work can justify the consumption.

Low token usage is not automatically a sign of efficiency either. A team may be paying for unused seats. Developers may avoid a tool because it does not fit their workflow. A cheaper model may produce output that requires extensive correction. An inexpensive agent may attempt the same task repeatedly while quietly generating review work for someone else.

DORA’s 2025 report, State of AI-assisted Software Development, describes AI’s primary role as an amplifier: it magnifies the strengths of organizations that already deliver well, and the dysfunctions of those that do not. Read as an efficiency finding, that is a warning. The same spend in two organizations will not return the same value, so an efficiency benchmark borrowed from someone else’s blog post tells you very little about your own.

Answering the question properly requires connecting spend to the work it paid for, which is a separate discipline with its own requirements. We cover it in AI cost attribution for engineering teams. This article stays on the narrower question: given that connection, where is the waste?

Real waste is specific. These are the six patterns worth instrumenting first, roughly in order of how much money they tend to hide.

Note what unites them. None of these are visible from a token total, and all of them are addressable without reducing anyone’s access to AI. That is the difference between an efficiency programme and a spending freeze.

Most organizations discover AI overspend after it has happened. By then the team has already selected the model, loaded the context, run the agents, repeated the attempts, and created the work that has to be reviewed. The money is spent and the rework is queued.

Effective governance has to operate before the billing period closes. That requires visibility across contributors, teams, tools, models, agents, and workflows. Useful controls can include company and team budgets, model guidance by type of work, alerts before thresholds are crossed, forecasted overruns, detection of repeated agent loops, visibility into premium model usage, and review of high-cost activity that produces little accepted output.

The purpose is not to restrict useful adoption, and this is where most cost programmes go wrong. A blanket spending limit reliably reduces a visible bill. It also stops valuable work, and it stops the valuable work first, because the expensive tasks are disproportionately the important ones. Good governance directs teams toward the appropriate resource for each task and makes it easier to expand investment where the evidence supports it.

Vendor controls remain useful, but they govern one product at a time. A developer who hits a limit in one tool will move to another, and the portfolio total will not improve. Engineering leaders need a governance model that follows the work across the whole AI estate.

Milestone treats efficiency as a question about output rather than a question about volume. It connects AI activity with the engineering signals that reveal whether consumption converted into work that lasted.

Governance tied to actual work

AI Governance and Limits brings company limits, team budgets, tool and model usage, and agent activity into a single connected view. Controls can be evaluated in the context of teams and workflows rather than through one vendor’s billing interface.

Visibility into agent behaviour

Agent Observability exposes what autonomous runs actually did — attempts, tool calls, and whether the run ended in accepted output. Retry loops and abandoned sessions are the two largest sources of quiet waste, and neither is visible from a cost report alone.

Cost read against quality

AI Quality connects AI-generated changes with review effort, rework, and post-release fixes. This is what separates a genuine saving from a cost that moved somewhere less visible.

One ledger to compare against

AI Spend Hub unifies tool, licence, seat, token, model, and agent costs, so seat utilization and model mix can be reviewed across the portfolio instead of one vendor console at a time.

Six questions. Each one targets waste rather than volume.

A “no” here does not mean money is being wasted. It means waste, if present, is currently indistinguishable from healthy spend.

The goal was never to minimize tokens. Minimizing tokens is trivially easy and reliably counterproductive: turn the tools off and the metric goes to zero.

The goal is to raise what the AI portfolio returns per unit of spend — which means finding the retries, the abandoned sessions, the idle seats, the context nobody needed, and the cheap output that someone else paid for in review. All of it is addressable. None of it is visible from an invoice.

Organizations that get this right will not have the smallest AI bills. They will have the smallest gap between what they spent and what survived.

1. What is AI token spend management?

AI token spend management is the practice of monitoring, evaluating, and governing the cost of model usage across AI coding tools, assistants, APIs, and agents. In an engineering organization it means judging consumption against what it produced – accepted output, review effort, rework – rather than against a monthly total.

2. Is high token usage always a problem?

No. High usage may be entirely justified when it supports complex or valuable work such as a difficult migration, a production investigation, or a meaningful test suite. The relevant question is whether the delivery improvement, quality, or saved effort justified the cost, not whether the number was large.

3. Why is AI token spend so hard to forecast?

Spend varies with the model used, input and output volume, context size, session length, retries, tool calls, automation, and the number of agents working in parallel. Organizations also combine seats, allowances, credits, tokens, and on-demand charges across several vendors, each metered on a different schedule.

4. How do you reduce AI coding costs without slowing teams down?

Target waste rather than volume. Retry loops, abandoned sessions, unused seats, unnecessary context, and cheap-model output that generates rework can be reduced without removing capability. A blanket spending cap does the opposite: it lowers a visible bill while also stopping valuable work.

5. Which AI efficiency metrics should engineering leaders track?

Track cost per accepted change rather than cost per token, alongside retry and abandonment rates, review effort per AI-assisted pull request, rework and post-release fixes on AI-generated code, seat utilization, and the share of spend on sessions that never reached production.