By Adam Wolf
Cloud FinOps took the better part of a decade to earn its visibility: bill shock, then dashboards, then allocation, then optimization, then governance. AI tokens rebuilt the blind spot in about two years. Nearly every FinOps team now says it manages AI spend, but for many of them, “managing” means a line item on an invoice, not knowing which team, which product, which agent, or which model the money went to. This piece is about translating the FinOps disciplines to the token era: why the old playbook breaks, why model switching is the new rightsizing, and why the answer has to live in the execution path rather than in a report.
FinOps won the cloud. Then the unit of spend changed.
The FinOps arc is one of the quiet success stories of the last decade. Uncontrolled cloud adoption produced bill shock; bill shock produced visibility; visibility produced allocation, optimization, and eventually governance. The discipline matured to the point that this year the FinOps Foundation formally changed its mission from managing the value of cloud to managing the value of technology. The same report shows why: 98% of FinOps teams now manage AI spend, up from 31% just two years ago, and AI cost management is the number one skillset practitioners say they need to develop. That is not gradual adoption. That is a discipline being handed a new mandate almost overnight.
Here is the uncomfortable part: “manage” is carrying a lot of weight in that statistic. Most teams can show that AI spend exists. The invoice says OpenAI, Anthropic, AWS Bedrock, or Azure OpenAI, and the number at the bottom is real. What far fewer can do is decompose that number: which business unit, which application, which user, which agent, which model, which request. Cloud FinOps solved exactly this problem for compute a decade ago with tags, accounts, and cost allocation. Tokens arrived without any of that scaffolding, and the unit of spend changed underneath the discipline that had just finished building it.
How did tokens break the cloud playbook?
Because the meter, the buyer, price, and speed of spend are no longer stable the way cloud compute was. Four things make token spend structurally different from the compute spend FinOps grew up on.
The meter moved. An instance-hour is predictable: you provisioned it, you can see it, and it costs the same tonight as it did this morning. A token bill scales with prompt length, output length, and whether someone toggled a reasoning mode, and reasoning models routinely generate 10 to 100 times more tokens per query than non-reasoning models. The same feature, used the same way by the same team, can cost an order of magnitude more this week than last week without anyone provisioning anything.
The buyer multiplied. Cloud spend was committed by a small number of people through procurement. Token spend originates from prompts, and prompts come from everyone: engineers, analysts, operations teams, and increasingly the agents they build. A meaningful share of that spend does not even touch the company’s accounts, because employees are running agentic tools on personal API keys, which means the invoice FinOps can see is a floor, not a total.
The price is a moving target. Compute prices move slowly and publicly. List prices can span one to two orders of magnitude between frontier reasoning models and small task models: as of August 2026, Anthropic's Claude Fable 5 lists at $10 per million input tokens while OpenAI's GPT-5.6 Luna lists at $0.20 and its GPT-5 Nano at $0.05, a 50x to 200x spread, and further once self-hosted open-source models enter the mix. Providers reprice as new versions ship, and the same request costs differently depending on whether its input was cached. The cost of a workload is no longer a property of the workload. It is a property of the routing decision that served it.
Spend happens at machine speed. Cloud waste accumulated monthly and was caught monthly. Agents spend continuously, and they do not get tired or suspicious. In one widely discussed incident from late 2025, a four-agent pipeline looped for 11 days with no budget cap or termination condition before the team found the $47,000 bill in its billing data. Alerts, even when they fire, report spend that has already happened. That is a detection model built for human-speed mistakes, applied to actors that make mistakes at machine speed.
What is model switching?
Model switching is routing each request to the least expensive model that still meets the quality bar for that task, instead of sending every request to the same model regardless of complexity. It’s the rightsizing of the token era, and it’s arguably more powerful.
The classic optimization lever in cloud FinOps was rightsizing: matching the instance to the workload instead of paying for headroom nobody used. The token era has an equivalent, and it is arguably more powerful, because cloud rightsizing moved a workload between adjacent instance sizes, while model switching can move a request across that entire price span and still meet the quality bar.
Model switching, routing each request to the least expensive model that meets the quality bar for that task, is where the real money is. A contract-analysis request may genuinely need a frontier reasoning model. A classification or extraction request almost never does. Routing done well is worth more than most volume discounts providers offer.
But switching only works if you can see. Three visibility requirements come with it.
- Cost per task, not just cost per token: a cheaper model that needs three retries to produce valid output is not cheaper.
- Model-aware attribution: when the router changes where requests land, finance needs to know which model served which tenant at what price, or every forecast breaks the day the routing policy improves.
- Both ledgers in one view: a request served by an in-house open-source model on your own GPUs carries an infrastructure cost, not a token invoice. A true optimization decision compares the two. An organization that can only see its API bill will quietly over-route to whichever ledger it cannot see.
How do you translate FinOps disciplines to tokens?
Re-map each discipline to the token instead of the instance: visibility means attributing every request in one gateway, allocation means giving humans and agents their own budget lines, optimization means routing to the cheapest model that clears the quality bar, and governance means enforcing that budget at request time instead of reporting on it after the fact.
Visibility. Every model request, in-house, open-source, or third-party, flows through one gateway and is attributed at the moment it happens: which user or agent, which team, which project, which model, how many tokens, at what price. Sampling and monthly invoice parsing do not get you there. Being in the request path does.
Allocation. Showback and chargeback by tenant, where showback reports each tenant’s spend and chargeback bills it to their budget, and tenants include the workforce’s agents, not just its people. Agents need their own tenancy for exactly this reason: an agent without its own budget line is spend attributed to nobody.
Optimization. Model switching as policy rather than heroics: route by task class, cache aggressively, right-size context windows, and measure cost per task so the routing decisions can be defended. This is the model switching lever, running as policy instead of a one-off decision.
Governance. Budgets that act, not budgets that report. A dashboard can tell you a team blew its token budget last month. A gateway in the execution path can decline the next call, throttle the runaway agent, or downgrade a low-priority workload to a cheaper model before the money is gone. The $47,000 loop was not a visibility failure alone; the team had billing data. It was an enforcement failure. Nothing was positioned to stop call number ten thousand.
How does Klique bring FinOps to AI tokens?
Klique, the enterprise AI orchestration platform, delivers this framework end-to-end through three connected engines.
Visibility
It starts with identity: the Governance Engine gives every human and agent a real, scoped identity with per-user and per-agent keys instead of shared credentials. The AI Engine routes every model request through that same gateway, attributing tokens and spend to the identity that generated them the moment the request happens.
Every model, whether it is in-house, open-source, or a third-party API sits behind that one gateway. That is what makes attribution automatic rather than forensic.
Allocation
Allocation follows from that same identity. Spend rolls up by user, group, project, and model. That is how every tenant, agents included, gets its own budget instead of disappearing into a shared invoice.

