Outbound editorial link: OpenAI list pricing (in “The three costs that never appear on the invoice”).
Illustration: a platform engineer consolidating four AI model providers through one operating layer.
The sprawl nobody budgeted for
Picture a 300-person software company. Two years ago it ran one AI pilot. Today it runs four models in production.
The support team uses OpenAI. The legal review tool runs on Anthropic. Marketing switched to Google because it handled long documents better. And one data engineer stood up an open-weights model on a rented GPU because it was cheaper for bulk classification.
Four providers. Four invoices. Four sets of API keys. Four rate limits that behave differently the moment traffic spikes.
Now ask the finance team a simple question. What did this company spend on AI last month, and which department spent it?
Nobody can answer. Not because finance is careless, but because the answer sits across four billing portals, two corporate cards, and one invoice that arrives as a PDF with no line items. This is not an unusual situation. It is the normal end state for any company that moved quickly on AI between 2024 and 2026.
Illustration: finance and engineering teams reconciling four separate AI-provider accounts in a bright operations workspace.
How the sprawl happened
It is tempting to call this a management failure. It is not. It is a problem of tempo.
New models ship every six to eight weeks. Each one is genuinely better at something. When a team has a job in front of it and a model that does that job well, the team picks the model. At the team level, that is the correct decision. Procurement cannot run a vendor review on a six-week cycle, so procurement does not get asked.
Three symptoms show up in almost every company that reaches this point.
Shadow IT. Teams sign up for API access on a company card and tell nobody. The spend is real. The contract is a click-through terms page that no lawyer has read.
Keys living in personal accounts. An engineer creates a key under their own login because it takes thirty seconds. Eight months later that engineer changes jobs. Either the key dies with them and something breaks in production, or the key stays live with no owner. Both outcomes are bad.
Spend that cannot be attributed. One invoice, one total, no breakdown by team or by product. Finance watches the number rise each quarter with no way to ask which workload caused it.
None of this is dramatic on its own. Together it means a company has built a dependency it cannot measure.
The three costs that never appear on the invoice
The provider bill is the visible cost. It is usually the smallest of the four numbers that matter. Here are the other three, and a rough way for a CFO to put a figure on each.
Cost one: engineering hours for every extra provider.
Each new provider brings its own SDK, its own authentication, its own error codes, and its own retry behaviour. Then it brings maintenance, because every provider ships breaking changes on its own schedule.
To estimate it: take the hours your team spent integrating the most recent provider, add a quarter of that figure per year for upkeep, and multiply by your loaded engineering cost. Most teams land between two and six weeks of engineering per provider in the first year.
Cost two: the loss of negotiating leverage.
The second cost is the one finance teams feel last and regret most. A team built entirely around one provider has no credible way to walk away, and it pays accordingly. Published work on how flagship model pricing actually compares regularly shows double digit differences between vendors on tasks of similar difficulty. If you cannot move a workload, you cannot use that difference. It shows up in someone else’s margin instead of yours.
To estimate it: take your annual spend with your largest single provider and assume 15 to 30 percent of it is sitting on the table. That is the range most buyers recover once they can credibly threaten to move. Published list pricing is the floor of that conversation, not the ceiling.
Cost three: no failover path.
If one provider has an incident and you have no route to a second model, their outage becomes your outage. Your customers do not care whose status page is red.
To estimate it: take the revenue or the internal productivity your AI feature supports per hour, then multiply by the longest provider outage you have recorded in the past twelve months. That number is your current exposure, and it is not insured.
A CFO can put a figure on all three. Most have never been asked to.
Illustration: three hidden costs of AI-provider sprawl—engineering overhead, weaker purchasing leverage, and limited failover.
What a consolidation layer actually does
Rather than negotiating separately with every vendor, a growing number of teams now place a single aggregation layer in front of all of them. Platforms such as DataLLM Lab expose hundreds of models from different providers behind one OpenAI-compatible endpoint, which turns “move this workload to a cheaper model” from a sprint into a configuration change.
Strip away the marketing and a consolidation layer does four things.
One endpoint. Your application calls a single address and names the model it wants. Adding a fifth provider stops being an engineering project and becomes a string in a config file. The integration cost from the previous section drops close to zero after the first setup.
Unified billing with per-team attribution. One invoice, but broken out by key, by team, or by product. This is the capability finance actually wants. It is also the one most companies discover they never had.
Cross-provider failover. When a provider degrades, traffic routes to a comparable model somewhere else. The feature stays up. The incident becomes a line in a log rather than a call from a customer.
Routing by cost and quality. Every request goes to the cheapest model that clears your quality bar for that task. A summarisation job does not need your most expensive model. A contract analysis might. Routing lets you make that choice per request instead of per vendor contract.
The order matters. Attribution is what gets the project funded, because it is the first thing a finance team can act on. Routing is where the savings actually appear.
It is worth being clear about what this layer does not do, because the category is being oversold in places. It does not make a weak model strong, and it does not remove your obligation to test. It adds a component to your request path, which means it becomes something you depend on, and that dependency deserves the same questions you would ask any vendor about uptime, data handling, and what happens to your traffic if they have a bad week. It also does not negotiate for you. What it does is put you in a position where negotiating is possible, which is a different and more modest claim than most of the marketing makes.
The honest summary is that a consolidation layer converts a procurement problem into a configuration problem. That is a smaller promise than “AI cost savings” and a much easier one to verify.
A 30-day consolidation checklist
This is not a twelve-month transformation programme. A capable team can complete the following in a month.
Days 1 to 5: inventory every key in use. Search your cloud accounts, your secret manager, your expense reports, and your code. Expect to find keys you did not know existed. Write down who owns each one and what it powers.
Days 6 to 10: classify workloads by task type. Group them into buckets such as classification, summarisation, extraction, drafting, code generation, and complex reasoning. Do not group by team. Group by what the model is actually being asked to do, because that is what determines which model can do it.
Days 11 to 15: set a baseline per bucket. For each group, record three numbers: an acceptable quality threshold, an acceptable latency, and current cost per thousand requests. Without a baseline you cannot prove a change was an improvement.
Days 16 to 25: shift 10 percent of traffic as a canary. Pick your least contested bucket. Route a tenth of it through the consolidation layer to a cheaper model and compare against the baseline you just recorded.
Start with the workloads where quality is least contested, meaning classification, summarisation, and routine extraction. Those are also the areas where cheaper models that now cover routine workloads have closed the gap most convincingly. One caution worth carrying into the test: a low published rate per token is not the same as a low bill, because a chattier model can use enough extra tokens to erase its price advantage. Measure the spend on your own tasks rather than trusting the sticker price.
Days 26 to 30: stand up a spend dashboard broken out by team. Whatever else you do, do this. Once a manager can see their own consumption, behaviour changes without anyone issuing a policy.
Illustration: a 30-day AI consolidation timeline covering inventory, classification, baselining, canary testing, and spend attribution.
What to watch through 2026
Three things are worth tracking over the next year.
Price competition is not finished. The gap between frontier models and the tier below them keeps narrowing while the price gap stays wide, which puts steady downward pressure on published rates.
Open-weights models are already good enough for most routine work. The interesting question is no longer whether they can do the job, but how much of an organisation’s volume is routine. In most companies it is more than the engineering team assumes.
And the real advantage is moving up the stack. Choosing a model was the 2024 problem. Deciding which of hundreds of models should handle each individual request, and proving that decision was correct, is the 2026 problem. Companies that can answer it will run the same workloads for meaningfully less than the companies that cannot.
The sprawl was never the mistake. Not being able to measure it was.
