In 1910, automobile insurers tried to apply horse insurance actuarial tables to cars. The logic seemed reasonable. Both were transportation assets. Both could be damaged. Both created liability when they harmed someone else. Every company that used the horse insurance framework to price automobile risk went bankrupt.
Cars failed differently. They failed more expensively. They failed more unpredictably. The horse actuarial tables had been built on decades of claims data that reflected a completely different failure mode. The companies that survived automobile insurance were the ones that built new actuarial models from scratch, ones that accounted for speed, mechanical complexity, and the novel ways a car could hurt a person.
The enterprise AI cost management industry is making the same mistake right now, and it is doing it at scale. The organizations struggling with controlling AI spend are almost always the ones that started with cloud FinOps tools and tried to adapt them.
The Cloud FinOps Playbook Is the Horse Insurance Table
Cloud FinOps is a mature discipline. Reserved instances. Spot pricing. Rightsizing idle resources. Tagging taxonomies. Showback and chargeback to business units. These practices were built over 15 years of hyperscaler cost management and they work extremely well for what they were designed to do.
They were designed for compute resources that behave predictably. A VM has a defined cost per hour. A storage bucket has a defined cost per gigabyte. The resource runs until you stop it. The cost curve is linear and continuous. You can forecast it with reasonable accuracy because the inputs are stable.
AI spend does not behave this way. And every organization that bolts a cloud FinOps framework onto an AI spend problem finds this out the hard way, usually during a board presentation when the numbers do not match the model. Controlling AI spend requires a different starting point entirely.
Cloud Spend vs. AI Spend: A Direct Comparison
Before building a control framework, it helps to understand precisely where the two models diverge. The table below shows the structural differences that make cloud FinOps tools inadequate for controlling AI spend.
Every row in this table represents a place where the cloud FinOps playbook gives wrong answers. Understanding these divergences is the prerequisite for building a framework that actually works for controlling AI spend.
Why Token Costs Are Not Compute Costs
The first failure point of the cloud playbook is cost structure. Token costs are not billed per unit of time. They are billed per unit of work, where the unit of work varies dramatically based on inputs you do not always control.
A cloud VM costs the same whether it is processing a simple request or a complex one. A language model call does not. An 800-token prompt and a 12,000-token prompt are not eight percent different in cost. They are fifteen times different. And the size of that prompt is often determined by application logic, user behavior, or upstream data that the cost management framework never touches.
Rightsizing works for VMs because idle VMs waste money. There is no equivalent idle cost for AI. But there is an equivalent waste pattern: prompts that are longer than they need to be, context injected that is not being used, retry loops that fire on recoverable errors instead of implementing backoff. These are the waste patterns that matter for controlling AI spend, and none of the cloud FinOps tools are instrumented to find them.
Attribution Is Harder and the Stakes Are Different
Cloud FinOps solved attribution with tags. You tag every resource with a team, a project, a cost center, and the billing data flows accordingly. This works because cloud resources are persistent. A VM lives for days or weeks. You tag it once.
AI API calls are transient. A single user request might trigger dozens of model calls across different services, orchestrated by an agent, with no single system that has visibility into the full chain. Tagging an individual API call is technically possible but organizationally fragile. The call is made by a library, inside an agent, called by a service, triggered by an event. Which team owns that cost?
The attribution problem in AI spend is a workflow problem, not a tagging problem. Solving it requires instrumenting at the application layer, not the billing layer. That requires a fundamentally different approach than what cloud FinOps tooling provides. Organizations that try to solve it by adding more tags to their existing FinOps tool consistently fail because the architecture is wrong from the start.
Agents Break Every Assumption About Human-Triggered Spend
The third failure mode of the cloud playbook is the most consequential. Cloud cost management assumes that a human decision precedes every significant resource allocation. Someone provisions a VM. Someone schedules a job. The human decision is the control point.
AI agents operate without human approval per operation. They retry. They loop. They spawn subagents. A background document processing agent that encounters an API error might retry 50 times before hitting a limit, generating 50x the expected cost in minutes. A planning agent might expand its context window as it decomposes a complex task, multiplying costs with each step.
These behaviors are not bugs. They are how agents are designed to work. But they create cost spikes that no cloud FinOps framework was designed to catch, because cloud FinOps assumes spending is triggered by a person making a choice. Controlling AI spend from autonomous agents requires pre-authorized per-run budgets and real-time spend rate monitoring -- neither of which exists in any cloud FinOps tool.
What a Purpose-Built Framework for Controlling AI Spend Actually Requires
Building from scratch means starting from the actual failure modes of AI spend, not the failure modes of cloud compute.
Cost must be measured at the workflow level, not the API call level. A workflow has a defined purpose, expected inputs, and a cost profile that makes sense to a business owner. API call-level data is too granular to manage and too disconnected from business outcomes to be actionable.
Attribution must be instrumented in the application layer. This means the code that makes the model call must tag that call with workflow identity, team ownership, and context about what it is trying to accomplish. This cannot be retrofitted from the billing dashboard.
Agent spend must have pre-authorized budgets per run, not alerts that fire after the run completes. An agent that can spend without limit until a human reviews the invoice is not governed. It is watched after the fact.
Model selection must be treated as an economic decision, not just a technical one. The difference in cost between GPT-4o and GPT-4o-mini for the same task can be ten to one. Organizations need frameworks for making that tradeoff systematically, not leaving it to individual developer preference. This is one of the most impactful levers available for controlling AI spend without restricting what teams can build.
Frequently Asked Questions
Why doesn't cloud FinOps work for controlling AI spend?
Cloud FinOps was built for compute resources that are priced by time, attributed by persistent resource tags, and governed through human provisioning decisions. AI spend is priced by token count (which varies non-linearly with input size), attributed through transient API calls inside opaque agent workflows, and generated autonomously without human approval per operation. Every assumption in the cloud playbook is wrong for AI. Using it produces governance that is structurally blind to the actual failure modes.
What makes controlling AI spend harder than cloud?
Three things make AI spend structurally harder to control. First, cost non-linearity: a small change in prompt size or context can multiply cost by an order of magnitude in seconds, not days. Second, attribution depth: AI spend is often generated inside agents, libraries, and orchestration layers that are far removed from the team that owns the cost. Third, autonomous execution: agents spend without human approval per operation, so spend can accelerate to damaging levels before any human sees a dashboard.
How do token costs differ from compute costs?
Compute costs are proportional to time: a server running for two hours costs twice as much as one running for one hour, regardless of what it processes. Token costs are proportional to content: a prompt that is ten times longer costs approximately ten times more for input tokens, but the output cost depends on what the model generates. More importantly, token costs are determined by application logic and user behavior, not by resource configuration -- which means you cannot "right-size" your way to lower costs the way you can with VMs.
Can I use my existing FinOps tool to control AI spend?
Existing FinOps tools can provide vendor-level spend visibility and basic budget alerts. That is a starting point for awareness, not a control framework. They cannot do workflow-level attribution, cannot monitor agent spend rates in real time, cannot enforce per-run budgets, and cannot connect cost variance to outcome data. You can use them alongside purpose-built AI spend tooling, but you cannot use them as a substitute for it.
What new frameworks are emerging for controlling AI spend?
The emerging frameworks share three architectural features: workflow-level cost measurement (not API-call-level), application-layer attribution (not billing-layer tagging), and agent-specific controls (pre-authorized budgets, spend rate circuit breakers, post-run attribution reports). These frameworks treat model selection as an economic decision with documented tradeoffs and require that variance thresholds be calibrated to AI-specific cost behavior rather than adapted from cloud benchmarks.
Building the Right Foundation
The horse insurance companies that survived did not tweak the actuarial tables. They built new ones. That is the work in front of every enterprise finance team trying to govern AI spend today.
Oberhahn was built for this problem specifically: workflow-level cost attribution, agent spend controls, and model economics tooling that starts from how AI actually behaves rather than how cloud compute behaves. The organizations that invest in purpose-built frameworks for controlling AI spend now will be the ones with defensible governance stories when boards ask the inevitable questions about AI ROI and financial discipline.