AI Vendor Lock-In: The Switching Cost Trap

Anthropic moved Claude Enterprise off its flat fee and onto usage-based billing, and heavy accounts started seeing bills two to three times higher for the same work. Around the same time, the CEO of Lindy moved every bit of his product’s traffic off one model and onto a cheaper open-weight one. Two headlines, one lesson: the price of the model you build on is not fixed, and the day it changes is the day you find out how hard it is to leave.

That is the trap. When the market gives you a reason to switch, a cheaper model, a better one, a vendor who just raised your rate, you reach for the exit and discover the door is heavier than you thought. Not because of a contract. Because of everything you quietly built on top of one provider while you were shipping.

This is the durable version of a story that keeps repeating with new names. I have wired products to a single model provider and felt the pull of that convenience. It is real, and it compounds. This post is the map of where that lock-in accrues, why the cost of leaving multiplies instead of adds, and the one architectural line that keeps switching a config change instead of a rewrite.

What this covers

• The bill you never get sent
• The Switching Cost Stack: where lock-in actually accrues
• The Switching Trap: why the moment to leave is the moment you cannot
• Why switching costs multiply instead of add
• Data gravity: the heaviest layer
• The Portability Line: the architecture that keeps you free
• The portability tax: what staying free actually costs
• The contrarian take: lock-in is convenience debt you signed for
• What to do Monday morning: the Exit Test
• FAQ

The bill you never get sent

Every founder can read the price of a model. It is on the pricing page, per token or per seat or per resolution. What no page shows you is the price of leaving. That number does not appear until you try to move, and by then it is not a line item, it is a project.

Here is what the research says that project costs. Analysts now put the average AI vendor migration at around 315,000 dollars. For more than half of IT leaders who have actually run a platform migration, the real number crosses a million. When teams measure the switching cost as a share of the original spend, it lands somewhere between 19 and 34 percent, and across major platforms the full rebuild runs 2.3 to 5.7 times the original implementation. You did not pay to build once. You are paying to build, and then paying a multiple of that to ever build somewhere else.

The part that should worry a founder most is not the size of any single bill. It is that most buyers are accumulating these costs from several vendors at the same time and nobody is keeping the tally. Enterprise teams in 2026 are stacking switching costs across Microsoft, Salesforce, ServiceNow, and their cloud provider simultaneously, and almost none of them have a method for measuring what that pile means for their negotiating position two years out. Small teams do the same thing faster. One model provider for generation, its embeddings for search, its agent framework for orchestration, its evals for compliance. Four dependencies, one vendor, zero tracking.

The vendor is not hiding this from you. You are hiding it from yourself, one convenient decision at a time. Every time you use a provider-specific feature because it is right there and it works, you add a little weight to a bill you will only read on the way out. I have written that check. The trap is not that the cost is high. The trap is that it is invisible until the exact moment you most want to move.

This is a cousin of a problem I have written about before. When your model vendor can turn around and compete with you directly, that is platform risk. When the price you pay is below the true cost of compute and destined to rise, that is the subsidy problem. Switching cost is the third leg. It is what turns those first two threats from annoyances into cages. You cannot walk away from a vendor who competes with you, or from a price that just doubled, if walking away costs a year of engineering.

The Switching Cost Stack: where lock-in actually accrues

Lock-in is not one thing. If it were, you could just avoid that one thing. It is a stack, and it accrues at six separate layers, each of which feels harmless on the day you add it.

Layer 1, prompts and scaffolding. The prompts that make your product sing are tuned to one model’s habits. Research on cross-model prompting finds that model-specific optimization improves output quality by 45 to 70 percent over a generic prompt. Read that number the other way. Up to 70 percent of the quality you see is not the model, it is the fit between your prompt and that model. Move to another provider and you do not just copy the prompt across, you rebuild the fit.

Layer 2, the API and SDK surface. Every call you write assumes one vendor’s request shape, one tool-calling format, one streaming protocol. It is a thin layer, and it feels replaceable, right up until you count how many files import the client directly.

Layer 3, data gravity. This is the heavy one, and it gets its own section below. Your embeddings, your fine-tunes, your logs, and your evaluation sets all live in one vendor’s format. Data is the layer that does not want to move.

