Ten Years Ago, Cloud Created FinOps. LLMs Are About to Create AI FinOps.

A field guide to the cost governance discipline that’s about to become real

I spent several years working closely on FinOps before I moved fully into AI product work. Multi-cloud cost management. Cost attribution. Anomaly detection. The whole discipline. It taught me something I didn’t fully appreciate at the time.

A new economic model doesn’t become a new discipline because the bill gets bigger. It becomes a new discipline when the existing ways of measuring, attributing, optimising, and governing spend stop working.

That’s what happened with cloud between 2013 and 2018. And that’s what’s happening with LLMs right now.

The bills are arriving. The attribution is broken. The people making cost decisions have no visibility into what those decisions cost. Finance can’t see the spend at the granularity that matters. Engineers and PMs are making trade-offs — model choice, context length, retry policy, reasoning mode — that each carry price tags none of them can see.

I’ve watched this movie before. Different lead actors. Same plot.

But there’s an important difference this time, and it changes everything downstream.

Cloud FinOps taught organisations to answer: what infrastructure are we consuming, who is consuming it, and what is it costing us?

AI FinOps has to answer a harder question: how much intelligence are we consuming, why are we consuming it, and was that intelligence worth what we paid for it?

That distinction matters. Because tokens are only the meter. The thing businesses are actually buying is intelligence. And the thing they ultimately care about is the outcome that intelligence produces.

The category doesn’t have a settled name yet. I’ll call it what it is — AI FinOps — because the parallel to cloud is exact enough to be worth naming plainly, and because the extensions AI adds turn it into a discipline of its own.

This piece is a field guide to what I think that discipline becomes. The three pillars it inherits from cloud FinOps, translated for LLMs. The three coinages that name the new cost categories AI FinOps has to reason about — the Reasoning Tax, the Token Budget, and Cost Trajectories. What’s genuinely harder about LLM economics than cloud economics. And what mature AI FinOps looks like in 2–3 years.

If you’re a PM, an engineering lead, or a CFO looking at an AI bill you can’t fully explain, this is for you. The bill is going to keep growing. The question is whether you build the discipline to govern it, or wait until the CFO does it for you.

Let’s start.

What FinOps actually solved

Before the parallel, a quick grounding for anyone who came into tech in the LLM era.

FinOps didn’t emerge because cloud was expensive. It emerged because cloud created an economic model that traditional IT financial governance couldn’t handle. Three things happened at once.

Cost became variable and consumption-driven. In the on-prem era, IT infrastructure was capital expenditure. Cloud replaced that with per-hour, per-request, per-gigabyte pricing that scaled with usage. Infrastructure became something you consumed, not simply something you owned.

Cost decisions moved to engineers. They were now the ones choosing instance sizes, storage tiers, autoscaling policies, data-transfer patterns. Each of these was a cost decision. None of the engineers making them had training in cost management, and most had no visibility into what their choices cost.

Existing controls couldn’t see the spend at the right granularity. Finance got a monthly bill from AWS. What they couldn’t see: which team, which product, which feature, which engineer’s late-night experiment drove which portion. Attribution was broken.

The response — over roughly five years — was FinOps. A shared discipline built on three pillars: Inform, Optimise, Operate. Make the spend visible and attributable. Match spend to value. Treat cost as a shared operational responsibility across engineering, finance, and product.

FinOps didn’t stop cloud spending. It made cloud spending governable. That distinction is important. Because AI doesn’t need a discipline that simply makes AI cheaper. It needs a discipline that makes AI economics governable.

The same three conditions are back

Look at what’s happening with AI. The three conditions that created FinOps are all present again. Not analogously. Literally.

Cost is variable and consumption-driven. Per-token pricing at the provider level. Per-request pricing for reasoning modes. Per-second pricing for extended thinking. Per-image pricing for multi-modal. A single query can cost fractions of a cent or several dollars depending on which model routes it, how much context it carries, how much reasoning it does, how many tool calls it triggers. The meter is running while the product is thinking.

Cost decisions have moved to PMs and engineers. Which model do we route to? How much conversation history do we carry? How verbose is the system prompt? How aggressively does the agent retry when a tool fails? How many sub-agents can the orchestrator spawn? Every one of these is a cost decision, made by a product or engineering person, usually with no visibility into what the decision costs at scale. The people writing the prompts are the people setting the bill.

