Your AI model strategy is a finance problem, not just a technology one
On August 7, a carefully built industry tracker published a countdown: Anthropic's Claude Sonnet 5 promotional pricing ends August 31, rising 50% in 24 days out. Translation: a workload costing $2,000 a month becomes $3,000 in September with no change in usage. Forecast it now.
That was correct and read from the vendor's own published price list.
On August 10, that is three days later, Anthropic cancelled the increase and made the lower price permanent. If you had started forecasting, you can bin that work. Your first instinct if you’re in Finance is probably to celebrate. But it raises a number of questions you should pay attention to.
The model cadence, quantified
One continuously maintained tracker now catalogues 225 major AI models from 11 companies since ChatGPT launched in 2022. Its data shows the monthly rate of significant releases has roughly quadrupled since 2023.
Whatever review cycle was appropriate in 2023 is now roughly four times too slow today.
One thing to note as well; several recent moves aren't new capabilities at all, they're new prices, new default settings, product retirements, and changed licence terms. The kind of change that never makes a headline but may impact your cost base.
The exposure is financial before it's technical
Most organizations treat AI model selection like choosing a database: evaluate, compare, decide, commit, review annually. That assumes the options change slowly enough for a year-old decision to stay roughly correct.
For AI models, this practice isn’t adequate anymore. The risk isn't just that a competitor ships something dazzling that you cannot benefit from because you are locked with vendor X. The risk very few people talk about is that you keep paying last year's price for this year's commodity.
Let me explain. Anthropic's Sonnet 5 launched at $2 per million input tokens and $10 per million of output, with the vendor describing its performance as close to Opus 4.8 on many tasks. Opus 4.8 costs $5 and $25. So you do the math, Sonnet 5 is roughly 40% to 60% cheaper for broadly comparable results across a large share of real work.
The August price reversal was published as an edit at the bottom of a blog post from the 30th of June. No press release. No account manager calling to say your costs had fallen. If your AI spend is material, that single line was worth more to you than most of the launches that made headlines. This is one of the many cross-over points in the world of AI: AI should never just be treated as an “IT thing”.
Make switching cheap
Aside from making sure you track vendor changes beyond the capability release (and that’s a job in itself depending on the array of vendor solutions you deployed), another theme emerges: building so that changing models is cheap and easy.
Instead of each application being wired directly to one vendor, applications call an internal service that decides which model handles each request. Changing models becomes a configuration change in one place rather than a development project across every system that touches AI.
It enables the pattern that saves the most money: matching model cost to task difficulty. Most business AI requests are not hard: sorting, extracting, summarising, routine drafting. A minority genuinely need the expensive tier. Sending everything to your most capable model because it's the one you evaluated is the single most common source of unnecessary AI spend.
Of course there’s a catch: cheap to switch means increased risk
Previously, swapping a model had to go through normal change control, got a ticket, a reviewer, a record. With a routing layer it's a configuration value. Configuration changes are notoriously under-governed precisely because they don't feel like changes.
So the same mechanism that makes switching cheap also makes it easy to switch without anyone noticing. Build the routing layer without testing is a governance liability.
Three controls have to travel with it.
Record which model served which request: without this you cannot answer "what produced this output?" months later, which is the question that actually gets asked during an incident, a complaint, or an audit. It is cheap to build at the routing layer and nearly impossible to reconstruct afterwards.
Approve models per use case, don't let the system choose freely. Each application gets a defined set of permitted models, and adding to that set is a governed decision. For high-risk uses like anything customer-facing, anything that moves money, anything touching regulated decisions, there should only be one fixed model. Automatic routing is for the low-risk bulk, which is where the cost savings sit anyway.
Re-test when you switch, scaled to risk. If you validated an AI capability on one model and switch to another six months later, you should assume re-testing is required. Model changes fail in ways that spot checks miss: output quality holds, but tone shifts, formatting drifts, or the new model interprets ambiguous instructions more literally than the one your instructions were tuned around. These surface in production, at volume, weeks later. Prioritise re-testing based on risk; a customer-facing system that takes actions gets full re-validation and a human sign-off. An internal summarizing tool gets an automated test run and a review of what changed.
One thing worth noting here; testing should never be a one-off exercise. It should be part on your overall monitoring. Model drift can be a real problem and in AI the approach should never be “we’ve tested before it went live 6 months ago”.
If you operate under EU AI Act high-risk obligations, financial services model-risk rules, or medical device software regimes, assume validation attaches to the system as deployed, model included and that a switch is a change requiring documented re-validation. Confirm the specifics with your compliance function rather than assuming otherwise.
What this doesn't mean
This is not an argument for chasing every release. The goal is optionality, not activity. Most releases won't matter for your business. An organization that switches constantly may replace one problem with a worse one.
And model choice isn't the whole system. Your data quality, how you retrieve information, and your testing discipline will impact more of your outcomes than which model you call.
So, what now? The practical version
Five questions for your team:
If we had to change our primary AI model next month, what would that take? If the answer is months, then switching model will probably cost more than what you’ll save.
How would we know if a new model were better for us? No repeatable test against your own data means you're deciding on vendor marketing.
Does the cost tier match the difficulty? The usual finding is that a large volume of easy requests are being handled by the most expensive model available.
Can we say which model produced any given output, six months on? If not, that gap will be found during an audit rather than before one.
When did we last check vendors' list prices against what we're paying? As August showed, changes in your favour aren't always announced in ways you'll notice.
The organizations that handle the next two years well won't be the ones with the most AI features, they'll be the ones that built so that being wrong is visible and cheap to fix.
*Verified against vendor announcements and primary release trackers as of August 13, 2026. Some of it will be out of date shortly which is, unavoidably, the argument.*