Layer 4, workflow entanglement. Your orchestration, routing, and retry logic all grew up around one provider’s behavior. You learned its rate limits, its failure modes, its timeouts. That knowledge is baked into code, and it does not transfer.

Layer 5, evidence and compliance. If you sell to anyone who asks questions, you have accumulated audit trails, red-team results, and safety documentation tied to a specific model. Switch, and a compliance reviewer wants all of that re-run.

Layer 6, team fluency. Your people know how to get the best out of this vendor. Your internal docs say “here is how we prompt.” That fluency is an asset, and like every other layer, it is an asset that only pays out while you stay.

Notice what happens when you read that table top to bottom. No single row looks fatal. That is exactly why the stack works. You never make one big decision to get locked in. You make sixty small ones, and the vendor collects on all of them at once the day you try to leave. This is the same shape as the efficiency trap, where each cheap shortcut looks like a win and the bill only shows up in aggregate.

The Switching Trap: why the moment to leave is the moment you cannot

Here is the mechanic that makes lock-in a trap instead of just a cost. Two things move over the life of your product, and they move in a way that closes the door on you.

The first curve is the value of switching. Early on it is low. You just picked a vendor, the price is fine, nothing better is calling your name. Over time that value climbs. Better models ship. Open-weight options catch up. Your volume grows until a 2x price difference is real money. And your own vendor raises the rate, the way Anthropic moved Claude Enterprise from a flat fee to usage-based billing and heavy accounts watched their bills climb two to three times. Every one of those events makes leaving more valuable.

The second curve is the cost of switching. Early on it is near zero, because you have barely built anything. But it climbs faster than the value curve, because every sprint adds weight to all six layers of the stack at once. The two curves cross. I call that crossover the Lock-In Point.

Before the Lock-In Point you are free. Leaving is cheap, but you have little reason to. After it, the story flips. Now you have every reason to leave, a cheaper model, a better one, a vendor who just doubled your rate, and leaving costs more than you would save. You are not staying because the vendor is winning on merit. You are staying because the exit is more expensive than the abuse. That is the trap, and it is why the exact moment switching becomes worth it is the moment it starts to feel impossible.

The Lindy story is the rare public example of a team that got out. Its founder moved the entire product off one provider and onto a cheaper open-weight model. That is only possible if the cost curve was held down on purpose, if switching was designed to be a config change rather than a rebuild. Most teams never drew that line, so they sit on the wrong side of the crossover and pay the rate hike because the alternative is worse.

Why switching costs multiply instead of add

The single most expensive mistake in reasoning about lock-in is treating the stack as a sum. It is not a sum. It is a product.

Here is why. If your prompts, your API calls, and your data were three independent boxes, you could swap one at a time and pay one third of the cost each time. But they are not independent. Your prompts assume your data is embedded a certain way. Your workflow assumes your API behaves a certain way. Your evals assume your prompts produce a certain shape. Pull one layer out and the layers above it break, so you cannot migrate incrementally. You migrate the whole entangled column or nothing.

That entanglement is why the measured numbers land where they do. A full switch running 2.3 to 5.7 times the original build is not a story about one hard layer. It is the story of six layers that each require the others to be in place, so the total effort is closer to the product of the layer weights than the sum. This is the same reason a rewrite always costs more than the sum of its parts. You are not paying to rebuild the pieces. You are paying to re-establish the relationships between them.

There is a compounding effect on top of that. The deeper you go, the more the layers reference each other, so the cost of switching does not just grow, it accelerates. A product six months in has a switching cost you could stomach. The same product two years in, with fine-tunes and compliance evidence and a team fluent in one vendor’s habits, has a switching cost that looks like a full replatform. The clock is not your friend. Nothing about lock-in gets cheaper by waiting, which is the opposite of how founders instinctively treat it. We tend to say we will deal with portability later. Later is when the multiplier is highest.

This is worth putting next to the commoditization clock. Models are getting cheaper and more interchangeable on a predictable schedule. The value of being able to switch is rising for everyone, on a clock you do not control. If your cost of switching is rising even faster on your own internal clock, the gap between what switching is worth and what it costs to you personally widens every quarter. You end up watching the whole market get cheaper while you personally cannot move.

Data gravity: the heaviest layer