Existing financial controls can’t see the spend at the right granularity. Finance sees the OpenAI bill, the Anthropic bill, the Google Vertex bill. What they cannot see: which product, which feature, which customer tenant, which query pattern is driving which portion. Provider-side reporting has improved but is still not attribution-grade for a mid-sized enterprise’s needs.

The bills are still small compared to cloud bills. That’s the thing that makes this feel less urgent than it is. AWS bills in 2013 weren’t the AWS bills of 2018 either. The urgency of a category isn’t determined by the current bill. It’s determined by the growth curve and the direction of travel. Both, for AI, are steep and up.

The response is going to be the same as it was for cloud. A discipline that makes AI spend visible, attributable, and governable. It’s already emerging in fragments — cost dashboards, model routing layers, provider observability tools. What it hasn’t yet done is cohere into a named practice with a shared vocabulary and a set of standard patterns.

That’s the space AI FinOps is about to occupy.

Inform — measure intelligence, not just tokens

The first pillar of FinOps was making spend visible in ways finance and engineering could both work with. Not just “here’s the total bill” but “here’s what drove it, broken down by team, product, feature, and pattern of use.”

AI FinOps starts in the same place. But the information hierarchy that matters is different.

Most organisations today start with total AI spend. That’s useful. It’s also insufficient. The real hierarchy looks like this:

Provider → Model → Product → Feature → Task → Trajectory → Outcome

The deeper you can go, the more useful the economics become.

Imagine your AI bill increased 40% quarter over quarter. The default answer is “we used 40% more tokens.” A better answer is “the support agent generated 25% more sessions.” Better still: “most of the increase came from the new troubleshooting workflow.” Better again: “that workflow increased context consumption by 60%.” And ultimately: “the workflow increased cost per resolved case from $0.11 to $0.17 while resolution quality stayed flat.”

Now you have something you can act on.

That’s the difference between cost reporting and AI FinOps.

The end state of Inform isn’t per-request visibility. It’s cost tied to business outcome. Because not every request is equally valuable — an expensive query that closes a deal is cheap, a cheap query that no one reads is expensive. The metric that eventually matters most is cost per outcome:

• For a support product: cost per resolved case
• For a sales assistant: cost per qualified opportunity
• For a manufacturing copilot: cost per successful intervention
• For an engineering agent: cost per successfully completed task
• For a knowledge assistant: cost per useful answer

The objective isn’t to minimise AI spend. It’s to maximise business value per unit of AI spend. That’s the shift from cost management to FinOps.

The tools are catching up. Provider-native cost dashboards from OpenAI, Anthropic, and Google are getting better. Third-party layers — LangSmith, Langfuse, Helicone, Portkey, Kong AI Gateway — offer per-request tracing that includes cost attribution. Enterprise observability platforms like Datadog and Honeycomb have added LLM cost views. The infrastructure exists.

What doesn’t yet exist is the discipline of using it. Most AI teams still discover their cost picture the way cloud engineers did in 2014 — from the bill, in aggregate, monthly, when it’s already too late to change the decisions that drove it. The teams that will be governed well two years from now are the ones treating cost as a first-class observability signal today, alongside latency and quality.

Which sets up the second pillar. Because visibility only matters if you use it to make different decisions.

Optimise — reducing waste while preserving quality

The second FinOps pillar was about matching spend to value. Rightsizing instances. Killing zombie resources. Not spending less for its own sake — spending less where the extra spend wasn’t buying anything.

AI FinOps has to do the same. But the levers are different, and one of them didn’t exist eighteen months ago.

Some of it is familiar in shape. Prompt caching where the provider supports it. Trimming context that got pulled in but didn’t earn its space. Compressing conversation history rather than truncating it. Deduplicating retrieved documents before they hit the context window. All of these save real money at scale without lowering quality.

What’s genuinely new is the routing layer.

Nobody serious ships a single model anymore. A production AI system in 2026 is a portfolio — fast models for high-volume simple tasks, balanced models for the middle, reasoning models for hard problems, vision models when the query has an image, on-device models when latency or privacy matter. The routing layer decides which model handles which query. Get the routing right and you get most of the quality for a fraction of the cost. Get it wrong and you either burn cash on queries that didn’t need the heavy tier, or you ship a bad experience because you routed a hard query to a model that couldn’t handle it.

