Imagine the monthly AI review begins with a victory slide. Token consumption is up. Requests are up. More teams are using copilots and agents. The dashboard is precise, colourful and completely confident. Then someone asks the awkward question, what did the business get back?
That is where the dashboard usually becomes less certain. Every model call leaves a detailed cost trail in the form of input tokens, cached tokens, output tokens, tool calls and latency. Very few leave an equally useful value trail. When cost is visible and value is not, token volume becomes an easy proxy for adoption, productivity and momentum. It is the wrong endpoint.
Tokens tell us how much computational work an AI system attempted. They do not tell us whether a customer issue was resolved, a contract risk was caught, a sales opportunity moved forward or an employee avoided an hour of administrative work. A workflow can consume more tokens and create more value. It can also consume more tokens because it is verbose, poorly routed, stuck in a loop or solving a problem nobody needed solved.
The goal is not to minimise tokens. The goal is to make these tokens accountable to an outcome.
A precise cost trail is not a value trail
The major AI platforms already give teams the mechanics to manage consumption. OpenAI's cost guidance recommends reducing unnecessary requests and tokens, selecting the smallest model that preserves accuracy and using Batch or Flex processing where the workload allows it. Microsoft's Azure guidance adds the operating discipline around that advice that tag spend by tenant, feature and environment, then put caching, routing, batching and model changes behind evaluation gates. That is good engineering. It still does not answer the investment question.
Cost optimisation asks, "Can we deliver the same quality for less?" ROI asks, "Was this workflow worth funding in the first place?" A beautifully cached agent that produces work nobody accepts is still waste. A relatively expensive agent that prevents a material compliance loss may be an excellent investment.
This distinction matters more as systems become agentic. One user request can trigger planning, retrieval, several model calls, tool execution, reflection, retries and human review. The FinOps Foundation's guidance for AI makes the useful shift explicit that measure the total cost of achieving a business outcome, such as a customer query resolved or a code review completed, rather than treating raw tokens or GPU hours as the result.
The model call is a cost event. The workflow outcome is the value event.
Measure two things, not one
I would keep two measures side by side.
Token-spend efficiency tells us how much incremental value a model, prompt or routing policy creates for its model-and-tool spend. It is useful when comparing technical options inside the same workflow.
Workflow ROI tells us whether the whole investment is economically worthwhile.
Here, V is realised incremental value, S is model-and-tool spend and C is fully loaded AI cost.
"Fully loaded" is doing important work in that formula. The cost is not only input and output tokens. It includes cache reads and writes, retrieval, search, tool calls, orchestration, observability, retries, evaluation, human review and rework. AWS's Bedrock cost documentation is a useful reminder that even token accounting has multiple price lines; input, output, cache-read and cache-write tokens can all be charged differently. If the workflow crosses other services, the invoice extends well beyond inference.
Value needs the same discipline. It should be incremental, realised and compared against a credible baseline. A support agent should be valued through accepted resolutions and labour that was genuinely redeployed. A sales agent should be connected to incremental gross margin, not emails drafted. A risk agent should be assessed through the probability-adjusted losses it prevented, not the number of policies it summarised.
"Time saved" is not automatically value. If ten minutes disappear from a task but the organisation never converts those minutes into additional capacity, better service, lower cost or faster revenue, the benefit is theoretical. Useful, perhaps, but not yet realised.
Give every workflow an outcome ID
The bridge between cost and value is attribution. A production AI log should not stop at model name and token counts. It should also carry the workflow, tenant or customer, environment, outcome ID and the final disposition of the work: accepted, edited, escalated, abandoned or rejected.
For agentic systems, that outcome ID needs to survive the entire run. Ten model calls, three tool calls and one retry may all belong to one customer resolution. Measuring each call independently makes the system look busy. Grouping them under the final outcome lets us ask whether the busyness was useful.
A practical scorecard can stay small:
| Leadership question | Metric that helps answer it |
|---|---|
| Did the workflow produce usable work? | Acceptance, rework, escalation and abandonment rates |
| Are we delivering the same outcome more efficiently? | Fully loaded cost per accepted outcome |
| Does more context or reasoning improve the result? | Marginal quality gain and marginal ROI per additional step |
| Is the value reaching the business? | Realised value against a holdout, A/B test or pre-AI baseline |
Raw tokens are still useful. They help diagnose prompt bloat, cache misses, runaway loops and routing mistakes. But because tokenisation and prices vary between model families and versions, token ratios are most meaningful inside a stable technical comparison. Across models and architectures, cost per accepted outcome is the more durable measure.
A support workflow that looks better and performs worse
Consider a customer-support agent that delivers 3,600 accepted resolutions per month. Each accepted resolution avoids six minutes of work at a loaded labour cost of $45 per hour. That creates 360 hours, or $16,200, of theoretical capacity.
Now apply a reality discount. Assume only half of that capacity is genuinely redeployed into useful work. Realised monthly value is therefore $8,100. The workflow costs $1,200 in model usage, $300 in retrieval and monitoring, and $600 in quality assurance. Its fully loaded monthly cost is $2,100.
The cost per accepted resolution is about $0.58. That is a meaningful operating number. A team can watch it over time, compare it with the baseline and investigate changes in quality or cost.
Now give the agent a larger model, much longer context and deeper reasoning loops. Accepted resolutions rise from 3,600 to 3,720, but monthly cost rises to $5,400. At the same 50% reality discount, realised value becomes $8,370, so total ROI falls to 55%.
The more revealing calculation is at the margin. The additional 120 resolutions create only $270 of realised value while the new configuration costs another $3,300. The marginal ROI of the change is approximately -91.8%.
Accepted output improved. The investment got worse.
This is the problem with treating a stronger model, longer context window or deeper agent loop as an automatic upgrade. The right question is not whether the new configuration performs better. It is whether the improvement is worth what it costs.
Tokenmaxxing turns the input into the target
The idea of "tokenmaxxing" takes the proxy problem to its logical extreme; reward people or teams for consuming more AI tokens as evidence of adoption and productivity.
Usage data can be helpful during an adoption phase. It can reveal where experimentation is happening and identify people whose working practices might be worth sharing. But the moment raw consumption becomes a performance target, it becomes easy to game. Verbose prompts, unnecessary agent loops, duplicated work and low-value experiments all make the number go up.
DORA describes raw token count as an activity metric that lacks the context needed to judge performance. The risk is not abstract. Amazon confirmed that an internal token-use leaderboard was deprecated after it encouraged activity that did not necessarily solve customer or business problems. The lesson is not that usage metrics are useless. The lesson is that adoption and productivity are different questions.
Token consumption may tell a leader whether people are trying the tools. It cannot tell them whether the tools are improving throughput, quality, customer experience or economics. The closer a metric gets to performance management or investment allocation, the closer it must get to an outcome.
More tokens can still be the right answer
An outcomes-based approach is not a campaign for tiny prompts and cheap models everywhere. That would be another form of metric blindness. Complex, ambiguous or high-risk work may justify more context, more reasoning, more specialist agents and more human review. If an additional $500 of inference and review reduces expected compliance losses by $20,000, the marginal ROI is 3,900%. Spending more is clearly rational.
The same principle applies to quality. A cheaper model is not cheaper if it creates enough rework, escalation or customer harm to erase the saving. A short agent loop is not efficient if it routinely stops before the task is complete. A cache hit is not valuable if it serves an answer that should have changed. The target is not minimum tokens. It is maximum risk-adjusted value.
That gives leaders a practical operating rule. Give every workflow an outcome metric, a value hypothesis and a quality gate. Route routine work to cheaper models. Escalate uncertain or high-value cases. Cache stable context. Batch asynchronous work. Cap retries and agent steps. Then review cost per accepted outcome, not just aggregate consumption.
Stop adding tokens when their marginal value falls below their marginal cost or below the return the organisation requires.
The most mature AI program will not be the one with the biggest token graph. It will be the one that can explain, with evidence, which outcomes improved, what those outcomes were worth and how much the system spent to create them.
Tokens are an input. Outcomes are the point.
Until next time.