AI coding tool vendor lock-in is what happens when the context your AI assistant has built up about your projects (your decisions, conventions, past fixes and preferences) only lives inside one vendor's tool. The code is portable. What the tool has learned about it is not. So switching tools, or just trying a new one, means teaching it your project again from zero.
Most writing about lock-in looks at pricing and file formats. We think the bigger cost for developers who use Claude Code, Cursor and Codex every day is quieter than that. It's all the time spent re-explaining things you've already explained.
The hidden cost of switching tools: re-explaining your project from zero
Say you spend a Monday afternoon in Claude Code working out why your job queue keeps dropping messages. You decide to drop Redis and use SQLite for the queue, because the app runs on one box and you're tired of managing a second service. You also mention, for the fifth time this month, that this repo uses pnpm and not npm.
On Tuesday you open the same repo in Cursor. Cursor doesn't know about any of that. It suggests npm install, and its first idea for the queue bug is to tune Redis connection pooling. You spend ten minutes catching it up, then do the same again on Thursday when you try Codex on a refactor.
That catch-up costs tokens as well as attention. Every tool has to rebuild the picture, either because you paste notes in or because the agent reads files until it gets its bearings. We measured this on our own store. Loading context for a 10,000-memory store as a full dump takes 1,131,367 tokens. As a ranked briefing it takes 1,325. On LoCoMo, a public long-conversation memory benchmark, our runs kept 97% of the full-conversation score while reading 18% of the tokens. If you want to cut that orientation overhead in your own setup, we wrote up ten practical ways to reduce AI coding agent token costs.
This matters more than it used to because the usage limits are tight. As of October 2026, Anthropic's Claude plans meter Claude Code in five-hour sessions with weekly caps on top. Cursor has billed agent use by usage since mid-2025. OpenAI's Codex limits depend on your ChatGPT plan and also reset in windows. The details change often, so check each vendor's current pricing page. The pattern is the same everywhere, though: tokens spent re-orienting a tool are tokens you can't spend on the actual work.
How each tool's built-in memory works as a soft lock-in
None of these vendors is trying to trap you, and the features are useful. The problem is that each one stores what it learns in its own place and its own shape.
Claude Code reads
CLAUDE.mdfiles at the user, project and directory level, and lets you add to them as you go. Anthropic documents this in its Claude Code memory docs. The files are plain Markdown, but only Claude Code reads them by that name.Cursor uses Project Rules stored as
.mdcfiles under.cursor/rules. Its separate Memories feature lost its management UI in the 2.1 release line (November 2025). Cursor staff told users to export memories into Rules, and later said the feature still works if you ask the agent in chat. If you relied on it, you probably noticed.Codex reads
AGENTS.md, an open convention that several other agents now support as well.
Rules files like these are a good start, and we cover where they fit in our explainer on AI memory layers and long-term project memory. They have two weaknesses, though. You maintain them by hand, so they go stale. And each tool reads its own file, so a decision you make in one session only reaches the others if you remember to copy it across. Leave that for a couple of weeks and you've got three slightly different versions of how your project works.
That's what we mean by soft lock-in. You can leave whenever you like. You just lose some of what you've built up when you do. Being able to export your code doesn't fix that, because the code was never the part you'd lose.
What portable memory needs: open format, local storage, and your own encrypted backup
If memory is going to outlast any one tool, we think it needs three properties.
An open, inspectable format. You should be able to read every memory, fix the wrong ones and delete the ones you don't want, without going through a vendor's interface.
Local storage under your control. Your project history includes architecture decisions, internal service names and sometimes the outline of a security fix. "Where does my memory live?" should have a one-sentence answer.
A backup only you can read. If you work on more than one machine you need sync. Sync shouldn't require handing your history to another company.
That's why we built Open Agentic Brain & Memory (OpenAB). At Open Agentic Brain & Memory (OpenAB), we think memory belongs to the developer, not the tool. So we built one memory that Claude Code, Cursor, Codex, Antigravity and Kilo Code (beta) all share.
Here's how it works. Hooks capture decisions, fixes and preferences from your sessions and tag each one with the project it came from, which OpenAB finds by walking up to the nearest .git. They're stored in a local SQLite database. When a session starts, a start-up hook ranks what's relevant and injects a briefing of at most 2,000 tokens, ready in 84 ms (p50). During a session, tools can recall on demand over MCP with brain_recall, brain_remember and brain_context. Recall across 10,000 memories takes 28 ms (p50).
For sync, memory is age-encrypted and stored as a Release asset in your own private GitHub repo. The key stays in your OS Keychain. There's no account and no server of ours, so a leaked repo or token exposes nothing readable. Only you hold the key, which also means nobody can recover your memory if you lose it. Our guide to self-hosted AI memory privacy and security walks through that trade-off.
Trying a new AI coding tool next month without losing what you've already taught your agents
This is where portable memory pays off day to day. Back to Monday: you decide on SQLite instead of Redis in Claude Code. On Tuesday, Cursor's first briefing already includes that decision and the pnpm preference. If a new agent ships next month and you want to try it on a real task, you connect it to the same memory and it starts with what the others know.
It also makes running two tools side by side much less annoying. A lot of developers we know plan in one tool and do fiddly edits in another. Our guide on running two AI coding agents side by side without losing context covers that workflow.
Memory is project-aware without being walled off. Opening a folder gives you that repo's history first. A map of up to 20 projects goes into the global CLAUDE.md, AGENTS.md and GEMINI.md, and recall can search one project or all of them. At start-up OpenAB also merges in what your other laptops learned, so you get the same briefing on every machine.
How to avoid AI coding tool vendor lock-in
You don't have to use our tool to get most of the benefit. These are the habits we'd recommend either way.
Keep memory in open formats. Prefer Markdown rules files and plain databases you can query yourself over memory you can only see through a vendor's interface.
Keep it local or under your own control. If you sync, sync into storage you own, encrypted with a key you hold.
Use one shared memory across tools. One source of truth beats three rules files drifting apart. A memory layer that every tool reads over hooks and MCP gives you that without the copying.
Check what it actually remembers. Open it every so often, fix wrong entries, pin the important ones. OpenAB's local control panel lets you read, edit, pin or delete every memory, and
brain evalscores recall against your own history.Test a new tool on a real task. Toy demos hide the re-orientation cost. Real work shows it fast.
You can see every supported tool and how to set each one up on the OpenAB connect page.
FAQ: AI coding tool vendor lock-in
Is AI coding tool vendor lock-in real if I can still export my code?
Yes. Your code was always portable. What you lose when you switch is the context: decisions, conventions and fixes the tool learned over weeks. You end up paying for that again in time and tokens.
Do CLAUDE.md and AGENTS.md solve vendor lock-in?
Partly. They're open, plain-text and worth keeping. But you have to keep them up to date by hand, and each tool reads its own file, so they drift apart unless something keeps them in sync.
Can I use Claude Code and Cursor on the same project without re-explaining it?
Yes, if both read from the same memory. With OpenAB, a decision captured in a Claude Code session shows up in Cursor's start-up briefing the next time you open that repo.
Can I bring my existing Claude Code and Cursor history into a new tool?
When you set up OpenAB you can start from your past AI work or start fresh. Whatever you import becomes shared memory, so any connected tool, including one you add later, gets it in its briefing.
Where does Cursor Memories or Claude memory store my data?
Built-in memory features keep data wherever that vendor decides, and the details change between releases. Check each vendor's current docs. With OpenAB, memory lives in a local SQLite file, and the synced copy is an encrypted blob in your own private GitHub repo.
What happens to my memory if I stop using the open-source project?
It stays where it is: a SQLite database on your machine that any SQLite client can open. The code is Apache-2.0, so you can also fork it or keep running your current version. Keep your encryption key safe, because no one else holds a copy.
Switching tools should be cheap
New AI coding tools keep shipping, and trying one should cost you an afternoon, not a month of re-teaching. The simplest fix for AI coding tool vendor lock-in is to keep project memory somewhere you own, in a format you can read, shared across every tool you use. That's what OpenAB is: free, open source and self-hosted, built by Rohith, Chandan and Sushmita.
Top comments (0)