This is where the sharpest new cost category in AI FinOps lives. It needs a name.

The Reasoning Tax

Call it the Reasoning Tax — the premium you pay to send a query through a reasoning model instead of a fast one. It’s real, it’s large, and it’s often paid without anyone deciding to pay it.

A reasoning model doesn’t just produce an answer. It produces a chain of thought — sometimes thousands of tokens of internal reasoning — before it produces anything the user sees. Those reasoning tokens cost money. Often more per token than the final output. And they take time. A reasoning query can be ten to fifty times more expensive than the same query routed to a fast model, and take fifteen seconds instead of half a second.

For hard problems, the tax is worth paying. A reasoning model getting a complex analytical question right is often worth a hundred fast-model attempts. But most queries in most products aren’t hard problems. They’re classifications, summaries, formats, small transformations. Paying the Reasoning Tax on those is pure waste.

The problem is that the Reasoning Tax gets paid by default in a lot of AI products right now. Teams pick a reasoning model as their primary, use it for everything, and only discover the cost impact when the bill grows faster than the user base. Or worse, they route everything through the smartest available model on the assumption that better is better — and pay the tax on every query, whether it earned the compute or not.

The AI FinOps question is therefore not “what’s the cheapest model?” It’s “how much intelligence does this task deserve?”

That’s a much better optimisation question. A mature system might look like:

• Simple task → small/fast model
• Moderate task → balanced model
• Complex task → reasoning model
• Exceptional task → high-compute reasoning + human escalation

The routing system becomes an economic control plane. Which makes model routing more than an architecture pattern. It becomes a FinOps capability.

Two smaller optimisation levers are worth naming alongside routing.

SLM offload. Small language models — Phi, Gemma, Llama 3.2 small, Apple’s on-device foundation models — can handle a surprising share of production workload for a fraction of the cost, often locally on the user’s device. The wrong question is “is this SLM as good as the frontier model?” The right question is “is this model good enough for the classification, extraction, or summarisation task we’re paying frontier prices for right now?” For a lot of tasks, the answer is yes.

Context discipline. Every token in the context window costs money on every request. Injecting more context isn’t free, and it doesn’t always improve quality — beyond a certain point, longer context actually degrades attention and hurts output. The instinct to stuff everything the retriever returned into the prompt is expensive and often counterproductive. Good context engineering is also good cost engineering.

The pattern across all these levers is the same. Cost optimisation in AI isn’t a technical exercise the way it was in cloud. It’s a product exercise — because every optimisation choice is also a capability choice. Route to a cheaper model, and you’re accepting a different quality profile. Compress context, and you’re accepting some loss of nuance. These are product decisions with product consequences.

Which sets up the third pillar. Because if cost is a product decision, cost has to be governed as a product surface.

Operate — cost as a first-class product decision

The third FinOps pillar was about making cost governance a shared operational responsibility. Not something finance owned. Not something engineering owned. Something the whole team ran together, with shared visibility, shared budgets, shared accountability.

This is the pillar where AI FinOps looks most different from what most AI teams do today. Because most AI teams still treat cost as something you discover after the feature ships. AI FinOps treats it as something you design into the feature before it ships.

The baseline discipline needs a name.

The Token Budget

Every feature that touches a language model needs a Token Budget — an explicit ceiling on how much intelligence it can consume per request, per user session, per unit of business value delivered.

The Token Budget is the equivalent of the cloud budget in FinOps. Not a wish. Not a target. A constraint. Something you design against from day one, the way a good engineer designs against a latency budget or a memory budget.

Setting a Token Budget forces the right conversations early. How much context does this feature actually need? What happens when the budget is close to being exceeded — do we truncate, summarise, refuse, or route to a cheaper model? Who has authority to raise the budget when the product evolves? What’s the acceptable unit cost of an interaction with this feature, and how does that relate to what a user is paying?

Teams without Token Budgets discover their unit economics from the invoice. Teams with them design their unit economics into the product. That’s the whole difference.

Token Budgets aren’t only about cost. They’re also about discipline. A feature with a well-defined Token Budget is a feature where someone has thought about what context matters, what history is worth carrying, and what tradeoffs get made when the budget tightens. Those are all product decisions that improve the feature independent of cost. The budget just forces them to be made.

