Lock-in is the cost of leaving. For LLM frameworks specifically, it is the cost you would pay to remove the framework from your codebase and replace it with direct calls to the provider SDKs (OpenAI's, Anthropic's, Google's).
Four costs are real framework lock-in.
**Type coupling.** Your application code passes around the framework's types. `ChatPromptTemplate`, `Runnable`, `Document`, `QueryEngine`. Removing the framework means rewriting every function signature that touches one of these types.
**Prompt portability.** Prompts in the framework are expressed in its templating system (`ChatPromptTemplate.from_messages`), with its parsers (`StructuredOutputParser`), composed with its operators. Lifting them to a raw SDK call means re-authoring the prompt code, not just copy-pasting strings.
**Observability vendor coupling.** Tools like LangSmith hook into the framework's callback surface. If your tracing depends on LangSmith, you depend on LangChain, and migrating away costs both.
**Feature lag.** New provider features (prompt caching, structured outputs, computer use) appear in the framework weeks after they ship in the vendor SDK. You either wait or escape-hatch.
Two distractors are provider or runtime concerns, not framework concerns:
- **GPU vendor coupling** is a hardware decision; the same Nvidia vs AMD choice exists with or without LangChain.
- **Token-pricing lock-in** is between you and the provider; the framework does not negotiate rates on your behalf.
Framework lock-in is the cost you would pay specifically to remove the framework, not the cost of being on its underlying providers or hardware. Four costs map onto the framework layer.
**Type coupling.** Application code carries the framework's types through its function signatures and return types. A function that takes `Runnable` and returns `AIMessage` cannot be migrated to raw SDK without changing its contract; every caller has to update too. The deeper the framework reaches into your business logic, the larger the surface area to rewrite.
**Prompt portability.** Prompts authored as framework primitives. `ChatPromptTemplate.from_messages([...])`, `StructuredOutputParser`, `RunnablePassthrough`-composed pre-processing. Do not move to raw SDK calls as a string copy. The templating, parsing, and composition logic has to be re-implemented. The longer you've been on the framework, the more of this you've built.
**Observability vendor coupling.** Proprietary observability stacks like LangSmith hook the framework's callback surface and require it to function. Replacing LangChain means also replacing LangSmith. Or instrumenting against OpenTelemetry GenAI conventions from the start to keep observability portable.
**Feature lag.** New provider features land in the vendor SDK first and reach the framework's wrapper 4-8 weeks later. During that window you either wait or use an escape hatch that bypasses the framework's abstraction (defeating the portability argument).
The distractors fail the 'would this cost still exist if I ripped the framework out?' test. GPU vendor choice and token-rate negotiation are provider/runtime decisions that survive any framework swap; they are not lock-in costs of the framework itself.
Quick reference
TL;DR
Framework lock-in costs are the taxes you only pay because you adopted the framework. Type coupling, prompt portability, observability hooks, feature lag; GPU choice and token pricing are not framework concerns.
Think of moving into a furnished apartment. The lock-in costs are the things you cannot take with you when you leave: built-in shelving, the alarm system wired to one company, the smart switches that only work with that brand's app. The things you can take with you, your couch, your rent, the neighbourhood you live in, were never the apartment's fault to begin with. When you pick a framework, the same test applies: list the costs that would vanish if you swapped the framework for raw SDK calls. Those are the lock-in costs.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Greenfield prototypes where ejection cost is not yet a concern Lock-in costs grow with codebase size; for a 200-line MVP, the framework's productivity wins dominate the eventual ejection cost
Single-provider workloads where the 'portability' argument never mattered If you will only ever run on Anthropic, the feature-lag tax against multi-provider portability is irrelevant to your situation
Teams without budget for hexagonal-architecture discipline The mitigations (adapter layers, OTel instrumentation) require sustained discipline; without it, the lock-in costs accumulate regardless
Workloads that genuinely need the framework's unique primitives (e.g. LangGraph's checkpointer) Some frameworks earn their lock-in by providing capabilities that are expensive to build from scratch; the cost of leaving calculation has to weigh both sides
Quick scan · 2–4 min
Everything important, quickly.
5 minutes: the ejection-cost test, the four real costs, the two wrong-layer distractors, and the mitigation for each real cost.
Side-by-side
Cost
Framework lock-in?
Why
Type coupling
Yes
Framework types in function signatures must be rewritten on exit
Prompt portability
Yes
Framework templating + parsers do not move to raw SDK as-is
Observability hooks
Yes
Proprietary tracers (LangSmith) require the framework
Feature lag
Yes
Framework wrappers ship weeks after provider SDKs
GPU vendor
No
Hardware decision independent of any LLM framework
Token pricing
No
Contract between you and the provider, framework is uninvolved
Real-world examples
Real products, models, and research that use this idea.
1LangSmith's tight coupling to LangChain is the canonical observability-coupling example; teams migrating off LangChain have to migrate off LangSmith too.
2OpenAI's structured-outputs feature with strict schemas landed in the OpenAI SDK in mid-2024 and reached LangChain's `with_structured_output` weeks later. A concrete feature-lag instance.
3Production teams running LangChain-OpenTelemetry instrumentation (rather than LangSmith) keep observability portable across Langfuse, Phoenix, Datadog, and Honeycomb.
4Companies with multi thousand line LCEL pipelines who tried to migrate to raw SDKs after the LangChain v0.1 packaging churn report multi-month rewrite efforts driven mostly by type-coupling and prompt-portability costs.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you design an application to minimise type coupling to a chosen framework?
Sign in or go Pro to see the approach for this follow-up.
QWhat instrumentation strategy keeps observability portable across LangChain, LlamaIndex, and raw SDK calls?
Sign in or go Pro to see the approach for this follow-up.
QHow do you quantify feature-lag tax for an executive audit?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Conflating framework lock-in with provider lock-in. Confusing the cost of leaving LangChain with the cost of leaving OpenAI, when they are independent decisions.