Choosing an AI model feels like a technical decision, but it quickly becomes a business commitment. Prompts get tuned to one model’s quirks, data gets stored in one cloud, and contracts include spending minimums. Months later, a better or cheaper model appears and switching is painful. This guide shows where lock-in actually hides and gives a checklist to keep your options open. It is general guidance, not advice about any one vendor.

Why the topic is timely

Marketplaces are making multi-model access easier. Cloud catalogs such as Google Cloud’s Model Garden list first-party, open and third-party models side by side, and labs are listing their models on competitors’ clouds, as we discuss in our analysis of OpenAI models arriving on Google Cloud. Easier access does not remove lock-in, though; it moves it into your code, data and contracts.

Where lock-in hides

  1. Prompts and behavior. A prompt tuned for one model may behave differently on another, so a swap needs re-testing.
  2. Provider-specific features. Proprietary tool-calling formats, caching options, batch modes and fine-tuning formats do not transfer. For example, prompt caching rules, retention windows and pricing differ by provider and by model generation, as OpenAI’s own guide shows.
  3. Data location. Embeddings, vector indexes and logs stored in one platform cost time and egress fees to move.
  4. Fine-tuned weights. Models tuned on a hosted service may not be exportable.
  5. Orchestration. Agent frameworks that assume one vendor’s API shape.
  6. Contracts. Committed spend, volume discounts and exclusivity terms.
  7. People. Teams skilled in one stack resist change.

A six-step checklist

1. Put a thin abstraction in front of models

Route all model calls through one internal interface that takes a standard request and returns a standard response. Keep vendor specifics inside adapters. The goal is not to support every feature, only the common ones your product needs.

2. Keep prompts and evaluations in version control

Store prompts as files, with a test set of realistic inputs and expected qualities. An evaluation suite lets you answer “is the new model good enough?” in hours, not weeks. Without it you cannot switch safely, and you cannot tell whether a vendor’s update broke something.

3. Prefer open standards for tools

Where possible, expose your tools and data through open protocols such as the Model Context Protocol, so agents from different providers can use the same connectors. Our glossary entry explains the idea.

4. Own your data layer

Keep source documents, embeddings and logs in storage you control, with documented export. Choose vector databases and formats that you can move, and record the model used to create each embedding because embeddings from different models are not interchangeable.

5. Negotiate contracts for flexibility

Ask about:

  • Committed spend and whether it can be applied across models or services.
  • Data-use terms, retention and deletion.
  • Notice periods for model deprecations.
  • Price protection and exit terms.
  • Support and security commitments.

Marketplace purchasing through an existing cloud account can simplify billing, but check that terms match direct agreements.

6. Run a switching drill

Once a quarter, pick a task and run it on an alternative model. Measure quality, cost and latency. Even if you do not switch, you learn the true cost of switching and gain negotiating leverage.

When lock-in is acceptable

Some dependence is rational. If one model is clearly best for a core task, if a vendor’s integrated tooling saves months, or if a discount outweighs switching costs, accept it, but do so knowingly. Document the decision, the exit path and a trigger for review, such as a price change or a deprecation notice.

Common mistakes

  • Treating a multi-model marketplace as proof of portability.
  • Skipping evaluations, then discovering behavior changes in production.
  • Re-embedding data repeatedly because the embedding model was not recorded.
  • Signing large commitments before measuring usage.
  • Building agents around one vendor’s proprietary features without a fallback.

What to watch next

  • Convergence of tool and agent standards across providers.
  • More models offered through multiple clouds, and how pricing differs by channel.
  • Deprecation schedules, which force migrations on a vendor’s timeline.
  • Regulatory attention to cloud switching and egress fees.
  • Growth of open-weight alternatives that can run in your own environment.

Key takeaways

  • Lock-in hides in prompts, features, data, fine-tunes, orchestration and contracts, not only in the model choice.
  • A thin abstraction layer and an evaluation suite are the highest-return protections.
  • Record which embedding model produced each vector.
  • Negotiate for flexibility and run periodic switching drills.
  • Accept lock-in deliberately, with a documented exit path.

Frequently asked questions

Does a model marketplace mean I am not locked in?

No. A marketplace simplifies access and billing, but prompts, tool formats, data and contracts can still tie you to a provider.

How big should an evaluation set be?

Start with a few dozen realistic cases covering your main tasks and failure modes, then grow it as you find issues in production.

Is multi-cloud always worth it?

Not always. It adds complexity. Many teams get most of the benefit from a model abstraction and portable data, without running every workload on several clouds.