Why your AI bill keeps growing while token prices fall
Token prices dropped 67% year-on-year between Q1 2025 and Q1 2026, from $18.40 to $6.07 per million tokens, yet 73% of enterprises still exceeded their AI budgets over the same period. That contradiction is the central problem for engineering leaders trying to plan AI spend.
The explanation is structural. A single user querying a model once produces one inference call. An agent completing the same task may produce dozens: planning steps, tool calls, self-correction loops, sub-agent delegations, and a final synthesis pass. Each of those is a separate inference call, often across different models at different price points. The unit cost per token falls; the number of tokens consumed per business outcome rises faster. Gartner predicts that AI inference costs per agentic workflow will increase more than fivefold through 2028, even as token prices continue their decline.
This article explains the cost drivers that are specific to agents, how to instrument your workflows to surface them, and how to attribute spend to behavior rather than raw consumption.
The cost drivers that token pricing hides
Raw token counts tell you what was consumed. They do not tell you why. Four agent-specific behaviors account for most of the gap between expected and actual spend.
Iteration count
Agents that use a plan-then-act loop call the model at least twice per task, once to plan and once to act. Agents that verify their own output, or that retry on tool failure, add more calls. A customer support agent resolving a single ticket might call a model six to ten times if it checks context, drafts a response, validates tone, confirms policy compliance, and retries after a failed API call to a backend system. Each iteration compounds the token count because the full conversation history is typically included in every subsequent prompt.
If you are measuring cost per ticket rather than cost per token, iteration count is the lever with the most direct effect on that number. Tracking it separately from raw token volume is the first step toward controlling it.
Model switching
Most production agents do not use a single model. A multi-agent orchestrator might route planning tasks to a large frontier model and execution tasks to a smaller, cheaper one. Routing logic that works correctly in development can drift in production: a classifier that routes too many tasks to the expensive model, or a fallback that triggers more often than expected, will inflate costs without any visible quality change. The bill goes up; the output looks identical.
LLM gateways and routers can record which model handled each call, but the useful signal is which task type triggered the switch and how often. Without that attribution, model-switching costs are invisible in aggregate billing.
Planning horizon
Agents that plan over longer horizons, decomposing a task into ten steps rather than three, consume more tokens in the planning phase and produce more downstream calls. Research-style agents and autonomous background agents are particularly prone to this. Planning depth is often a prompt configuration choice, not a model constraint, which means it is adjustable without any model change.
Tool call overhead
Every tool call that an agent makes typically adds tokens: the schema describing the tool, the arguments passed, and the response returned. A RAG retrieval agent that retrieves five document chunks per step, across ten steps, may add tens of thousands of tokens per run that appear nowhere in the task description. Tool call frequency and retrieval depth are cost drivers that have no equivalent in single-turn pricing models.
Attributing cost to behavior, not consumption
The shift from measuring tokens to measuring behavior requires instrumentation at the span level. Each discrete agent action, a planning call, a tool invocation, a sub-agent delegation, a retry, should produce a span with its own token count, model identifier, latency, and a label describing what the agent was doing at that moment.
With span-level data, you can answer questions that aggregate billing cannot: which step type costs the most per run, which task categories trigger the most retries, and whether a specific agent version introduced a planning pattern that doubled inference calls for a subset of inputs.
This is the instrumentation layer that OpenTelemetry was designed for, and it is what Prefactor records when the SDK wraps an agent's execution. Each span carries the behavior label alongside the token count, so cost attribution is a filter rather than a forensic reconstruction.
What production deployments reveal
The companies that have moved agents to scale are discovering these dynamics in their billing, not in their architecture reviews.
Klarna's customer service agent handled 2.3 million conversations in its first month, November 2025, cutting resolution time from 11 minutes to under 2 minutes. At that volume, a one-call-per-conversation design and a six-call-per-conversation design differ by millions of inference calls per month. The efficiency of the agent's internal loop determines whether the unit economics hold as volume scales.
Morgan Stanley's DevGen.AI tool processed 9 million lines of legacy code by January 2026, saving 280,000 developer hours. A coding agent working on legacy translation has a high tool call surface: it reads files, runs linters, checks compilation, and iterates on errors. Each of those steps has a token cost. Measuring the ratio of tokens consumed to lines successfully translated is a concrete cost-efficiency metric that per-seat or per-token billing cannot produce on its own.
Salesforce's Agentforce delivered 2.4 billion agentic work units across sales, service, and marketing workflows by February 2026. At that scale, even a small per-unit token overhead compounds into material infrastructure spend. Salesforce's internal deployment of the same platform handled 1 million employee conversations per year with a 75% resolution rate without human escalation, saving over 500,000 employee hours. The resolution rate matters for cost because every escalation is a failed run: tokens spent without a completed outcome.
General Mills has used AI models for supply chain optimization since fiscal year 2024, assessing more than 5,000 daily shipments and realizing $20 million in savings. The agent assesses each shipment as a discrete task. At 5,000 tasks per day, planning depth per task has a direct and measurable effect on daily inference spend.
The metrics that matter for agent cost evaluation
Once you have span-level instrumentation in place, the metrics worth tracking fall into three categories.
Per-outcome cost tracks total tokens consumed across all spans for a completed task, divided by the count of successful outcomes. This is the agent equivalent of cost per conversion.
Iteration efficiency measures the ratio of task-completing runs to total runs, weighted by token cost. An agent that completes 75% of tasks in three steps and retries the remaining 25% for six steps has a predictable cost curve. An agent where that ratio drifts has a cost that will surprise you.
Model routing accuracy measures whether the routing logic is sending tasks to the model it was designed to use. If a task category that should route to a small model is hitting a large model 30% of the time, that is a configuration issue with a measurable dollar cost.
Detecting quality decay in production is related: a degrading agent tends to retry more, escalate more, and consume more tokens per outcome. Cost drift and quality drift often appear together, which means cost metrics serve as an early signal for reliability problems.
This connection between cost and reliability is why agent evaluation in production needs to cover both. A quality score without a cost dimension misses the feedback loop between the two. Prefactor scores both alongside each other, so a spike in per-outcome token cost appears in the same view as the quality metrics for the same run.
For teams managing multiple agent types, measuring token efficiency and cost as agents scale and understanding the hidden token overhead in production are the natural next reads. Validating agent behavior against expected outcomes closes the loop between cost attribution and behavioral correctness.
The structural shift is from budgeting a price per seat or a price per token to budgeting a price per outcome, with iteration count, model routing, and planning depth as the variables you actually control. That requires instrumentation, not just billing data.
Where to start
Attach span-level tracing to your agents before you try to optimize anything. Without labeled spans, cost data and quality data stay separate and neither tells you which agent behavior to change. Start with one agent type, measure per-outcome cost for two to four weeks, and compare it against the planning depth and iteration count distributions in that window.
Start evaluating your agents or read the docs to see how Prefactor instruments spans and attributes cost to behavior.