Model Lock-In: The Quiet Tax of the AI Era

Model Lock-In: The Quiet Tax of the AI Era AI July 28, 2026 11 min /ai/model-lock-in/ Foundation models are commoditizing. The lock-in is not. It moved up the stack into prompts, memory, skills, and the muscle memory of how I work. A field report on where model lock-in actually hides and what I do to keep it shallow.

I tried to switch a workflow from Claude to a competing model last month. The model itself was fine. The switch was not. Half a day in, I realized I was not migrating a model. I was migrating a habit. My prompts were tuned for one provider's quirks. My skills folder assumed a specific tool calling shape. My eval set was implicitly calibrated to one model's failure modes. The "model" was the smallest part of what I had to move.

That afternoon convinced me that the AI industry has already invented its version of vendor lock-in, and most people have not noticed because the word "model" makes it sound like the thing being locked is the model. It is not. The model is the cheap part. What is locked in is everything wrapped around it.

This post is a field report on where model lock-in actually hides, why it compounds faster than people expect, and what I have started doing to keep mine shallow.

I have lived through several rounds of vendor lock-in in my career. Database lock-in in the 1990s. Java EE app server lock-in in the early 2000s. Cloud lock-in in the 2010s, where the word "egress" stopped being networking jargon and became a line item on the CFO's desk. Each cycle followed the same shape. The technology felt new. The lock-in felt old.

Vendor lock-in works by raising the cost of the next switch. The first install is free or cheap. Then small decisions, made one at a time, accumulate into a position you cannot unwind without writing it all again. Cloud lock-in did not happen because anyone signed a multi-year contract on day one. It happened because S3 became the place the data lived, then IAM became the place identity lived, then a managed Kubernetes service became the place the cluster lived, and one day someone added it up.

Model lock-in is the same pattern. Pick a model. Build a prompt around its quirks. Train your eval set on its failures. Wire your tools to its function calling syntax. Set up memory inside its product. Pay for the bundled subscription. Six months in, the cost of switching is not the cost of changing one API call. It is the cost of changing every habit you built on top of it.

The reason this is confusing is that the model itself is becoming a commodity. Foundation models have converged on roughly comparable capability for most everyday tasks. You can do serious coding with Claude, with Gemini, with GPT, with Llama, with Qwen, with Grok. You can summarize, translate, draft, plan, and reason with all of them. The benchmarks are noisy and the gaps are real, but the gaps are no longer the kind of gap that justifies refusing to ever switch.

If the model were the thing being locked in, the lock-in would be weakening. It is not weakening. It is moving.

This is the Christensen pattern I keep coming back to. When one layer of a stack commoditizes, the value, and the lock-in, migrate to an adjacent layer that is still scarce. In AI right now, the model is the layer that is commoditizing. The layers around it, the prompt scaffolding, the tool integration, the memory, the personalization, the workflow, are the layers that are quietly hardening.

Call it what it is. Foundation model providers are competing on capability. They are winning on lock-in.

From running my own daily workflow across multiple providers for the better part of a year, I have started to map the five layers where lock-in is real and growing. None of them sound like lock-in when you adopt them. All of them act like lock-in when you try to leave.

One. Prompt and skill libraries. Every serious user of an AI model accumulates a library of prompts that work. They are short, they are crafted, and they are tuned to a specific model's biases and failure modes. Claude rewards a different prompt shape than Gemini. Gemini rewards a different shape than GPT. Codex CLI behaves differently from Cursor's agent. The library you build is portable in theory and brittle in practice. Move it to a new model and the prompts that used to land start drifting. The skills folders, the slash commands, the multi-step routines, all of it has to be re-tuned. This is the cheapest layer to underestimate and the most expensive layer to actually move.

Two. Memory and personal context. Claude Projects, ChatGPT Memory, Gemini's persistent context, Custom GPTs, Claude Skills, Gemini Gems, all of them are designed to make the model feel like it knows you. They work. They also create a personal data flywheel that does not export cleanly. The longer you use them, the more the model "knows," and the less the next model knows about you on day one. This is the consumer version of cloud lock-in. The data is the moat, and the data lives inside the provider's product.

Three. Tool calling and function calling shapes. Each provider has its own conventions for tool definition, tool invocation, JSON mode, structured output, and parallel tool use. They are similar enough to feel portable and different enough to break in production. A small difference in how a model handles a tool that returns an empty array becomes a long debugging session when you switch. Multiply that by every integration in your stack and the migration cost stops being theoretical. I have done this. It is not pleasant.

Four. Eval suites and quality baselines. If you are doing this seriously, you have an eval set that defines "good." That eval set was almost certainly tuned to a specific model. It catches that model's failure modes. It does not catch the next model's failure modes. Switching models means re-running your evals, finding the new failures, fixing the prompts, and re-baselining. It is invisible work. It also has to happen every time.

