Key Insight Teams routinely default to the most capable, and most expensive, AI model for most tasks, not because the task demands it, but because it feels safe. FinOps spent years correcting the same behavior in compute, helped by the fact that engineers already knew how to size a server. Model selection carries no such inheritance and no signal as legible as a utilization percentage. Tokenomics is the discipline redesigning AI economics across that chain, from energy and silicon to pricing and margin. FinOps makes the cost visible and drives accountability. Both are needed, and neither is far enough along.
Practitioners who have worked in cloud cost optimization will recognize this pattern immediately. A developer needs a compute instance, picks one that feels safely oversized, provisions it, and moves on. Compute utilization settles and no flag catches it because the link between ownership and accountability was severed at provisioning. It can take years before rightsizing conversations happen at scale.
AI model selection is tracing the same path. Teams building chatbots, coding assistants, document summarization pipelines, and agent workflows that default to the most capable frontier model available, not because the task requires it, but because nobody has told them otherwise. The cost accumulates quietly across hundreds of API calls, buried in billing data most teams are not yet equipped to interrogate.
The issue is not carelessness. It is that the organizational conditions that eventually enabled compute rightsizing, visibility, accountability, and ownership, do not yet exist for model selection.
With compute, over-provisioning made a kind of sense: more CPU meant more headroom, and an undersized instance causing an outage felt riskier than the slow bleed of idle capacity. FinOps closed that gap by making utilization visible, establishing rightsizing by engineering as routine practice, and giving teams a shared language for trade-offs.
Model selection has its own version of this trade-off. Frontier models from OpenAI, Anthropic, and Google excel at complex reasoning and ambiguous tasks, and they cost significantly more per token than smaller models that handle a surprising range of work at a fraction of the price. Across major providers, the cost gap between a frontier model and a capable smaller model on the same simple task can vary exponentially and is not a rounding error at high volume.
The real trade-off is price relative to the task’s actual complexity. A simple summarization or a yes-or-no routing decision rarely needs frontier-model reasoning and associated cost. Without clear guidance though, teams default to the model they trust most, which is almost always the most capable one available. Over-modeling is the new over-provisioning: the waste is real, but invisible without deliberate measurement.
Compute utilization is an unambiguous signal. CPU running at 8 percent tells you something clear, and the path from observation to action is well established. Model selection has no equivalent metric yet. Average prompt size per API call is a starting point, but it does not indicate whether the task’s complexity actually warranted the model that handled it. Few organizations today have a standard answer to the question: what KPI tells you a team is over-modeling?
Three additional layers of complexity separate this problem from the compute analogy:
This is where FinOps has the clearest role to play, and the most urgency. Compute rightsizing did not happen organically. It happened because FinOps practitioners established visibility, built accountability structures, and gave engineering teams both the data and the standing to optimize. The technical path to rightsizing was always available; what was missing was the organizational infrastructure to act on it.
The same gap exists today with AI model selection. Tools are emerging, model evaluation frameworks, LLM routing platforms, prompt-level observability, and LLM gateways, but adoption lags, and in most organizations, nobody has been explicitly tasked with the problem yet.
This is where FinOps can support teams and should not be making model selection decisions themselves, but because they can inform on the cost-quality trade-offs visible, making them actionable for others is exactly the FinOps charter. Practitioners are positioned to ask questions nobody else is asking:
Strategic model selection is a direct optimization lever on enterprise ROI. It balances predictive performance, infrastructure cost, and time-to-market, and it lets organizations avoid the financial drain of running oversized models where smaller, fine-tuned alternatives would do, while managing risk tied to latency, compliance, and downtime. Done well, it turns AI spend into sustainable unit economics informing a measurable line to bottom-line business metrics.
FinOps practitioners do not dictate which model a team uses, but it can frame the value question that makes model selection a leadership priority instead of an engineering afterthought: what is this model costing per unit of business outcome, and would a lighter one deliver the same result for less? That framing is what turns model selection from a technical preference into a governed ROI lever.
For leadership, the case is financial: unmanaged model choice compounds into a run-rate cost that grows invisibly across thousands of API calls, and a structured program converts that into a predictable, defensible line item tied to unit economics rather than an unexamined baseline that hardens over time.
For product personas, the case is speed and margin: matching model capability to actual task complexity shortens time-to-market by avoiding unnecessary over-engineering, and it protects the margin on AI-enabled features rather than letting inference cost erode them.
For engineering personas, the case is standing, not control: FinOps isn’t asking teams to justify every choice after the fact, it’s giving them a shared framework, cost per outcome, quality floors, routing guardrails, so they can make and defend cost-quality trade-offs proactively, the same way rightsizing gave cloud engineers language and data to own their own optimization.
Positioned this way, a Model Selection Program isn’t FinOps inserting itself into technical decisions; it’s FinOps supplying the visibility and vocabulary that lets leadership, product, and engineering all optimize toward the same goal: sustainable AI economics that scales with the business instead of against it.
Simply asking better questions is not enough but is the line between a FinOps task and moving into a Tokenomics task. Once you move into technical decision making it’s no longer a cost centric decision. FinOps is a catalyst for decision making, and a vetting process on the outcomes of technical decisions, but should acknowledge that the deeper technical assessment moves beyond FinOps alone. That decision brings in experts from multiple disciplines including Technical, Security, ITAM, Business Leaders.
Without a structured decision-making framework, organizations consistently fall back on the most secure and costly hardware stacks and model configurations. FinOps practitioners require a diverse assembly of experts to evaluate the complex trade-offs surrounding risk, quality, and infrastructure, as the true efficacy of any routing platform, gateway, or model depends entirely on the stakeholders defining what satisfies requirements and what good-enough looks like.
| FinOps Competencies | Technical Competencies |
|---|---|
|
|
FinOps practitioners don’t need a perfect framework to begin closing the model selection gap, they need a sequence of practical moves that build visibility and credibility step by step. The following playbook lays out where to start, from classifying workloads to shifting-left selection logic into infrastructure, giving practitioners a concrete path.
Compute rightsizing took years to mature after cloud adoption scaled, and it had a decade of engineering instinct behind it when it did. Model selection has neither. The spend is too visible, the growth too fast, and the pressure to show AI ROI too immediate for organizations to extend the same runway. FinOps practitioners who make model choice visible now, (FinOps-Informed Model Selection Program) before it hardens into an unexamined baseline, are working with less inherited understanding and less time than the last generation had. That is the argument for starting before the framework is ready. The difference between model selection happening by default and by design is whether someone asks the questions above while the answers can still change anything.
