Vendor lock-in (AI)
Dependency on an AI provider to the point where switching tools or models carries a real migration cost: restricted subscriptions, non-portable configs, frozen workflows.
Definition
Vendor lock-in applied to AI tooling covers two distinct layers. The first: model/subscription lock-in — a first-party subscription (Claude Code on the Anthropic subscription, for example) that restricts its use to the same vendor's tools, preventing it from being reused as a provider inside a third-party agent. The second: configuration lock-in — the agents, skills, hooks and custom commands built for one tool (`.claude/`, `.opencode/`) don't carry over as-is to another. The two compound: switching tools often means rebuilding both model access and workflow configuration.
postcursors perspective
Lock-in isn't disqualifying on its own. A well-integrated first-party tool can be worth the trade-off if the integration pays back more than it costs to migrate away from. The mistake isn't choosing a locked-in tool — it's never maintaining a tested exit path, and discovering the cost of lock-in only when the vendor changes the rules.
In practice
The concrete case: Anthropic restricted the use of the Claude Code subscription inside third-party tools, breaking overnight an OpenCode workflow that consumed that subscription as a provider. No fallback was in place, so the migration happened under pressure. The slower case: a `.claude/` setup with specialized agents, skills and hooks doesn't port to OpenCode or Kilo Code — it has to be rebuilt, format by format.
Common misconceptions
- ✗ Treating lock-in as an absolute argument against a tool, without ever pricing the real migration cost against what the tool delivers day to day
- ✗ Confusing model lock-in (provider access) with configuration lock-in (agents/skills/hooks) — the two compound but are resolved through different means