Every AI product team eventually asks a nervous question: what if we build this on one provider and then regret it?
That question is healthy. The unhealthy move is answering it with ideology.
Some teams become romantics about one lab and call it focus. Some teams become allergic to commitment and build a giant abstraction layer before they even have product-market fit. Both are ways of avoiding judgment. The useful middle is simpler: make bets that are strong enough to ship, but reversible enough to survive vendor movement.
Two manual chapters matter most here: Cost & Latency as Product Constraints and Building With AI vs. Building AI Products. The first reminds you that provider choice changes your economics immediately. The second reminds you that the right lock-in posture depends on what kind of company you actually are. If AI is your product, your supplier strategy is existential. If AI is a feature inside a larger product, it should usually be treated more like a commodity input.
Start there.
If you are building with AI, not building an AI product, your default posture should be pragmatic and lightly hedged. You probably do not need deep provider-specific dependence unless a capability is uniquely valuable to your workflow. Your user is not paying for your vendor allegiance. Your user is paying for the feature to work.
If you are building an AI product, the seam matters much more. Your provider is not a nice vendor in the background. It is a supplier whose pricing, policies, outages, and product roadmap can hit your core value proposition directly. In that world, lock-in is not merely a technical concern. It is strategy, margin, and resilience wrapped together.
There is capability dependence: only one provider currently clears your bar on the hard cases.
There is economic dependence: only one provider currently makes the feature financially viable.
There is workflow dependence: your product or internal tooling is shaped tightly around one provider's specific behaviors, tools, or interface.
These are different risks. Treating them as one vague category called "lock-in" produces fuzzy decisions.
Capability dependence can be rational. If one model is materially better for your hardest and most valuable use case, use it. But name the dependence honestly and decide what you need in reserve if the gap narrows or the vendor changes terms.
Economic dependence is more dangerous. If your product only works at one vendor's current price, you are effectively renting your margin from that vendor. That can still be an acceptable choice, but it should trigger urgency around eval-driven fallback options.
Workflow dependence is the sneakiest. Teams often think they are provider-flexible because the API call is abstracted, while in reality the prompt shape, tool semantics, output assumptions, and internal review flows are all tailored tightly to one model's style. Swap the vendor and quality quietly falls apart. The team had a transport abstraction, not a product abstraction.
This is where fallback chains become useful.
A fallback chain is simply a pre-decided order of operations for what the system does when the primary model is too expensive, too slow, unavailable, or below confidence. The point is not to feel architecturally sophisticated. The point is to remove panic from moments when the primary path fails.
A sane fallback chain often looks like this.
For routine traffic, use the cheapest model that clears the eval bar.
For hard cases or low-confidence cases, escalate to a stronger model.
If the stronger model is unavailable or cost-capped, degrade gracefully: shorter context, narrower task, ask a clarification question, or route to human review.
If a full vendor outage occurs, fall back to a secondary provider that has already been run against the eval set on the critical categories.
That last sentence is where many teams cheat. They say they have a fallback provider because another API key exists in a config file. That is not a fallback. A fallback exists only when the secondary path has been evaluated on the tasks that matter. Otherwise you have a fantasy failover path.
Anthropic's Claude app is instructive because it shows how much product value is created in the wrapper rather than the raw model call. This is exactly why fallback needs more than API-level redundancy. The system behavior, memory assumptions, and refusal boundaries all matter. A fallback chain has to preserve enough of the product contract that users do not experience chaos when the provider changes.
At the same time, do not overbuild this too early. A common mistake among anxious technical teams is building full multi-provider routing infrastructure before they have nailed a single compelling feature. That is complexity bought in advance.
The better question is: what kind of reversibility does the current stage deserve?
At prototype stage, reversibility means keeping the prompt and evaluation assets clean enough that you can test another provider in a week.
At pilot stage, reversibility means a secondary provider has been checked on the critical path and you know the economics of switching.
At scale, reversibility may justify a proper provider abstraction, traffic routing, and spend or latency circuit breakers.
But most teams should not jump straight to stage three. Reversibility should scale with exposure.
Cursor's coding product is a good example of making a committed bet without pretending it is irreversible. Cursor clearly benefited from deep alignment with frontier model behavior. That focus helped the product move faster. But the product also lives in a market where model routing, provider changes, and specialized internal models are part of the long-term strategy. The lesson is not "never commit deeply." The lesson is "commit deeply where it creates product value, while keeping the organizational muscle to re-evaluate."
The opposite lesson comes from Harvey's legal AI. In a high-stakes domain, reversible bets are not optional. If the domain requires auditability, predictable outputs, enterprise trust, and negotiated controls, the provider strategy has to match that exposure. You cannot explain to a law firm that a core workflow degraded because your entire stack was emotionally attached to one model release.
Another useful distinction: reversible bets are not the same as indecisive bets.
An indecisive team keeps the product vague so it can swap vendors painlessly.
A disciplined team makes the product specific, chooses the best current path, and preserves enough seam around that path that it is not trapped if the world changes.
That is the posture you want.
Four habits make it real.
First, keep the evaluation asset provider-neutral even when the prompt is provider-specific. Your golden set should test the user job, not your loyalty.
Second, track vendor-specific assumptions explicitly. If a feature depends on a particular tool-calling behavior, context length, or safety policy, write that down. Hidden dependencies are what make migration unexpectedly painful.
Third, separate "primary for quality" from "primary for economics." Naming the split helps you decide where routing or fallback actually matters.
Fourth, decide in advance what would trigger a serious re-evaluation. A price increase? A new model from a competitor that clears the bar at half the cost? An outage pattern? A procurement issue in enterprise deals? Without pre-commitment, teams keep absorbing bad conditions because the switching conversation always feels inconvenient.
This is also where product writing matters. The best teams create a short provider memo that names why the current primary exists, what the known dependencies are, what the secondary option is, and what the re-evaluation triggers will be. It sounds lightweight because it should be. Most AI provider strategy does not need a committee. It needs a clear document and a team willing to look at it honestly every quarter.
The final mindset shift is simple: lock-in is not a moral failure. Unexamined lock-in is.
You will be locked in somewhere. To a provider, to a product shape, to a domain workflow, to your own eval history. The job is not to eliminate dependence. The job is to choose the dependencies that create product value and keep escape paths alive where the risk justifies them.
If you do that well, vendor strategy stops being abstract anxiety and becomes what it should have been all along: part of product strategy.
Rules from this lesson
- Separate capability dependence, economic dependence, and workflow dependence. "Lock-in" is too vague to guide good decisions.
- A fallback provider counts only if it has been run against the eval set on the critical categories. An extra API key is not resilience.
- Reversibility should scale with exposure. Keep prototype seams light, pilot seams tested, and production seams operational.
- Do not overbuild multi-provider complexity before you have a compelling feature. Hedge proportionally, not theatrically.
- Lock-in is acceptable when it creates product value and the re-evaluation triggers are named in advance.