In March this year, by one industry count, 114 of 483 tracked AI models changed price in a single month. Around the same time, a senior OpenAI executive described the industry's current pricing as, roughly, accidental, with bigger changes coming. That's the ground you're standing on when a client asks you to put a fixed number on two years of AI running costs.
Most consultants respond to this the way most humans respond to any moving target: pick a number that felt right recently, add a safety margin invented on the spot, and hope. Hope is not a pricing strategy. It's how you end up either eating a cost increase for a year or, almost as bad, quoting so defensively you lose the work to somebody reckless.
The fix isn't a better crystal ball. It's separating the three different numbers that get mangled together in AI pricing conversations, and handling each one honestly.
The three numbers
Your fee is what the client pays for your expertise and delivery. The build estimate is the effort to make the thing. The running cost is what the system costs to operate, and token consumption is the volatile part of it. The classic error is quoting all three as one figure, because that welds your margin to a vendor's pricing page. When the vendor reprices, your fixed quote silently absorbs it. You've become an unpaid insurance company for platform risk, with no premium and no exclusions.
So unweld them. Fee and build estimate, you control and can commit to. Running cost, you don't control and shouldn't pretend to.
How to handle the number you don't control
Quote running costs as a model, not a figure. Give the client the calculation: expected volume, tokens per interaction, current price per million tokens, with a low, mid and high scenario. Then say the honest sentence out loud: "these are today's prices, they have been changing roughly monthly across the industry, and here's how the model updates when they do." A client shown a sensitivity table trusts you more, not less. The consultant who says "it'll cost about four grand a month" and the consultant who shows what happens at half and double today's token price are not competing on the same tier.
Pass token costs through where you can. The cleanest structure is the client holding the provider relationship and API keys directly, with consumption billed to them at cost. You advise on optimisation; you don't broker the tokens. If you must resell usage inside a managed service, index it: the contract names today's provider rates as a baseline and adjusts your usage line when they move beyond a threshold, in either direction. Passing through decreases as well as increases is what makes the clause feel fair rather than sneaky, and prices have moved down as often as up this year.
And put a repricing trigger in the business case itself. Any ROI model you hand a CFO should state the token price assumptions on their own line and commit to a re run when they shift materially, say beyond 20 percent. A business case with dated assumptions and a review cadence is a living document. One without is a screenshot of a good mood.
How volatility changes the build too
Two scoping notes that pay for themselves.
Cheaper models change the answer. The five fastest growing models on the big routing platforms this year are all cheap or free, and capability at the budget end keeps improving. A pipeline that routes easy cases to a cheap model and hard cases to an expensive one can cut running costs dramatically. Scope in an optimisation pass a month or two after go live, priced as its own small engagement. By then you have real traffic data, and the savings usually dwarf the fee, which makes it the easiest upsell in your catalogue and the rare one that's unambiguously in the client's interest.
Estimate consumption from tests, not vibes. Token consumption per interaction is measurable during the build. Measure it, don't guess it. The gap between guessed and measured consumption is routinely a factor of three, and it's your credibility attached to the difference. The AI Project Estimation Calculator includes a token cost model with scale sensitivity built in precisely because we got tired of seeing this guessed.
What not to do
Don't fix a price on someone else's variable. Don't bury a silent 40 percent buffer in the quote instead of showing a sensitivity table, because sophisticated clients can smell padding and unsophisticated ones will benchmark you against a padder with worse maths. And don't treat a vendor price cut as a windfall to quietly pocket inside a managed service, because the client will eventually read the same pricing page you did, and that conversation costs more than the margin ever earned.
The theme, as ever on this site: the volatility is not your fault, but absorbing it silently is your choice, and a bad one. Name the moving parts, model them in the open, and charge properly for the judgement that turns a chaotic pricing page into a decision a CFO can sign. That judgement is the product. The AI Pricing Framework has the structures and the calculator, the AI Business Case Builder has the CFO ready model, and the Platform Ledger will tell you, daily, exactly how unstable the ground currently is. We measure it so you can bill for standing on it.