Cost Optimization and AI FinOps

In February 2026 the FinOps Foundation published its annual survey of the people whose job is managing technology spend. As The Economics of AI noted, almost all of them now manage AI spend: 98 percent of the practitioners who answered, a share of FinOps teams rather than of all organizations. The same report names the hardest part of that job, and it is not cutting AI costs. It is seeing them. Visibility into AI costs was the top challenge practitioners cited, ahead of allocating those costs to business units and working out what the spending returns. One practitioner summed up the state of the art: nobody can yet say whether their AI is providing value¹.

That is the contradiction this chapter resolves. Organizations are managing a cost they cannot yet see, assign or value. A large number on an invoice is not a management fact until someone can say who spent it, on what, whether it was expected and what it bought. The discipline that turns the number into those answers is called FinOps, and AI is now its top priority².

The core idea

FinOps grew up in cloud computing, where any engineer with access could start spending in minutes and the bill arrived a month later. Its practitioners found that the answer was not a tighter purchasing process. It was a continuous loop in which the people who create the cost can see it, own it and change it. The FinOps Foundation describes that loop as three phases, Inform, Optimize and Operate, which practitioners cycle through again and again rather than complete once³.

Two of the Foundation’s principles carry most of the weight for executives. The first is that business value drives technology decisions, which means trading cost against quality and speed deliberately rather than minimizing any one of them. The second is that everyone takes ownership of their technology usage: accountability for cost is pushed out to the teams that design and run the systems, not held only by finance⁴. Put together, they define the goal. AI FinOps does not aim for the smallest AI bill. It aims for the most value per unit of spend, which sometimes means spending more on the systems that earn it and cutting hard on the ones that do not.

Why AI spend needs its own discipline

Traditional cloud FinOps watches servers, storage and networks, most of which are provisioned in advance and change slowly. AI spend behaves differently, and the FinOps Foundation’s guidance for AI lists the reasons⁵.

The Foundation notes that a low barrier to entry turns people in non-technical roles into operators of AI systems, and that allocation is harder because many consumers share the same model, and forecasts need revising more often because early usage is hard to predict⁵. Agentic systems add a multiplier of their own. One model provider measured, in its own systems, that its agents used about four times the tokens of an ordinary chat, and its multi-agent systems about fifteen times⁶. The trade press also reported, in June 2026, a Gartner prediction that at least half of generative AI projects will overrun their budgets through 2028; the report is not public, so treat it as a reported forecast⁷. The Economics of AI explained why metered cost rises with use; this chapter is about running that meter.

Inform: see it, then give it an owner

The first pass of the loop answers two questions: what are we spending, and who or what is consuming it? Visibility starts where the spend is created. If every request to a model passes through a shared gateway, each one can carry a label for the product, team, workflow and environment that sent it. That single habit makes the rest of FinOps possible. Separating experimental spend from production spend matters here, because the two are managed differently, as Experimentation vs Production Economics argued.

Allocation turns visibility into accountability. A cost that belongs to everyone belongs to no one. Shared costs, such as the gateway itself or a central evaluation team, still need a rule for how they reach each system’s numbers, and Understanding AI Total Cost of Ownership set out the options, including deliberately holding some centrally⁸. The practical choice for most leaders is between two ways of showing teams their share⁹.

Showback is usually the right start, because charging teams for numbers they do not yet trust creates arguments about the method rather than better decisions. Chargeback works once the attribution is stable and the team being charged can actually change its consumption. Either way, the spend should be reported per unit of business work, the unit that AI Unit Economics and Economics at Scale taught, so that rising spend from rising volume can be told apart from rising cost per unit.

Forecasting belongs in this phase too. A historical run rate is a poor guide while adoption is still growing; build the forecast from drivers, such as users, requests per user and the mix of models, with low, base and high cases⁵.

Operate: guardrails in proportion

Visibility tells you what happened. Guardrails decide what is allowed to happen next. They range from a warning to a hard stop, and a common mistake is to assume a warning is a stop.

A budget alert is not a limit. In 2020 a startup’s cloud budget of 7 sent alerts but capped nothing, and a recursion bug ran the bill to about 72,000 overnight¹⁰. The case predates generative AI, but the mechanism is the same one that makes an agent dangerous: a loop that calls a metered service, faster than any person reads an alert.

Two rules follow. An alert needs a named owner who is expected to act on it; detection without an owner is not control. And hard limits belong where amplification is possible, which for AI means at the level of the workflow: a maximum number of steps or tokens per agent task, a daily ceiling per user or per application. Elsewhere, soft controls are usually enough, and they keep teams learning. A guardrail that requires approval for every experiment protects the budget by stopping the work the budget was meant to fund. Experiment budgets should be sized by the value of the decision they inform, as Experimentation vs Production Economics showed, and then left alone within their limits.

Optimize: start at the top of the stack

Many organizations reach for the price list first. It is rarely the best place to start. The practitioners’ standard text on cloud cost frames optimization as two separate levers, using less and paying less for what you use⁹, and for AI the “using less” lever has several layers. The rule is to work from the top down, because each layer decides how much work reaches the layers below it.