Three practices matter around Token Budgets:

Budgets per feature, not per team. Team-level budgets are useless for governance because they aggregate too many decisions. Feature-level budgets — this chatbot has a per-interaction budget of X tokens, this agent has a per-task budget of Y — are what create actionable accountability.

Budgets tied to unit economics, not to infrastructure cost. A budget of “5,000 tokens per interaction” is arbitrary. A budget of “3 cents per resolved support ticket” is meaningful. The best budgets are expressed in the business units the product actually operates in — cost per user, cost per session, cost per outcome — and translated to token limits underneath.

Budgets that can flex, with authority defined. A rigid budget breaks the product the moment a user has a legitimate edge case. A flexible budget with no authority becomes meaningless. The AI FinOps pattern is a budget with a defined ceiling, a defined process for exceeding it, and a defined owner who can authorise the exception. Same as any operational limit in a mature engineering org.

The Reasoning Tax and the Token Budget together give you the two shapes of everyday AI cost governance. The Tax tells you which queries deserve the expensive tier. The Budget tells you what any given query is allowed to spend before it has to stop or escalate. Together they let a PM say something they mostly can’t say today — “I know what this feature costs to run, and I know why.”

That’s the answer to the CFO question. And the CFO question is coming.

What’s genuinely new — the four differences from cloud

The parallel to cloud FinOps is real. But the parallel is not perfect, and the places it breaks down are the places AI FinOps has to invent something new.

Four things about LLM economics are structurally harder than cloud economics ever was.

One. Cost is coupled to quality. A cheaper EC2 instance is still an EC2 instance. It runs the same code, produces the same output, costs less. Cloud cost optimisation was mostly a technical exercise. LLM cost optimisation isn’t like that. A cheaper model is a different model with a different capability profile. Route a query to a smaller model and you don’t just save money — you get a different answer, sometimes worse, sometimes indistinguishable, occasionally better. Cost optimisation in AI is a product exercise, not an engineering exercise, because every cost decision is also a capability decision. This is why PMs have to be in the room. Cloud FinOps could largely be run by engineers with finance oversight. AI FinOps can’t.

Two. The economic unit is fuzzy. Cloud has clean units — vCPU-hours, GB-months, requests. Token economics is messier. A “token” varies by model. Reasoning tokens are priced differently from output tokens. Input tokens are cheaper than generation but you pay for them repeatedly across a conversation. Vision, audio, and multimodal inputs are priced on entirely different structures. Providers change their pricing structures every few months. Which means the economic unit that matters to the business isn’t the token — it’s the outcome. Cost per user, cost per session, cost per successful task, cost per successful agent trajectory. The token is only the meter. The outcome is the unit.

Three. Cost is non-deterministic. The same input to the same model doesn’t produce the same output length twice. A reasoning model might spend 500 reasoning tokens on one attempt and 3,000 on the next. An agent might retry a failed tool call once, or five times, depending on how the model interprets the error. The cost of any given interaction has a probability distribution, not a fixed value. Cloud costs were deterministic in ways this isn’t. Which means the FinOps practices of forecasting, alerting, and anomaly detection all have to work in probabilistic terms rather than absolute ones. The goal isn’t to prevent every expensive request — it’s to distinguish legitimate expensive behaviour from pathological expensive behaviour.

Four. Cost is embedded in the behaviour of the system. A verbose system prompt costs money on every request. A poorly designed retrieval pipeline injects thousands of unnecessary tokens. Carrying full conversation history increases cost every turn. An agent that retries a failed tool call five times is creating cost. A router that sends simple tasks to a reasoning model is creating cost. Cloud never had this problem. Nobody was writing infrastructure configuration files where a sloppy sentence added 15% to the bill. In LLMs, prompts are code — and unlike code, they’re written by PMs, designers, and sometimes end users as much as by developers. Which means AI FinOps extends into a domain FinOps never touched. Prompt discipline. Context assembly discipline. The writing you do inside the model’s context window is a cost surface. This is where AI FinOps stops looking like FinOps and starts looking like something new.

These four differences don’t invalidate the FinOps analogy. They extend it. AI FinOps inherits the shape of cloud FinOps, then has to add machinery cloud FinOps never needed.

The provider layer problem

