Notes on the bill.

By 2017 the finance organizations that had moved early were discovering they had a cloud bill. Not a small one. A line item that had not existed two years earlier, growing fast enough that someone in the CFO's office wanted a name to put next to it on the monthly review. The teams that had migrated had delivered what the business case described. Staying able to leave was not in it, and went undone.

I have been thinking about that pattern a lot lately. The shape of it is back.

What the cloud cycle taught us

The cloud cost story is told now as if everyone knew. Nobody knew. The 2014-to-2018 migrations were sold on flexibility, elasticity, and a capex-to-opex story that read well in a board pack. All of that was true. What got underweighted at the time, and looks obvious in hindsight, was the specific shape of the lock-in: egress fees, reserved-instance commitments, services that were nominally portable but actually wired into a particular provider's identity, networking, and storage idioms. A firm that had moved aggressively in 2015 was, by 2019, paying a bill only that one vendor could have written, and unwinding it was a program rather than a decision.

The function that eventually rose to manage this, FinOps, did not exist on day one of those migrations. It was invented because the bill demanded it. The discipline existed in pieces in older procurement and treasury practice, but the job of sitting between engineering and finance and asking what are we paying for, why, and what would it cost to stop was new. It took a cycle to build.

That is the part I keep coming back to: not the bill itself, but the lag between the bill arriving and anyone in the org being equipped to read it.

The AI bill, and why it is worse

The current cycle has the same shape and three differences that make it harder.

The first is the unit. An EC2 hour is opaque, but it is countable in ways an engineer can reason about. A token is opaque in a different way. Token spend is downstream of prompt design, model choice, context length, retrieval strategy, and a dozen other knobs, most of which are owned by people who are not the people who get the bill. The line item moves for reasons the finance function cannot interrogate on its own.

The second is the product. With cloud, the product was infrastructure. You could, with enough work, re-host the same application on a different provider and get the same behavior. With a model, the model is the product. A swap is not a re-host: it is a re-evaluation of every prompt, every eval, every downstream judgment your team has tuned to the specific behavior of the specific model you have been using. The switching cost is not plumbing. It is trust.

The third is the frontier. With cloud, the capabilities were broadly comparable across the major providers within a year of each other. With models, the frontier moves fast, and the gap between the best available model and the second-best for a specific task is sometimes meaningful and sometimes not, and the answer changes every quarter. The strategy of "wait, consolidate, optimize" that eventually worked for cloud carries a real opportunity cost here. Waiting is not free.

Which is why the AI bill will land harder than the cloud bill did. It will be visible sooner. The function to manage it will not exist yet. And the exit cost will not show up on an invoice; it shows up as months of engineering and degraded behavior.

What a capabilities assessment looks like

If the exit costs that much, the effort has to move upstream, to the vetting. I have run one of those at full strength, once.

The client was the insurance arm of a global asset manager, deciding whether to outsource roughly $120 billion of back- and middle-office flow. My partners and I at Cambrian ran the assessment across 2007 and 2008. I have written elsewhere about the prework question it raised; this is about how the vetting worked.

The core of the methodology was joint design sessions, not RFP responses or demos or reference calls: two days on site with each vendor, every subject-matter expert at the table, every back- and middle-office process walked end to end against the vendor's actual platform behavior with the vendor's actual people answering. We built the scoring rubric from the gaps that surfaced in those rooms, not the gaps the vendor acknowledged in the RFP. The assessment eliminated the non-contenders quickly. One vendor took it seriously enough that its chief executive got involved, and the proposed fees came down.

What made it work was that the assessment gave the client a credible walk-away: for every gap that surfaced, an answer to "and if you cannot do this, here is what we do instead." That is what vendor vetting is: the buyer being credibly willing to not buy, not procurement running a scoring spreadsheet.

Most AI vendor evaluations I have seen over the last few years do not look like that. They look like demos, internal champions, and a procurement step appended at the end. The capability frontier is moving fast enough that the buyer doesn't feel able to walk, and the vendor knows it.

What vendor-agnostic means

Full agnosticism is expensive, and full lock-in is cheap right up until the day you need to leave. The middle path is the one worth working on, and it is not glamorous.

The cloud playbook eventually settled on portability at the seams, not at the core. You did not rewrite every application to be multi-cloud. You kept the option open at specific layers: identity, secrets, observability, the data plane. You paid a small portability tax in those layers in exchange for the ability to move the things that mattered.

The AI version of that has four seams worth paying for.

The eval harness is yours. The prompts are versioned in your repo. The regression suite runs against any model you can hit through an API. The day you decide to swap, you have a Tuesday afternoon's worth of work to know whether the swap is safe, not a quarter.

The routing layer is yours. The application code does not import a specific provider's SDK in twelve places. It calls one interface, and the interface chooses the model. The code is boring on purpose.

The data layer does not leave. Whatever fine-tuning, retrieval, or context you accumulate is held on infrastructure you control, in a format you can move. If a vendor's retention or training policy changes, you can leave with everything you accumulated.

The contract has an exit. A real one: somebody on the buying side has walked through it with engineering and confirmed they could execute it within ninety days.

None of this is novel; it is the cloud playbook with the nouns swapped. The reason it doesn't get done is the same reason it didn't get done in 2015: it costs something now to preserve optionality later, and the team feeling the pressure to ship does not want to pay the tax.

Whose problem this is

The framing of vendor lock-in as a procurement problem is the part that goes wrong first. Procurement can negotiate price. It cannot negotiate switching cost, because switching cost is mostly built into the engineering. By the time the bill is large enough that procurement is asked to fix it, the engineering decisions that made the bill that shape have been in place for a year or two, and they are not the kind of decisions you reverse over a quarter.

The fix is upstream of the bill, in the seams of the architecture, on the afternoon when somebody on the build team is choosing how to call the model. The PM's job is to make sure that decision is made with the bill in view, not after.

The bill will land before the discipline to manage it does.

What I expect

I do not think AI vendor lock-in will look exactly like cloud vendor lock-in. It will be worse in some ways, because the product is the behavior and the behavior is the trust. It will be easier in others, because the abstraction surface is narrower (a prompt, a response) and the seams are cleaner to draw than they were in 2015.

What I expect to be true is the lag. The firms that come out of this cycle well are the ones that decide, now, that the seams are worth paying for, and the ones whose buyers are credibly willing to walk.

The cloud generation learned this a cycle late. This time the lesson is already written. So is the excuse for ignoring it.

// DG