Five. Subscriptions and habits. The most underrated form of lock-in is the one your wallet already accepted. Claude Max, ChatGPT Plus or Pro, Gemini Advanced, Cursor, the IDE plugins, the terminal tools, the bundled enterprise seat. Each one is a small monthly commitment that ties you to a specific surface area. The surface area becomes muscle memory. The muscle memory becomes a daily reflex. The reflex becomes a workflow. The workflow becomes a switching cost. None of this looks like lock-in on the receipt. All of it acts like lock-in when you try to break it.

The thing that makes model lock-in dangerous, more dangerous than I think most people are tracking, is that the five layers compound. Each layer raises the cost of moving the layer below it.

If your prompts are tuned to one model, your skills folder is built on top of those prompts. If your skills folder is built on those prompts, your tool definitions assume a specific output shape. If your tool definitions assume a specific output shape, your eval set is calibrated to that shape. If your eval set is calibrated, your baseline of "good" is locked. And if your baseline is locked, you stop noticing that switching has become impossible because everything you measure success by is a measurement of how well you fit the current model.

This is exactly how cloud lock-in worked. No single decision was the lock-in moment. The lock-in was the sum.

The market dynamic on top of this is worth saying out loud. Providers are not stupid. Every feature that makes the day-to-day experience better, persistent memory, longer context, native tool use, integrated agents, file workspaces, also raises switching cost. The features genuinely help users. They also genuinely lock them in. Both things are true at once, and pretending only one is true is how you end up surprised by your own switching cost two years from now.

There is a counter-current worth tracking, and it is the same one I wrote about with MCP. Standardization layers exist to flatten lock-in. The Model Context Protocol is the most visible example, but it is not the only one. Open agent frameworks, vendor-neutral tool definitions, OpenAI-compatible APIs that let you swap a provider behind the same client, open-weight models that you can self-host. All of these are attempts to push value back toward the user and away from the provider.

I am cautiously optimistic about MCP for the same reason I was cautious about it earlier this year. It works for the things it is genuinely the right shape for, plug-and-play tools, multi-vendor agent ecosystems, third-party extensibility. It does not magically remove lock-in from the layers above it, prompts and memory and personalization, that the protocol does not touch. A standard for tool calling does not standardize the way a model interprets a system prompt. A standard for tool discovery does not standardize the way a model handles ambiguous instructions.

The honest read is that standardization helps in the layers where the protocols actually live, and the lock-in keeps migrating up to layers that are not standardized yet. The fight over those upper layers is the next decade of this market.

I am not trying to avoid lock-in. That is unrealistic, and it is also strategically wrong, because some lock-in is the price you pay for using a thing well. What I am trying to do is keep my lock-in shallow enough that I can switch when I want to, not when I have to.

A few rules I have settled into:

• Spread daily usage across at least two providers. Not for redundancy. For taste. If I only use one model, I lose the ability to feel where it is good and where it is weak. Using two keeps both honest in my head.
• Keep prompts and skills in plain text under version control. Not inside a provider's product. Not inside a Custom GPT or a Gem. In a git repo I own. Provider-specific tweaks live as small overlays on top of a portable base.
• Treat memory features as convenience, not as truth. The canonical version of "what the AI should know about me" lives in files I control. The provider's memory is a cache of that, not the master. If I lose the cache, I rebuild it in an afternoon.
• Define tool calls with portable schemas. JSON schema, not provider-specific syntax. A thin adapter per provider. The adapter is the only thing that has to change when I switch.
• Maintain an eval set that runs against multiple models. Not to pick a winner. To stay aware of who is good at what. The day I notice my eval set has only ever run against one provider is the day my baseline has been quietly captured.
• Renew subscriptions deliberately, not automatically. Once a quarter I look at what each subscription is actually doing for me. The ones I am paying for out of habit get cut. The ones I am paying for out of value get renewed.

None of this is dramatic. All of it is unglamorous, the way good lock-in hygiene always is. The cost is small now. The cost of not doing it shows up two years later, when the switch you wanted to make is suddenly the switch you cannot make.

Vendor lock-in did not go away when the cloud arrived. It moved. It moved from the database to the storage layer, from the storage layer to the identity layer, from the identity layer to the managed services layer, and finally to the data gravity itself. Each move made the lock-in less visible and more total.

Model lock-in is on the same trajectory. The model is the cheap, visible part. The expensive, invisible part is the scaffolding around it. The providers know this. The protocols are racing to catch up. The users, mostly, are paying attention to the wrong layer.

I do not think the answer is to refuse to commit. The answer is to commit with eyes open. Pick the model that fits the work today. Build the scaffolding in a way that survives switching tomorrow. Treat your prompts, your memory, your tools, your evals, and your subscriptions as assets you own, not as features you rent. The model providers are doing their job, which is to make their model the best place to live. Your job is to make sure the place you live is one you can leave.

The pattern repeats. The technology is new. The lock-in is old. What is yours to control is whether you walked into it on purpose.