Build an AI cost strategy you can change

Cheap access today is a weak basis for a long-term AI commitment. This week's reporting gives leaders a reason to examine how much room they have to change models, suppliers and deployment choices.

In CIO Dive, Gartner analyst John-David Lovelock warns that today's subsidized token prices will not last indefinitely. Gartner forecasts global IT spending will rise 15% to $7.35 trillion in 2027. The same reporting describes rising memory prices affecting devices, storage, servers and networking. Owning infrastructure would still leave an organization exposed to those hardware costs. [s1]

A separate CIO Dive report, drawing on Splunk's survey of 2,050 IT operations and engineering professionals, says 60% reported unexpected AI billing spikes that put strain on operations. More than half said they could not control AI costs. These are survey findings, rather than a measured comparison of open and proprietary models. [s2]

Our view

The argument for open intelligence starts with having practical choices. Neither story establishes that running an open model costs less. Both make a useful starting point for asking whether an organization can understand its AI bill and change its approach when the economics change.

Measure the work, then compare the options

CIO Dive's reporting on billing spikes describes the need to track model calls and token use by workflow or team. It also discusses budgets, rate limits, smaller models for routine requests and consumption caps in supplier contracts. [s2]

Start by deciding which work deserves which model. Select a recurring task, define an acceptable result, and measure the cost of completing it. Include retries and human review in the comparison. A low price per token offers little guidance if one option needs more attempts to produce useful work.

An open-model option deserves a place in that evaluation. Compare it with the current service using the same workload and quality standard. Include infrastructure, operations, monitoring and staff time where they apply. The outcome may favor an API, a managed open model or an internally operated deployment. The evidence in this week's coverage does not settle that choice.

Make the ability to switch concrete

Find out how much effort a change of supplier would require. Before expanding a deployment, ask the team to demonstrate a second model on a small representative workload. Identify what must change in the application, what evaluation is needed and what the transition would cost.

That exercise makes ownership concrete. It turns the ability to switch into something the organization has tested. It also exposes the work still needed before an alternative is credible.

Be equally specific about the word “open.” Review the actual license, the permissions it grants and the operational responsibilities your team would take on. Treat those as due-diligence questions for the deployment under consideration.

This week's decision

The next step can be small: choose one important workflow, name its cost owner, set a spending boundary and compare the current approach with one viable alternative. Record both the result and the effort required to change.

The case for owning your intelligence becomes stronger when it is backed by that work. You can make an informed decision about cost and control without assuming that any one deployment model will always win.