Of the six layers, one pulls harder than the rest. Practitioners borrowed a term from physics for it: data gravity. The more data you accumulate in one place and one format, the harder everything around it is to move, because the data itself resists relocation.

In an AI product, data gravity shows up as embeddings, fine-tunes, stored logs, and evaluation sets, all shaped by one vendor’s models and tools. Embeddings are the sharpest example. If you embedded a large corpus with one provider’s embedding model and stored the vectors, those vectors are only meaningful in that model’s space. Switch embedding providers and the vectors are worthless. You have to re-embed the entire corpus, which for a real product is not a weekend job, it is a compute bill and a re-indexing project and a fresh round of quality testing on the retrieval side.

The teams who saw this coming did one small thing that changed everything. They kept the raw source data as the source of truth and treated the embeddings as a derived, disposable artifact. They put a thin retrieval interface in front of the vector store, a single function that takes a query and returns chunks, so that all the database-specific and model-specific code lives behind one boundary. Re-embedding then touches one place instead of forty. The guidance that keeps showing up in 2026 practitioner writing is blunt about this: abstract the embedding model from the vector database client from day one, because if re-embedding requires touching multiple parts of the codebase, the migration will be expensive.

There is a broader lesson hiding in the vector database story. Through 2022 to 2025 the default move was to reach for a specialized vector-native database. By 2026 a lot of teams walked that back toward extended relational databases, with pgvector becoming the default for anyone who did not truly need a dedicated store. The teams that had abstracted their retrieval layer made that shift as a swap. The teams that had wired their app directly to one vendor’s proprietary index made it as a migration. Same market change, two completely different bills, decided entirely by whether a boundary existed.

The principle generalizes past embeddings. Anywhere you generate a derived artifact in a vendor’s format, a fine-tune, a cached response set, a proprietary index, ask one question: if I deleted this and had to regenerate it somewhere else, what would it cost? If the answer is large, that artifact is gravity, and gravity is the layer that decides whether you are ever really free to move.

The Portability Line: the architecture that keeps you free

Everything above sounds like a case for paranoia. It is not. It is a case for one architectural decision, made early, that costs very little and changes your entire negotiating position. I call it the Portability Line.

The idea is simple. Your application never talks to a model provider directly. It talks to one adapter you own, a thin interface that exposes exactly the operations your product needs: generate, embed, call a tool. Behind that adapter you wire up the actual vendor. Everything provider-specific, the client, the call shape, the retry logic, the model name, lives behind the line. Nothing in front of it knows which vendor is answering.

Once that line exists, switching stops being a rewrite and becomes a configuration change. This is exactly the mitigation that keeps appearing in enterprise guidance for 2026: put a vendor-neutral model router in front of every application so switching becomes configuration, not a code project, and keep a second equivalent model wired up per use case so you are never down to one option. The pattern people converge on is a small stable of three to five models routed by task, never one, and never so many that you drown in choice.

The Portability Line is not a heavy piece of engineering. On day one it is a wrapper of maybe a few hundred lines. What makes it hard is not the code, it is the discipline, because every provider-specific feature that shows up is a small temptation to reach around the line and call the vendor directly for that one convenient trick. Every time you do, you punch a hole in the boundary. The line only works if you defend it every sprint, which is why I said at the top that portability is a line you draw at commit one and defend after. The drawing is easy. The defending is the job. This is close in spirit to spec-driven development, where the durable asset is the specification, not the vendor-specific implementation that happens to satisfy it today.

The portability tax: what staying free actually costs

I would be selling you something dishonest if I pretended the Portability Line is free. It is not. It carries a real tax, and you should choose it with your eyes open.

The tax is quality and speed. Remember that model-specific tuning buys 45 to 70 percent better output. If you refuse to use any vendor-specific feature so that your code stays perfectly portable, you leave some of that quality on the table. You also give up the newest capabilities, which almost always ship as provider-specific features first and become portable standards only later. A team that insists on the lowest common denominator across three models will sometimes ship a worse product than a team that went all in on one and tuned it to death.

So the honest position is not maximum portability. It is deliberate portability. You draw the line at the layer that matters most, which is almost always data gravity and the model call itself, and you let the higher layers be a little vendor-flavored where the quality gain is worth it. You keep a plain, portable version of each critical prompt next to the tuned one, so the tuned version is an optimization you can drop, not a dependency you cannot. You accept that your backup model gives you 90 percent of the quality at a moment’s notice, and that 90 percent available beats 100 percent trapped.

