LLM lock-in: what you'd have to rebuild to leave

Separate a model swap from a context migration, test what can leave, and estimate the future work before you commit.

“We're not locked in. We can swap the model.” That sentence shows up in a lot of architecture reviews, and it's often true as far as it goes. Changing the model endpoint can look like one line of configuration.

But an agent isn't only a model call. It's source content, an embedding model, chunks, a vector index, permissions, prompts, an evaluation set, and an audit trail. LLM lock-in is whatever of that you couldn't move, retest, or re-prove on a deadline. You find it by listing the artifacts and testing each exit, not by checking whether the endpoint is swappable.

Test the assumption that the model is cheap to change and the context is expensive. Your exit ledger should show which is harder to move, and what evidence would change that judgment.

Two exits that get confused for one

Changing the model and moving the context are separate decisions. They touch different artifacts, and they fail in different ways.

Changing the generator model means a different large language model (LLM) writes the answers. If your embedding model and index stay the same, you don't have to re-embed anything. The retrieval layer keeps returning the same chunks. What changes is how the new model reads them, follows your prompts, and calls your tools.

Moving the context means changing where retrieval lives or how it's built. Switch the embedding model, and every stored vector has to be regenerated, because vectors from different embedding models aren't comparable. Leave a hosted retrieval store, and you need its contents in a form you can rebuild from. Permissions, provenance, and logs have to come along intact.

Keeping those apart changes the estimate. Include three costs on the model side:

• Behavioral drift. A compatible API isn't equivalent behavior. Prompts tuned to one model may not transfer, and tool-call formats differ.
• Mid-conversation handoffs. Raad Khraishi and colleagues tested model handoffs in a March 2026 preprint that hasn't been peer-reviewed. They report “statistically significant, directional effects”, and some switches helped rather than hurt. The practical read: test your own multi-turn flows, don't assume.
• Cache benefits. Prompt caching generally reuses work for a repeated prompt prefix on a given model. A switch can lose some of that benefit until reuse builds again. How much depends on your architecture and traffic.

None of those require touching your index. All of them require a retest.

The opposing hypothesis: when the model is the hard part

“Model cheap, context expensive” is a hypothesis for you to test, not a rule. Plenty of systems run the other way.

Say your team fine-tuned a hosted model on your support history, and the provider doesn't let you export the weights. Your prompts lean on one provider's structured-output and hosted-tool features. Meanwhile, your documents live in your own stores, your embedding model is open and self-hosted, and your index is a standard database you run.

Here the context moves in an afternoon. The model is the trap.

Tool interfaces can tip the balance too. DevRev's Enterprise-Bench reports lower accuracy when synthetic enterprise tasks move from curated tools to realistic API surfaces. It's a DevRev-authored benchmark, not proof about your workload. It's a reason to put the tool layer on your list, not to assume where the cost sits.

So don't open the review with the conclusion. Open it with a ledger.

The exit ledger: what moves, what fails, what's unverified

Meridian Logistics is a fictional company built for this guide. Its internal support agent answers shipping-policy and systems-access questions for staff. It runs on one hosted generator model, uses the same provider's embedding model, and stores vectors in that provider's hosted retrieval store. A third-party gateway sits in front, holding access policies and request logs.

The platform owner asked two questions of every artifact: what could we actually get out, and could we rebuild from it? Each row records an illustrative check, the result, and who acts next.

All values are fictional and illustrative. They aren't vendor behaviors, prices, or test results.

The model endpoint isn't the only exit to check. And the hardest row isn't the model or the index. It's the gateway Meridian bought to stay flexible.

Price the future work, not the past

With the ledger done, Meridian filled in two columns. Each one is the work it would take from today to complete that exit and trust the result.

The estimate rule: count only future work.

The year Meridian spent tuning its index isn't on it. That cost is spent whether they stay or leave, so it isn't money they'd save by staying.

Ongoing run costs belong elsewhere too. If you need that view, the practice of keeping day-to-day agent spend accountable covers it.

Fictional estimates for illustration only.

For Meridian, the hypothesis held: the context move cost more. But the sheet also showed what the estimate couldn't yet include. The context column rests on an index export nobody has tested. Until that check comes back, the honest figure is “at least 30 person-days.”

Ownership isn't the same as a usable export

Contract language is where many teams stop checking. Owning your data and being able to rebuild from it are different things.

A provider can confirm you own your inputs and outputs. That doesn't tell you whether a hosted index exports with metadata, or whether conversation state comes with it. It doesn't tell you whether permissions survive the trip. Test the export, don't infer it from the ownership clause.

Retention, training, and residency terms need the same care. They're usually set per product, per endpoint, and per contract edition, not once per provider.

OpenAI's API data-controls page describes retention behavior that varies by endpoint. Endpoints and capabilities ineligible for Zero Data Retention may still store application state, even when it's enabled. Check the terms for the exact products you use, under your agreement.

The gateway that was supposed to keep you free

Gateways and orchestration layers are a common answer to lock-in. AvePoint's guidance argues for governing every agent through one central layer, so security teams see each one regardless of model. Kai Waehner writes: “The abstraction layer you build to manage all of this becomes a dependency in its own right, with its own lock-in…”

Both points hold. Centralizing governance is a design choice, not a requirement, and it has a cost. If you centralize, put that layer on the ledger like any other artifact:

• Can you export access policies as rules, not screenshots?
• Do the logs include tool calls and the identity that made them?
• Could you run the same policies somewhere else and get the same decisions?

Meridian's gateway failed the first question. That's the kind of finding that should change a renewal, not wait for an incident.

Meridian's posture decision

The review ended with a bounded statement the team could defend, not a claim to be lock-in-free.

• What they can say now: “We can change the generator model for single-turn policy lookups after one eval run and a grader check.”
• What they can't say yet: “We can leave the retrieval store or the gateway.”
• Hold: No model swap for multi-turn access requests until the platform owner reviews drift on those flows.
• Next actions: The retrieval lead runs the 50-document test export. The security owner runs the permission check on the rebuilt sample. Procurement makes a policy export a renewal condition.
• Acceptance: The posture upgrades only when the export rebuilds with versions, provenance, and permissions intact. If it doesn't, the store stays listed as a lock-in risk with an owner.

If the decision needs a budget, the exit estimate fits into a funding memo Finance can approve. Remaining contractual obligations belong in that exit math too.

Put the exit cost into the decision

The ledger works on any agent platform, including one you're evaluating now. If you're looking at Computer, by DevRev, ask the questions you'd ask of Meridian's stack.

What can you export from Computer Memory, and in what format? Do permissions and provenance come with it? What changes, and what has to be retested, if the underlying model changes?

The answers belong in your ledger as checks with owners, not as assurances. DevRev has made the case that memory, not the model, is becoming the advantage in enterprise AI. If that's right, the memory is exactly what you should be able to inspect and move.

Your ledger may confirm the hypothesis, or it may show the model is your hardest exit. Before you sign, record that exit, its owner, and the evidence still missing.

Score that exit risk alongside the other criteria your evaluation committee weighs.