AI savings are not cloud savings

Picture a FinOps lead who has run cloud cost reviews for years and is now asked to look after AI spend as well. The first month goes well. The team moves a support agent to a cheaper model, turns on prompt caching, and reports the expected saving to finance. Three months later the AI bill is higher than before, the support team says the agent resolves fewer tickets, and nobody can say what either change saved.

Nobody in that story was careless. The team used methods that work for cloud, and they work there because a cloud saving is mostly arithmetic on a contract. With AI, the saving depends on what happens after the change, so you only know it once someone measures it.

Why cloud savings are predictable

Cloud cost work is mature, and the tools built for it do it well. Most of the savings come from a short list: commit to the capacity you run steadily, size each server to its load, and switch off what nobody uses. Most companies buy from one, two or three clouds, so the list does not grow much as the spend grows.

You also know the saving early. A commitment's discount is written into the contract, so it is known on the day you sign, and a smaller server runs the same application, so the work it does stays the same.

My personal observation from eleven years at AWS is that this is why cloud reviews became routine. There were only a few levers, and you could work out the result of each one before you made the change.

Cloud savings: AWS, Microsoft Azure, Google Cloud

AI savings: Anthropic, OpenAI, Amazon Bedrock, Cursor, GitHub Copilot

• LeversA few: commit, resize, switch off65 levers in 10 heads
• VendorsOne to three cloudsModel providers, clouds, coding seats, gateways
• What a change movesMostly the priceCost, quality and usage, together
• When the saving is knownWhen you approve itAfter the change, on the bill

An AI saving counts once the bill shows it, on the same work.

AI savings come from many levers

With AI there are far more ways to save, and they sit with many vendors: model providers, cloud AI platforms, coding seats, gateways, and agents inside other software. We group the levers under ten heads, the same ones the product uses.

Some of the levers under each head will be new to a team that has worked mostly on cloud:

• Model choice. A smaller model for simple work, a newer model that costs less, the same model from a cheaper provider, and a global endpoint where the law allows it.
• Prompt and context. Shorter prompts, conversations that stop sending their whole history on every turn, and answers kept to the length people need.
• Caching. The stable part of a prompt read from a cache, and a cache that is written but never read.
• How calls run. Retries and failed runs, the batch price for work that can wait, and a speed premium paid where nobody needs the speed.
• Seats and licenses. Unused seats, light users on a higher plan, and the same people on two tools that do one job.
• Buying. Credits used before they lapse, reserved capacity left idle, and list price paid at a volume large enough to negotiate.
• Limits. A budget over every dollar, a limit per person and per key, and a check for runaway agents and leaked keys.
• Value. Cost per successful outcome, spend nobody owns, and agents whose results are worth less than they cost.
• Infrastructure. Hosted models billed while idle, fine-tuned models nobody calls, and the tracing bill.
• Data and retrieval. A vector store paid for while idle, documents embedded again when they have not changed, and fewer, better chunks in each prompt.

Each vendor also shows these levers in its own way. Caching is one field on one bill and a different usage type on the next, and a seat plan has a different name at each coding tool, so you go through the list again for every vendor you pay.

One change moves cost, quality and usage

The FinOps Foundation's working group on AI describes this in its March 2026 paper on how optimization changes AI forecasts. The paper calls it "change one thing, changes everything", and it warns that small changes to an AI system can have effects far from where they were made.

You can see it in the most common levers:

• A cheaper model costs less per token, but if it resolves fewer tickets or needs more retries, each resolved ticket can cost more while the token bill goes down.
• Prompt caching reads the repeated part of a prompt at a lower price, but writing to the cache costs more than a normal input token, so a cache that is written often and read rarely can cost more than no cache.
• A shorter prompt sends fewer tokens. If it leaves out context the model needed, the answers get worse and people ask again.
• A lower price usually brings more use, and part of the saving turns into new usage. That is often a good thing, as long as someone checks that the new usage is worth what it costs.

The estimate you make when you approve a change is still a fair place to start. It cannot tell you what the change did, though, and the bill can.

A cloud saving is known when you approve it. An AI saving is known once you measure it.

Count a saving once it is measured

We say realized, not recommended. When you approve a change, write down the saving you expect, and then measure what the change did:

1. 1Record the baseline for one workload: its cost from the bill, and its successful outcomes, such as resolved tickets or merged pull requests.
2. 2Make one change at a time, so its effect does not mix with another one.
3. 3Measure the same workload over the same number of days, and compare the cost per successful outcome rather than the total, because volume moves on its own.
4. 4If the change is taken back, stop counting the saving, and keep the measurement as history.

After a few months, this record shows which kinds of change pay back in your company, and which only looked good on the day you approved them.

Building it yourself

Many teams start by building their own view of AI spend, and it is a reasonable start. Pulling usage from a few vendors into a chart does not take long, and it answers the first question: how much did we spend? Most of the time goes into keeping that chart right:

• The price map. Vendors change prices and add options often. Every model at every vendor needs its current price, including the cache, batch and speed prices, or the totals drift away from the bill.
• The invoice match. Tokens times a list price leave out your discounts, credits and private pricing, and finance will trust the total only when it matches each invoice.
• Owners across vendors. Each vendor has its own way to mark a team: a workspace, a project, an application inference profile, a seat. Someone has to map each one to a team and keep the map current as teams change.
• The record of what each change saved. The expected saving, the measured one, and the changes taken back, kept month after month so the next review starts from it.

None of these is hard to do once. Doing all four for every vendor, every month, is what slowly takes an engineer away from other work.

Keep your cloud cost platform for cloud

If you already use a cloud cost platform, keep it. It is built for commitments, rightsizing and idle resources across your cloud accounts, and it does that work well. Beside it, AI needs a different record: one total across every AI vendor and seat, an owner for each dollar, the outcome the spend produced, and each saving measured after the change.

That record is what Valistry keeps. It reads each vendor's usage and bills with read-only access, never prompts or answers, and matches the total to each bill. When you approve a change, it records the saving you expect, and afterward it measures the same workload against the same baseline. If you take a change back, its saving stops counting.

Cloud taught most of us to trust the estimate, because for cloud the estimate was usually right. With AI, the habit worth building is to check each saving on the bill, and to keep checking.