The way to think about the tax is as an insurance premium. You are paying a small, ongoing quality-and-effort cost to hold the option to leave. Like any insurance, it feels like waste right up until the day the vendor doubles the price or the better model ships or the provider decides to build your product themselves. On that day, the premium is the cheapest money you ever spent. The founders who skip the premium are not wrong that it costs something. They are wrong that they will not need it, in a market where the CNBC-documented shift from spending on the biggest model to routing for efficiency is already the dominant move. The teams making that shift smoothly are the ones who bought the insurance early. This connects to the deeper build versus buy question: portability is what lets you rent without ever being owned.

The contrarian take: lock-in is convenience debt you signed for

The comfortable story about vendor lock-in casts the vendor as the villain. They designed the trap, they hid the switching costs, they engineered the dependency. It is a satisfying story and it is mostly wrong.

No vendor forced you to call their client from forty files. No vendor made you store your embeddings as your source of truth. No vendor stopped you from keeping a portable version of your prompts. Every layer of lock-in in your product got there because someone on your team, often you, chose the convenient path on a Tuesday when the goal was to ship. The vendor did not build the cage. You did, one bar at a time, and the vendor simply owns the property it sits on.

I find this framing far more useful than the villain story, because it puts the fix back in your hands. If lock-in is something done to you, all you can do is complain and negotiate. If lock-in is convenience debt you took on yourself, then like any debt, you can choose how much to carry, you can refinance it, and you can decide today to stop adding to the principal. The vendor’s pricing page is not the thing that determines whether you are trapped. Your architecture is. Two founders can build on the identical vendor and one is free while the other is caged, and the only difference is whether they defended a boundary.

This reframes the whole switching-cost conversation from a market complaint into an engineering decision, which is where a founder actually has power. You cannot control whether Anthropic moves to usage-based billing or whether the next great model comes from a vendor you have never integrated. You can completely control whether that event is a config change or a crisis. The uncomfortable truth is that most trapped teams had every chance to stay free and traded it away for a slightly faster Tuesday, many Tuesdays in a row. The good news buried in that discomfort is that the same choice is available to you right now, on the product you are building today.

What to do Monday morning: the Exit Test

Reading about lock-in changes nothing. Measuring yours changes everything, because it turns an abstract fear into a number you can act on. Here is the test I would run.

Run the Exit Test on one real use case. Pick a single feature in your product that calls a model. Ask one question: could a competent engineer on your team move this use case to a second, different-vendor model in one working day? Not perfectly, just working. If yes, this use case is portable and you are on the free side of the Lock-In Point for it. If no, write down exactly what is in the way. That list is your lock-in, made concrete.

Read your Lock-In Ledger. Go through the six layers and mark where you are entangled. How many files import the vendor client directly? Are your embeddings re-buildable from raw source, or are they the source? Do your prompts have a portable version, or only a tuned one? Is your eval harness tied to one model’s output shape? You are not fixing anything yet. You are just reading the invisible bill so it stops being invisible.

Draw the line at data gravity first. If you do only one thing this week, put a thin interface in front of your model calls and your embeddings. Store raw source as truth, treat embeddings as disposable, route every model call through one adapter. This is the highest-weight layer and the cheapest to fix early. Every week you wait, the multiplier climbs.

Wire up a second model behind the line. Not to use it full time, just to prove the line works. Route ten percent of one non-critical path to a backup model. The day you can do that is the day you have real negotiating power, because your vendor is no longer your only option, and you will feel the difference the next time a price changes.

Set a portability budget. Decide, out loud, how much quality you are willing to trade for the option to leave. Maybe it is five percent. Maybe on your most critical path it is zero and you accept the lock-in there on purpose. The point is to make it a deliberate choice with a number, not an accident you discover during a migration. This is the same discipline as deciding what to automate versus hire: the answer is not always yes, but it should always be chosen, never defaulted into.