Because Klique’s Orchestration Engine manages the GPU estate as well, the two ledgers land in the same control plane: token spend on external APIs and infrastructure spend on the models you host yourself, where they can be compared. That is the prerequisite for honest model switching, and it is the foundation of the visibility layer that AI Velocity is measured on: utilization, spend by business unit, and adoption, in the same control plane that enforces the policies.
Optimization
Optimization is the model switching described above, running as policy. The AI Engine sends each request to the cheapest model that clears the quality bar.
Governance
Governance closes the loop: quotas, rate limits, and per-tenant budgets are applied in-line, at request time. That turns FinOps from a reporting function into a control.

The FinOps principle has not changed in a decade: see it, allocate it, optimize it, govern it. The token era just moved the meter, multiplied the buyers, and put the price behind a routing decision. You cannot manage what you cannot see, and for tokens, the only place seeing actually works is in the path the request travels.
If you would like to see what governed token visibility looks like on your own infrastructure, request a demo.
Frequently asked questions
What is AI FinOps?
AI FinOps applies the same visibility, allocation, optimization, and governance disciplines that cloud FinOps built for compute spend to AI model and token spend, so it is tracked and controlled the same way.
What is model switching?
Model switching means routing each AI request to the least expensive model that still meets the quality bar for that task, instead of sending every request to the same model regardless of complexity.
How is AI token spend different from cloud compute spend?
Token spend changes with prompt length, output length, and reasoning mode rather than a fixed hourly rate, comes from far more requesters across the organization, and can run up continuously without a human noticing, unlike a monthly cloud bill.
How does Klique control AI token spend?
Klique routes every model request through one gateway with a real identity attached to each user and agent, then enforces quotas and rate limits inline at request time, rather than reporting overspend after it already happened.
