It's Tuesday morning and you open an email from the AI coding tool your team adopted last year. The plan you're on is changing. The usage your team runs every week now costs a lot more, or hits a rate limit by Wednesday, or the new data terms no longer cover your client's code the way your contract assumed.
You do the math on switching and it's ugly. Not because the tool itself is hard to replace, but because of everything you built around it: the custom commands, the rules files, the review step in CI, the onboarding doc that tells new hires how to prompt it. All of it speaks one vendor's dialect.
That's the moment a lot of teams realize that picking an AI coding tool stopped being a productivity decision a while ago. It's a risk decision now.
Your coding tool is infrastructure now
A year or two ago, an AI assistant was something one engineer tried on a side branch. If it disappeared, you lost some autocomplete.
Today it does real work. It writes first drafts of migrations, generates tests, reviews pull requests, and answers questions about the codebase that used to go to the one person who remembers why that module exists. Your team's habits have formed around it.
Anything your team depends on that much deserves the questions you'd ask about a database or a cloud provider. What happens if the price doubles? What happens if the terms change? How long would it take you to replace it?
For most closed tools, the answer to that last one is "longer than we'd like."
What actually locks you in
Switching tools is the easy part: installing a new one takes an afternoon. The hard part is everything tied to it, and that lives in three places:
- The model. Many closed tools are tied to one provider's models, or route through their own backend. When that provider changes prices, limits or quality, you get the change whether you want it or not.
- The terms. Data retention and training policies can change with a new plan or a new owner. If you work on code you don't own, like a client's, that isn't a footnote.
- Your workflow artifacts. Prompt libraries, project rules, custom agents and integrations often live in a format only that tool reads. That's where most of the switching cost hides.
To be clear, the vendor isn't the villain here. Pricing changes because running models is expensive and business models are still settling. But your team's way of working still depends on decisions you don't get a vote in.
What an open-source, model-agnostic agent changes
This is where tools like OpenCode come in. OpenCode is an open-source coding agent that runs in your terminal and works with many model providers, including models you host yourself.
It doesn't promise to be more polished than the closed tools. It promises that you control the stack. In practice, that gives you a few concrete options you didn't have before:
- Swap the model without swapping the tool. If one provider raises prices or a better model ships somewhere else, you change a config line. Your commands and habits stay put.
- Keep sensitive code local. For a repo that can't leave your network, you can point the agent at a self-hosted model and keep the same workflow.
- Read the code. When the agent has shell access to your machine, being able to see exactly what it does is a real security property.
- Fork if the project goes somewhere you don't like. Open-source projects change direction too. The difference is that the last good version stays available to you.
Your exit cost drops sharply, and that limits how much a vendor's next email can hurt you.
What that freedom costs you
If you're weighing this for your team, it helps to know what you're signing up for.
More setup. You choose the model, manage API keys, set up configuration, and decide how it fits your security policies. A closed tool makes most of those decisions for you.
Rougher edges. Polished onboarding, a smooth IDE experience and a consistent UI are where commercial tools spend their money. Expect more moments of "that's odd" and more trips to the issue tracker.
No support line. When something breaks, you have docs, a community and the source code. For some teams that's plenty. For others, it means the person who set it up becomes the support line.
You still pay for models. Model-agnostic doesn't mean free. You trade one bill for another, and you now own the job of comparing providers.
You'll also notice that the same agent feels very different on different models, which is useful information but also more work.
That's real friction, and it doesn't go away in a week.
When it's worth paying
The trade makes the most sense when one of these is true for you:
- You've already been burned by a surprise pricing or policy change, and you remember how long the scramble took.
- You work on code with strict data rules: client repos, regulated industries, anything that shouldn't leave your network.
- Your team uses AI deeply enough that switching tools would mean rewriting real workflows, not just reinstalling an extension.
- You have at least one engineer who enjoys owning tooling and has time to do it.
It makes less sense if you're a small team that's happy with your current tool, your code isn't sensitive, and the switching cost is an afternoon. In that case, the polish is probably worth more to you than the exit option.
A low-cost way to lower your risk this month
You don't have to migrate your team to find out where you stand. Three small steps will tell you most of what you need:
- Write down your exit cost. List what you'd have to rebuild if your current tool doubled its price tomorrow. If the list is short, you're fine. If it's long, that's your risk, in writing.
- Keep your instructions portable. Put project rules and conventions in plain Markdown files in the repo, rather than in a format only one tool reads. Most agents, open or closed, can read them.
- Run one real task through an open-source agent. Pick something from your actual backlog, point the agent at the model you already use, and compare the result. That tells you how much friction you'd really face, before it's urgent.
If you're still comparing the closed tools themselves, we wrote up an engineer's take on Claude Code vs Cursor. Whichever one you pick, it's worth knowing what replacing it would cost before the next pricing email arrives.