Do these five things and you have not eliminated lock-in. You have made it visible, bounded, and yours to price. That is the whole game. You will still build on vendors, you will still take on some convenience debt, and you should. The difference is that you will know your number, you will have drawn your line, and when the market hands you a reason to switch, the door will open. The founders who win the next few years of cheap and abundant models are not the ones who picked the perfect vendor. There is no perfect vendor, and the best one changes every quarter. The winners are the ones who stayed free to change their mind. For the wider view of how this fits a founder’s operating decisions, the AI-native founder playbook ties portability to the rest of the stack, and if you are thinking about which skills hold their value while tools churn, what to learn in the AI era makes the case that architectural judgment outlasts any single model. The narrow-market view in why vertical AI winners go narrow is the same instinct pointed at your product surface instead of your stack.

Frequently asked questions

What is AI vendor lock-in?

AI vendor lock-in is the operational dependency that builds up when your product relies so deeply on one provider’s models, APIs, data formats, and tools that switching to another would take major engineering effort, cost, or disruption. What makes it different from classic software lock-in is that it is a compound dependency: it accrues at every layer of the AI stack at once, from prompts and API calls to embeddings, workflows, compliance evidence, and team habits, and those layers multiply together into the total cost of leaving.

How much does it actually cost to switch AI vendors?

Recent research puts the average AI vendor migration around 315,000 dollars, with more than half of IT leaders who have run a platform migration reporting real costs above a million. Measured as a share of the original spend, switching runs roughly 19 to 34 percent, and a full rebuild across major platforms lands at 2.3 to 5.7 times the original implementation cost. The exact number for your product depends on how entangled your six lock-in layers are, especially data gravity.

Why do switching costs multiply instead of add?

Because the layers are not independent. Your prompts assume your data is embedded a certain way, your workflow assumes your API behaves a certain way, and your evals assume your prompts produce a certain shape. You cannot swap one layer at a time without breaking the ones above it, so you migrate the whole entangled column at once. The total effort is closer to the product of the layer costs than the sum, which is the same reason a full rewrite always costs more than its parts.

What is the Portability Line?

The Portability Line is a single boundary in your architecture. Your application talks only to one adapter you own, and everything vendor-specific, the client, the call shape, the model name, the retry logic, lives behind that adapter. Nothing in front of the line knows which vendor is answering. Once the line exists, switching providers becomes a configuration change instead of a rewrite, because you only touch the code behind the boundary.

Is it worth staying fully model-agnostic?

Usually not fully. Model-specific tuning can improve output quality by 45 to 70 percent, and the newest capabilities ship as vendor features first. The better approach is deliberate portability: draw a hard line at the highest-weight layers, the model call and data gravity, keep a portable version of critical prompts next to the tuned ones, and accept a small quality tax on the rest. The goal is 90 percent quality that you can move, not 100 percent quality that traps you.

What is data gravity and why is it the heaviest layer?

Data gravity is the tendency for accumulated data to resist relocation. In AI products it shows up as embeddings, fine-tunes, logs, and eval sets shaped by one vendor’s models. Embeddings are the sharpest case: vectors created by one embedding model are meaningless in another, so switching forces you to re-embed your entire corpus. Keeping raw source as the source of truth and treating embeddings as disposable, behind a thin retrieval interface, is the cheapest insurance against this layer.

How do I measure my own lock-in?

Run the Exit Test. Pick one real use case and ask whether a competent engineer could move it to a different-vendor model in one working day. If yes, it is portable. If no, write down what is in the way, and that list is your lock-in made concrete. Then read your Lock-In Ledger across all six layers: how many files import the vendor client directly, whether embeddings are re-buildable, whether prompts have a portable version, and whether your evals are tied to one model’s output.

Should a small startup worry about lock-in, or is this an enterprise problem?

Small teams should worry more, not less, because they accrue lock-in faster and have less budget to absorb a migration. The good news is that the fix is cheap exactly when you are small: a Portability Line on day one is a few hundred lines of code, while the same boundary added two years in is a replatform. Lock-in is not something done to you by big vendors. It is convenience debt you take on one shortcut at a time, which means a small team that draws the line early stays freer than an enterprise that never did.

This is where the switching-cost question meets the rest of the picture. Portability is the counterweight to platform risk and the only real defense when the compute subsidy ends and prices climb toward their true cost. Draw the line early, defend it every sprint, and the trap never gets to close on you.