There’s one more thing that’s structurally worse in AI than it was in cloud, and it deserves to be named. Because it’s the thing enterprises will discover the hard way, probably in 2027.

The provider layer in AI is more powerful than the cloud provider layer ever was.

When AWS raised prices, you could switch. Painful, expensive, but possible. Workloads were portable in principle. Kubernetes and containers made them more portable in practice. Multi-cloud strategies existed. Most enterprises didn’t execute them well, but the option was real.

When OpenAI, Anthropic, or Google changes model behaviour, pricing, availability, or terms, downstream products absorb it. Model portability is real but weak. You can switch providers, but the model you switch to behaves differently — different quality profile, different failure modes, different prompt sensitivities, different tool-calling behaviour. Your prompts, your evals, your product experience — all of it was tuned against a specific model. Switching means re-tuning.

So the real cost of a provider isn’t just the API price. It’s the API price plus the switching cost plus the operational risk plus the quality migration cost.

This has practical consequences for cost governance. It means single-provider lock-in has real economic weight — the provider knows you can’t easily leave, and they’ll price accordingly over time. It means multi-provider architectures are worth investing in even when they seem redundant. It means the routing layer we talked about earlier isn’t just an optimisation layer — it’s also a resilience layer against provider decisions you can’t control.

Mature AI FinOps will treat provider risk as a cost category in its own right. Not just “how much are we spending” but “how exposed are we to a single provider changing terms.” Most teams aren’t thinking about this yet. The teams that will be governed well in three years are.

Where AI FinOps has to go — from per-request to per-trajectory

The last frontier concept is the one that ties AI FinOps to where AI products are actually heading.

Everything I’ve described so far — the pillars, the Reasoning Tax, the Token Budget — operates at the level of the individual request. That’s where cloud FinOps operated too, at least in its early years. The unit of cost was the request, the query, the API call.

AI is about to blow past that unit. Because agents don’t do individual requests. They do trajectories.

Cost Trajectories

An agent doesn’t answer a question in one shot. It plans, calls a tool, observes the result, decides what to do next, calls another tool, retries when something fails, checks its own work, produces an output. A single user-facing task is a sequence — sometimes ten steps, sometimes fifty, sometimes more. Each step has a cost. And the shape of how those costs accumulate matters as much as the total.

Two agents can complete the same task at the same total cost while behaving completely differently.

Agent A: 5 steps → $0.40 → success. Agent B: 17 steps → 3 retries → $0.42 → success.

The total cost is almost identical. The economics are not.

Agent B has a behavioural problem. It may become dramatically more expensive when the task gets harder. It may spiral when a tool fails. It may have a retry loop. It may be using a reasoning model unnecessarily. It may be generating far more context than necessary. Looking only at total cost hides all of this. Trajectory analysis exposes it.

Call this the Cost Trajectory — the shape of cost accumulation across an agent run, not just its total.

Cost Trajectory analysis is where AI FinOps has to go, and it’s where almost no teams are today. The reason is straightforward — most cost observability tools treat each request as an atomic unit. Agent runs are multi-request events with internal structure. Understanding whether an agent is well-behaved economically requires looking at the trajectory, not just the sum.

The questions Cost Trajectory analysis lets you ask:

• Does this agent’s cost per task grow linearly with task complexity, or does it grow explosively?
• When a tool call fails, does the agent recover efficiently or spiral into expensive retries?
• Are there patterns of tool use that consistently produce cheap successful trajectories vs. expensive failed ones?
• Which trajectories generate the highest cost per unit of business value delivered?
• Which trajectories should trigger human handoff on cost grounds alone?

None of these can be answered from per-request cost data. All of them can be answered from trajectory data. The observability tools that support this properly are still emerging — LangSmith, Langfuse, Braintrust, and others are building toward it. The teams that will govern agentic products well are the ones treating cost as a trajectory-shaped signal now, not a request-shaped one.

Cost Trajectories are where AI FinOps stops being a cloud FinOps extension and starts being its own discipline. Because agents are unlike anything cloud FinOps had to govern. The unit of cost is no longer the request. It’s the behaviour. The system is making financial decisions while it’s running. That’s a fundamentally new FinOps problem.

What mature AI FinOps looks like

If AI FinOps follows the cloud FinOps arc — which I think it will, compressed into a shorter timeframe — here’s the shape it takes.

The maturity curve I’d expect:

