How Locked In Are You to Your AI Assistant?

Ask someone how hard it would be to leave their AI assistant and they’ll usually think about their conversation history. That’s the wrong thing to worry about. Old chats are mostly sentimental; you’ll never read them again.

The lock-in that matters is the stuff you built on top, and it accrues quietly. This post is about assessing that exposure at decision time — before you commit, and while it’s still cheap to shape. It is not a how-to for leaving; it’s the question you ask before you’re in a position to need one.

The four layers, from harmless to expensive

Layer 1: Conversation history (barely counts)

You have a lot of it, you value it more than you should, and losing it costs almost nothing in practice. Every major vendor as of mid-2026 offers some way to get a copy of your data. Treat this layer as solved and stop thinking about it.

Layer 2: Accumulated configuration (starts to hurt)

Custom instructions, saved preferences, project-level context, reference files you re-upload, a memory feature that has learned how you work. Individually trivial; collectively, this is months of tuning that makes the tool feel like yours. Nothing here transfers between vendors — the formats and concepts don’t line up, and nobody is incentivised to make them.

Exposure test: if your account were wiped tomorrow and you started fresh at the same vendor, how long until it felt right again? A day is fine. Three weeks means this layer is doing real work for you, and it is real lock-in.

Layer 3: Integrations and automations (expensive)

Connectors into your mail, files, or ticketing system. Scripts and internal tools calling one vendor’s API. Automations triggered by the assistant or feeding it. Team workflows that assume a specific product’s behaviour.

This layer is expensive because it’s other people’s software pointed at one vendor’s shape. Prompts tuned against one model family don’t transfer cleanly; output formats you parse can differ; features you depend on may have no equivalent elsewhere. This is where a switch stops being an afternoon and becomes a project.

Layer 4: Organisational habit (the deepest)

Thirty people who know one product’s quirks. Documented processes that name it. A shared prompt library written in its idiom. Training material. This is the layer companies underestimate most, because it doesn’t appear on any invoice or in any architecture diagram — and it’s the reason organisations stay on tools they’ve stopped preferring.

Why this is worth thinking about now

Two reasons, and neither is that vendors are villains.

Prices and terms change. A subscription price rises, a free tier tightens, a data-handling default shifts, a feature you relied on moves to a higher tier. Your leverage in that moment is precisely your ability to leave. If you have none, you accept whatever the new terms are.

Models get deprecated. With a hosted closed-weight model you don’t control which version you’re using. A vendor can retire the version your prompts were tuned against, and a “minor” upgrade can change output enough to break something downstream. This isn’t hypothetical — anyone who has had a carefully tuned prompt quietly stop working knows the feeling. Portable weights are the only real answer to it; see what are open-weight models.

Who should actually care

Being honest about this, because lock-in anxiety is easy to oversell:

If you’re one person using a chat app: you are not locked in and you should stop worrying. Layers 3 and 4 don’t apply to you. Layer 2 costs you a weekend of re-tuning at most. Pick the tool you like best and enjoy it.

If you write scripts or small tools against an API: mild exposure. Worth ten minutes of thought (see below), not a strategy.

If you’re building a product on one vendor’s model: serious exposure, and it should be an explicit part of your architecture decisions. Your pricing, your margins, and your product behaviour all sit on someone else’s roadmap.

If you’re choosing for an organisation: serious exposure, mostly in layers 3 and 4. See does it matter which AI assistant your team uses.

Cheap habits that keep your options open

None of these require choosing a worse tool. They’re all near-free, and they’re the whole point of thinking about this early.

• Keep your prompts and standard instructions in your own documents. A plain text file or repo that is the source of truth, mirrored into whatever tool you use. This single habit converts layer 2 from lock-in into a portable asset, and it makes any future comparison trivially easy to run.
• Keep reference material in your own storage, not only inside a vendor’s project feature.
• Put a thin seam between your code and the vendor’s API. One module that everything calls, rather than the vendor’s SDK sprinkled across your codebase. Standard engineering hygiene, and it’s the difference between changing one file and grepping a codebase.
• Don’t parse vendor-specific output shapes deep inside business logic if you can avoid it.
• Prefer shorter commitments when buying. Annual discounts are real; so is being stuck for a year in a market that moves quarterly.
• Re-run a small comparison periodically. Not to switch — to know your alternative. Twenty minutes with your own three real tasks tells you whether you’re staying by choice or by inertia. That’s the difference between a preference and a trap.
• Keep one non-primary tool warm. A free tier at a second vendor, used occasionally. It costs nothing and it keeps your knowledge current.

Where lock-in is genuinely lowest

If minimising dependence is a priority rather than an afterthought, the ranking as of mid-2026 runs roughly:

1. A model you run yourself — no vendor at all, and the exact version persists as long as you keep the file. Costs you capability and convenience; see can I run a ChatGPT alternative locally.
2. An open-weight model via a hosted provider — many providers serve the same weights, so switching is an endpoint change. Often the best balance available.
3. A closed hosted model behind your own abstraction layer — you keep the frontier capability and reduce the switching cost to a real but bounded piece of work.
4. A closed hosted model integrated deeply and directly — maximum capability, maximum dependence.

Most people and most companies should be somewhere in the middle two, and the reason is not ideology: it’s that positions 2 and 3 cost almost nothing extra to adopt at the start, and a great deal to retrofit later.

For the wider decision about which tool to pick at all, start from our framework.