At the top is work that should not happen at all: a step the process no longer needs, a summary nobody reads, a check that repeats another check. Next comes the shape of the workflow: fewer calls per task and shorter context, since every unnecessary page sent to a model is paid for on every request. Then comes the choice of model. As The Evolution of AI Models described, a portfolio can send easy work to a small model and only hard work to a large one. The cost case is strong in research settings: a cascade that tried inexpensive models first matched the best single model on its test sets at up to 98 percent lower cost¹¹, and trained routers cut costs by more than half in some settings without lowering answer quality¹². These are laboratory results, not promises for your workflow. After routing come caching and batching. One major provider charges a tenth of its standard input price when a request reuses cached input¹³, and Model, Compute and Infrastructure Costs showed the discount for work that can wait. Only at the bottom comes the rate: negotiated prices and commitments, which the FinOps Foundation assigns to a central team because they depend on the whole organization’s volume⁴.

The order matters for a reason beyond the size of each saving. Suppose a team negotiates a 10 percent discount on a monthly run cost of 200,000 before anything else. On paper it saves 20,000. If it also committed to today’s volume to get the discount, it has locked in the very usage it is about to remove, the commitment trap that Model, Compute and Infrastructure Costs described. Done last, the same 10 percent applies to 80,000 and saves 8,000, but on a volume the organization actually needs. In the illustration, 200 minus 40, 30, 30 and 20 leaves 80, and the discount brings it to 72. The usage levers did most of the work.

Every one of these levers can also damage the result. A smaller model, a trimmed context or a cached answer can lower quality, and a cheaper call that fails more often can raise the cost of each successful outcome, as Model, Compute and Infrastructure Costs showed. So every optimization should ship with three things: a quality measure for the work it touches, a baseline taken before the change, and a way to roll it back. Report cost, quality and speed together. A saving that only appears in the cost column has not been proved.

A rhythm and an owner

Because usage, models, prices and workflows keep changing, an optimization made in March can be undone by June. The loop needs a rhythm, matched to how fast each kind of spend can move.

Who runs it? In the FinOps Foundation’s 2026 survey, 60 percent of practices combined a central enabling team with champions embedded in product and engineering teams, 21 percent used a hub-and-spoke model, and fewer than 10 percent were fully decentralized². For AI the pattern fits well: a central team owns the gateway, the tagging, the rates and the reporting, while the owner of each system owns its consumption and its savings backlog. That backlog is worth keeping explicitly, ranked by expected annual saving against the effort to deliver it, with quality and risk as constraints rather than afterthoughts. FinOps also works alongside governance. The governance rules of Module 07 decide which models and data may be used; FinOps adds how much, by whom, and with what limits. This is the rhythm for spend only; the organization’s wider operating rhythm is set in AI Change Management, KPIs and Operating Rhythm in Module 09.

Story: the budget that was gone by April

One of the most widely reported AI cost overruns of 2026 happened at a company that was doing what many boards were asking for: adopting AI quickly. The account below rests on press reports, chiefly by Bloomberg and The Information as summarized by other outlets; Uber has not published the figures. According to those reports, Uber encouraged its staff to use AI tools as much as they could and ranked internal usage on leaderboards¹⁴. Agentic coding tools, billed by consumption, became the main AI software its engineers used from December 2025¹⁵.

By April, four months into the year, the company had used up its AI budget for the whole of 2026. Its chief technology officer told The Information that “the budget I thought I would need is blown away already”¹⁵. The usage was real: the chief executive said in May that about 10 percent of the company’s code was being developed by AI agents. The value was harder to show. The chief operating officer said it was very hard to connect the extra AI usage to new features for customers, and that measurable productivity gains remained unclear¹⁵. In June the company capped spending at 1,500 a month per employee for each agentic coding tool, with a dashboard where every employee could see their own usage and a process for asking to exceed the limit¹⁴.

Read as a post-mortem, the reported record shows a loop run backwards. The first metric was consumption, and it was rewarded, so the organization optimized for spending. Visibility for the individual engineer, the dashboard, arrived with the cap, after the budget had gone. The control that followed was well designed in itself: per person, per tool, visible to the user and with an exception path, which is a proportionate guardrail rather than a freeze. What the reporting does not show, and what the operating chief said was missing, is a unit of value to set against the spend. Without one, the only available response to a blown budget is a cap, because nobody can say which usage to keep. The lesson for other leaders is not to slow adoption. It is to start the loop on the day adoption starts: showback per team, an owner for every alert, and a value measure next to the usage leaderboard.

What this means for leaders

AI FinOps asks executives for a change of question. Instead of asking whether AI spend is too high, ask whether each significant unit of it is visible, owned and tied to value, and what is being done to improve it. That reframes the familiar argument between a finance team that wants a cap and an engineering team that says a cap will block innovation. Both are answering before the facts are in. The leadership job is to get the facts quickly, then apply controls in proportion to the risk.

Check yourself

1. The goal of AI FinOps is the smallest possible AI bill.MythFact
2. A budget alert stops spending when the budget is reached.MythFact
3. Showback is usually a better starting point than chargeback.MythFact
4. Negotiating a lower rate is the first optimization lever to pull.MythFact
5. Every cost optimization should ship with a quality check and a way to roll it back.MythFact
6. Ranking teams by AI usage is a good way to manage AI value.MythFact

Reflection: follow one invoice line

What comes next

FinOps improves the economics of AI systems the organization already runs. The larger choices come earlier: whether to build a capability, buy it or combine the two, and how to judge that choice as an investment rather than a slogan. That is the subject of the next chapter, Build vs Buy Economics and Investment Decisions.