Token spend now behaves like early cloud spend did. The organisations getting ahead of it are treating cost as a design choice, made early and revisited often.
On today’s price lists, a million output tokens from Anthropic’s Fable 5 costs $50. The same million from Google’s Gemini 3 Flash costs $3, and open-weight models push the floor lower still. Most organisations are now buying across that whole range without being able to say which workload justifies which price. TokenOps is the discipline emerging to manage AI token costs with the same rigour as cloud spend, and tokens are now consumed right across the business and the delivery lifecycle: assistants and coding tools, document processing and back-office automation, evaluation runs and test environments as much as production systems.
Anyone who lived through the first decade of cloud will recognise the shape of the problem.
Why token spend misbehaves
An LLM invoice tells you total tokens and total cost. It tells you nothing about which workload consumed them, which team owns them, or whether they produced anything of value. Untagged and unattributed, token spend is a black box, and black boxes have a habit of becoming budget emergencies.
The economics compound this. Per-token prices are falling across most provider families, yet total spend keeps rising, because demand is elastic: as tokens get cheaper, teams add modality, lengthen reasoning chains, and give agents more autonomy. A stable monthly invoice can be hiding explosive growth in consumption, which is exactly the growth you want, provided you can see it and steer it.
Consumption is also wildly non-linear. A user question answered by a direct prompt to a small model costs a fraction of a penny. The same question routed through a retrieval pipeline, an agent loop, and a handful of tool calls can consume orders of magnitude more, and nobody made a single decision that caused it. It accumulated, call by call, across teams and use cases.
TokenOps applies the lessons of cloud cost management
The FinOps movement gave engineering and finance a shared language for variable cloud spend, built on a simple cycle: inform, optimise, operate. The same cycle works for tokens. Inform means being able to say who consumed what, for which purpose, and whether it produced anything of value, rather than reading a single total off an invoice. Optimise means acting on that knowledge. Operate means budgets, anomaly alerts and cost reviews on the same cadence as cloud spend. The measure worth building towards is token yield: the proportion of tokens consumed that actually contributed to a valuable outcome.
One difference from cloud cost management is worth naming precisely, because the whole discipline turns on it: token optimisation can change the quality of what the system produces. Cut context too aggressively, compress a prompt too far, route to too small a model, and the output quietly degrades. Every token optimisation therefore needs a quality check alongside the cost measurement, which is why TokenOps belongs to engineering as much as to finance.
Attribution is where AI token costs stop being a black box
Everything in TokenOps depends on attribution, and attribution is the piece with the fastest payback, and the one most organisations get to last. It is a few weeks of engineering, not a programme, and it is worth doing before any optimisation work. The first pass looks like this:
- Route every model call through a single gateway. An LLM gateway (LiteLLM, Portkey, Helicone, or your existing API management layer) gives you one place where every call is logged, priced and controlled. Consumption that bypasses it is consumption you cannot see.
- Issue credentials per team and per use case. A shared API key is an unattributable key. If three teams share one key, the invoice will never tell you which of them tripled their spend.
- Tag every call with team, use case and environment, and reject untagged calls, exactly as mature cloud estates reject untagged resources. Tags mandated today pay back on every invoice from here on.
- Separate production from evaluation and test spend. Both are legitimate, but they answer different questions, and evaluation runs are a common source of surprise bills.
- Publish cost per use case weekly, next to a quality measure for that use case, and give the report a named owner. Cost without quality invites false economies; quality without cost invites drift.
None of this requires a new tooling category. It requires the same decisions cloud teams made a decade ago, applied to a new meter. Once attribution is in place, the interesting conversations start: this use case consumes 40 per cent of spend and nobody can say what it returns; that one costs pennies and saves hours. Those conversations are the point.
Pay frontier prices only for frontier moments
Reserve frontier models for judgement
Anthropic’s advisor pattern is the cleanest published example. A cost-efficient executor model does the actual work. A frontier model sits behind it as an advisor the executor can consult, like any other tool, when it hits a wall. The advisor reads the transcript, returns a short course correction, and steps back. It never calls tools and never writes the user-facing output.
Anthropic’s published results show the value of this pattern. A mid-tier executor with a frontier advisor beat the mid-tier model working alone on a multilingual software engineering benchmark. It also cut the cost of each task by around 12 per cent. Their smallest model, given the same advisor, more than doubled its score on a hard web-research benchmark. It still came in well under the cost of running the mid-tier model throughout. The community has been building the inverse arrangement too. In some coding tools, the expensive model plans, decomposes and reviews. It then delegates the mechanical work, boilerplate, tests and formatting to cheaper subagents.
Same instinct, opposite direction. In both cases, the expensive model is reserved for judgement. Judgement is a small fraction of most tasks.
Set sensible defaults
For most organisations, the unglamorous version matters more than either pattern: sensible default models, set centrally, per class of task. These defaults should be written into platform configuration, so teams inherit them automatically.
Most production calls are classification, extraction, summarisation or drafting against a template. A mid-tier or small model can often handle these indistinguishably from a frontier one. An FOI response drafted to a template does not need the most expensive model on the market. A KYC investigation agent mostly does not either, until it hits a genuinely ambiguous case. That is exactly what escalation paths are for.
Make the frontier model something a team opts into with a reason. Then review the exceptions monthly.
The exceptions are where the next default comes from.
The market will not hold still while you decide
The price list improves every quarter for those ready to take advantage, though not every move is downward. Claude Sonnet 5’s introductory rate rises from $2 to $3 per million input tokens at the end of August 2026, challenging the assumption that prices only fall. But the floor keeps dropping. Z.ai’s GLM-5.2 is beating frontier models on long-horizon coding benchmarks at around a sixth of the price, while open-weight models have stayed only a few months behind the frontier for the past 18 months. The middle of the market is also being squeezed, with xAI’s Grok 4.5 positioned against models costing four times more. Each shift creates savings for organisations set up to capture them quickly.
And for a growing set of workloads the marginal token price is heading towards the cost of your own electricity. Local and self-hosted open-weight models have become a practical option, and in regulated settings they are often the preferable one: a clinical scribe whose audio never leaves the trust’s infrastructure, or a government workload with data sovereignty obligations that no API terms of service can fully discharge.
The sensible response is to avoid coupling your systems, or your business case, to any single model’s price point. Keep pricing assumptions in routing rules and default configurations, where they are cheap to change, rather than baked into a procurement, where unwinding them takes years.
The right answers depend on who you are
The recipe is yours to choose, and every profile has a good option. A central government department with sovereignty obligations and a five-year planning horizon will weigh local open-weight hosting very differently from a fintech searching for product-market fit, whose scarce resource is engineering time and for whom a managed API with sensible defaults, revisited quarterly, may be the better trade. Even your commercial plan changes the calculus: flat-rate subscriptions and per-token APIs reward completely different consumption behaviour, and a pattern that saves money on one can be irrelevant on the other.
And “it depends” is a reason to start, not to wait, because the one thing that does not depend on who you are is the value of starting early. Attribution is a few weeks of work, and everything it enables compounds from the day it is in place: the organisations that did it early are already routing yesterday’s frontier workloads to models a tenth of the price and funding the next use case with the savings from the last one. That is the position worth competing for, and it is open to anyone who starts this quarter.
What is common to everyone is the discipline. Instrument first. Set the defaults. Revisit them on a schedule, because the market will have moved by the time you do.
Turn token spend into a competitive advantage
The organisations that manage tokens well get more AI for the same budget: every saving funds the next use case, and every use case teaches them where the next saving is. A short TokenOps review is the fastest route to that position. We map where your tokens are going, what they are returning, and which defaults and escalation paths fit your obligations, whether that is a sovereignty-constrained government workload or a product team on a managed API. The output is an attribution plan and a set of model defaults you can put into effect the following sprint, in time to show up on the next invoice.
Find out more here: https://esynergy.co.uk/ai/
Common questions
What is TokenOps?
TokenOps is the practice of bringing visibility, allocation, optimisation and governance to LLM token consumption. In practice it means being able to attribute token costs to the teams and use cases that generated them, setting default models per class of task, and reviewing token budgets on the same cadence as cloud spend.
Is TokenOps different from managing cloud spend?
The operating cycle carries over directly. The difference is the resource: token optimisation can degrade model output quality, so every cost decision needs a quality check beside it, and that pulls engineering into the discipline alongside finance.
What is the first practical step?
Attribution. Put every model call behind a gateway, issue per-team credentials, mandate tags for team, use case and environment, and publish cost per use case next to a quality measure. With attribution in place, every optimisation is measurable from day one.
Do cheaper models mean worse results?
For most production workloads, no. Classification, extraction and template-driven drafting perform comparably on models costing a tenth of frontier rates, and patterns like Anthropic’s advisor approach show small models with selective access to a frontier model can outperform mid-tier models working alone. The craft is reserving frontier models for the judgement calls that genuinely need them, which is what escalation paths do.
Should we run models locally instead?
It depends on your obligations and your scale. For regulated or sovereignty-constrained workloads, open-weight models on your own infrastructure remove a whole category of data-handling risk, and models like GLM-5.2 have narrowed the capability gap to months. For everyone else it is a cost and operations trade: you exchange per-token fees for an inference platform you must run yourself.