• Measure. What models are we using? How many tokens? How much are we spending?
• Attribute. Which product? Which feature? Which customer? Which task? Which trajectory?
• Evaluate. What quality are we getting? What latency? What cost? What business outcome?
• Optimise. Can we use a smaller model? Less context? Fewer retries? Better routing? Caching?
• Govern. What’s the cost envelope? Who owns it? What happens when we exceed it? What provider risk are we carrying?
• Automate. The AI system optimises its own economics. The router chooses the appropriate model. The system controls context. The agent detects inefficient trajectories. The platform identifies abnormal cost behaviour. The FinOps layer stops merely reporting what happened. It starts influencing what happens.

Most teams are at stage 1 or 2 today. Serious teams will be at stage 4 or 5 within eighteen months. Stage 6 is the frontier.

The operating model that emerges isn’t a separate department called “AI FinOps.” It’s a set of shared questions asked across functions:

• Finance asks: how much are we spending, where is it going, what’s our forecast, what’s our provider exposure?
• Engineering asks: why is it costing this much, where is the waste, how do we optimise the architecture?
• Product asks: what does this feature cost per customer, is the quality worth the cost, what’s the cost-to-value ratio?
• AI teams ask: which model should handle this task, how much reasoning does it need, how much context, how many agent steps?
• Leadership asks: what business outcome are we buying with this intelligence?

That’s the real AI FinOps operating model. Not finance versus engineering. Finance, product, engineering, and AI working from the same economic model.

Cost governance becomes a competitive advantage. The teams that ship AI products with strong unit economics will out-compete teams that ship equivalent products at three times the cost, because they can price aggressively, invest in growth, and survive the inevitable pricing pressure. This is the same dynamic that played out in cloud — enterprises that built strong FinOps practices ended up with meaningfully better margins than the ones that didn’t. It’ll happen again.

Regulatory pressure will add a compliance layer. The EU AI Act, ISO 42001, and various sector-specific frameworks are going to require cost and resource disclosure for AI systems in regulated environments. Which means AI FinOps won’t just be a business discipline — it’ll be a compliance discipline in some contexts. Financial services, healthcare, industrial safety-critical applications especially. Enterprises will need to document not just what their AI does, but what it costs to do it, with attribution to specific use cases.

The category will feel obvious in 2028 in a way it doesn’t in 2026. That’s how it worked with FinOps. In 2015 it was a niche practice adopted by a handful of forward-looking enterprises. By 2020 it was table stakes at any serious cloud-native organisation. AI FinOps will follow the same curve, faster.

The three concepts to watch

If I had to reduce the whole discipline to three concepts, they would be these.

The Reasoning Tax. How much additional intelligence are we buying, and does the task justify it?

The Token Budget. How much are we willing to spend to achieve the desired outcome?

The Cost Trajectory. How does an AI system consume intelligence as it works toward that outcome?

Together they describe something that traditional cloud economics never had to deal with — a system that is making decisions about how much intelligence to consume while it’s operating.

What actually matters

I’ve spent years looking at cloud bills and then moved into building AI products. The similarity between the two worlds is striking. In both cases, technology moved faster than financial governance. In both cases, engineers and product teams became responsible for decisions with economic consequences. In both cases, provider bills were easier to generate than to explain. And in both cases, the answer wasn’t to stop consumption. It was to build a discipline around it.

But AI takes the problem one step further.

Cloud FinOps taught us to govern consumption. AI FinOps will have to govern intelligence consumption. And the ultimate metric won’t be how many tokens we used. It will be how much business value we created per unit of intelligence.

That’s the shift.

The teams that see it early will design AI products differently. They’ll think about cost during product discovery, not after launch. They’ll evaluate models on quality and economics. They’ll design routing around task complexity. They’ll budget agent trajectories. They’ll treat context as a cost surface. They’ll measure cost per outcome. And they’ll build systems that know when additional intelligence is worth paying for — and when it isn’t.

That’s what the next generation of FinOps looks like.

Ten years ago, cloud created FinOps. LLMs are about to create AI FinOps. The teams that see it coming and build for it will be the ones that get to keep building.

The rest will spend the next five years explaining their bills.

If any of this resonates, I write about industrial AI, agent design, and the economics of building AI products on LinkedIn and here on Medium. Come find me.