A CTO I know recently described a conversation with their board: “We’ve built our entire competitive advantage on a foundation model API. What happens when your vendor changes their pricing? What happens when they change their terms? What happens when they decide to compete with us directly?”

The board had no answers. Not because they’re unprepared. But because nobody had modeled the scenario. It felt theoretical, or distant, or like someone else’s problem.

It’s not. It’s the central architecture problem facing enterprises right now, and most companies haven’t thought through the implications.

The Vendor Lock-in Is Structural, Not Accidental

Let’s be precise about what’s happened in the last 18 months. Foundation models have become genuinely useful, genuinely reliable, and genuinely easy to integrate into business systems. A team of three engineers can build a production system that was impossible to build in 2022.

That’s the good news.

The dependency is also structural, not accidental. You’re not using a foundation model as one option among five. You’re building on top of it because:

1. The capability is native to the model. You can’t replicate this behavior with a smaller model or open-source alternative because the few-shot reasoning, the instruction-following, the broad knowledge cutoff—these are unique to models of this scale.

2. Your domain adaptations are optimized for that specific model. You’ve tuned prompts for its strengths. You’ve built workflows that depend on its specific output format. You’ve designed your architecture around its API constraints. Moving would require rearchitecting.

3. Your team has built muscle memory. Your engineers think in terms of tokens. Your product managers understand the API’s quirks. Your operations team has learned how to handle the cost profile. There’s switching cost beyond the code.

When you’ve integrated this deeply, it stops being “we can swap vendors if we need to” and becomes “this vendor is our foundation.”

The question that should terrify you isn’t hypothetical: What’s your actual downside if the terms change?

What “Terms Change” Actually Looks Like

Let me name some scenarios that have already happened:

A foundation model provider raised pricing on their flagship API, and companies that had modeled economics around older versions had to reprice their products or absorb margin compression.

A foundation model provider changed their API rate limits, and companies hit unexpected bottlenecks in their production systems.

A foundation model provider changed their token-counting methodology, and billing shifted for systems that hadn’t anticipated the change.

A foundation model provider started offering cheaper models with similar capabilities, and companies that had built competitive advantages on the assumption of exclusive access to high-quality reasoning were suddenly competing on cost instead.

A foundation model provider changed their pricing on advanced context window features, and companies had to rebuild systems they’d optimized for that specific cost structure.

The pattern is consistent: these aren’t conspiracy theories or paranoia. These are normal business decisions from vendors optimizing for revenue and managing demand. And every time they happen, they force expensive recalibration on dependent companies.

But the scenario that should worry you more is the one that hasn’t happened yet: what if your foundation model provider decides to build a competing product?

The Unspoken Competitive Exposure

Here’s the asymmetry that matters: You’re optimizing your systems on their infrastructure. Your customer relationships, your domain expertise, your operational knowledge—these all live on top of their API.

They see your usage patterns. They see what you’re building. They understand your market. They have the infrastructure. They have the customer relationships.

If they decide your market is valuable, they can build a competing product faster, cheaper, and with built-in advantages (integration with their foundation model, direct access to their API, no external dependencies, direct customer contact for switching). You’ve essentially market-tested the opportunity for them.

This isn’t hypothetical either. It’s happened in cloud computing (major cloud providers started with foundational services but moved up into competitive applications). It’s happened in search (dominant platforms built ad networks, then started competing with the services that were built on top of search traffic). It’s the normal trajectory of platform companies.

The difference here is that the switching costs work in the vendor’s favor. If you’ve built an integration layer for one vendor’s API, moving to another foundation model provider isn’t just an engineering project. It’s a rebuild. They know this. You should price this risk into your strategy.

What Most Companies Are Actually Doing (And Why It’s Insufficient)

I’ve seen three patterns in how enterprises are thinking about this.

The Hedging Approach: “We’ll use multiple foundation models.” This reduces the risk that any single vendor’s downtime breaks your system. It doesn’t reduce dependency. You’re now dependent on multiple vendors, each of whom has independent incentive to compete with you or change their terms. It also increases operational complexity and cost. You’re not building redundancy; you’re building technical debt.

The Wait-and-See Approach: “We’re starting with one foundation model, and we’ll re-evaluate in a year.” This is rational caution. It’s also how you end up with deep integration by the time you realize you need an alternative. Year-one projects become standard. Dependencies calcify. By the time you re-evaluate, your systems have dependencies you forgot you had.

The Open-Source Alternative Approach: “We’ll train or fine-tune our own models.” This is intellectually satisfying and sometimes necessary. But most enterprises dramatically underestimate the cost. Training a capable foundation model requires infrastructure, talent, and capital that’s only cost-effective if you can amortize it across many applications or many customers. For a single product or department, it’s usually more expensive than staying dependent.

None of these approaches actually solves the dependency problem. They just mask it differently.

What Changes When You Design for Portability

The companies that are handling this well have made a structural decision: they’re building abstraction layers.

Instead of writing code that assumes a specific foundation model’s API response format, they write code against an abstraction that any foundation model interface could satisfy. It’s more code. It’s slightly less performant. It’s definitely more complex in the short term.

But it has one critical property: if the economics of your primary model change, or if the capabilities diverge, or if a better alternative emerges, you can actually migrate. It’s not effortless. But it’s possible without rebuilding your product.

This requires:

1. An abstraction layer at the application boundary that decouples your code from specific model APIs.

2. A cost model that includes the switching overhead in your unit economics. If you can only switch at 40% cost premium, that’s your real cost baseline, not the current API pricing.

3. A technical strategy that explicitly plans for model rotation. Not “if” but “when.” Assume you’ll need to switch models at least once over the product’s lifetime.

4. Monitoring around model performance that’s independent of vendor claims. You need to know when a model’s behavior changes, not when the vendor announces it.

This isn’t about paranoia. It’s about building businesses that can adapt when the infrastructure under them changes. Platform dependencies are real, and they’re not unique to foundation models. But foundation models are new enough that most enterprises haven’t yet built the organizational practices to manage them.

The Conversation You Should Be Having Now

The question isn’t “should we be dependent on a foundation model?” You should be. They’re better at many tasks than anything you can build or buy.

The question is: “What’s our dependency management strategy?”

That’s a conversation between your CTO (who owns the architecture), your CFO (who owns the total cost), your product head (who owns customer impact of changes), and your board (who owns risk). It’s not primarily a technical conversation. It’s a strategy conversation.

The companies that will compound value from AI over the next five years won’t be the ones that built the fastest integration in 2024. They’ll be the ones that built it in a way they can still change in 2026.