When Your Dev Tools Get Acquired: A Portability Playbook

In the space of one week, two of the pieces most builders treat as neutral infrastructure changed owners. SpaceX officially closed its $60B acquisition of Cursor, with the team saying it is joining SpaceXAI to work on Grok. Days earlier, reports put Stripe in line to acquire the AI gateway OpenRouter for north of $7 billion. The editor a lot of us live in and the router a lot of us shop tokens through are now inside companies with much bigger games to play.

Nothing breaks tomorrow. Acquisitions rot slowly, and most of the anxiety threads are running ahead of any actual change. But the cost of being locked in only becomes visible on the day you want out, and by then you are negotiating from zero leverage. This is a practical guide to auditing your stack now, while switching is still boring, so that any future acquisition, price change or deprecation is a config edit rather than a rewrite.

Why acquisitions change the product, eventually

An independent tool has one job: keep you happy enough to keep paying. Inside a larger company, that tool acquires a second job, which is to serve the parent's strategy. Those two jobs agree right up until they do not.

The mechanism is rarely dramatic. Nobody sends an email announcing that your favorite feature is being deprioritized. Instead the default model changes. The free tier gets a new limit. The roadmap shifts toward integrations with the parent's other products. Support for a competitor's API quietly stops being tested. A rocket company that owns an editor has an obvious interest in that editor recommending its own model. A payments company that owns a gateway has an obvious interest in owning the billing relationship for every token you buy.

None of that is villainy, it is just incentives. Your job is not to predict which way they break. Your job is to make sure it does not matter much either way.

The portability audit: five questions

Set aside an hour. Open your project and answer these honestly.

1. If your editor disappeared tomorrow, how much of your workflow disappears with it? Count the prompts, rules, snippets and agent configurations that exist only inside that product's UI.
2. If your model gateway doubled its fee, how long would switching take? If the answer is "I would have to find every place we call it", you already know your problem.
3. Do you know your spend per provider, per month? Not the total bill, the split.
4. Can you name the second-best model for your main task, and have you tested it in the last quarter?
5. Where do your prompts live? A repo, or someone else's database?

Most builders score badly on at least three, and that is fine. The point is to know which three.

Move your configuration into files

The single highest-leverage change is also the least glamorous: everything that shapes how your agent behaves should live in your repository, as text, in version control. Prompts, system instructions, coding rules, skill definitions, evaluation sets. If it currently lives in a settings panel, copy it out.

This has benefits that have nothing to do with acquisitions. Text files diff, so you can see when a prompt changed and who changed it. They review, so a teammate can push back on a bad instruction before it ships. They travel, so the same rules apply whether you are in Cursor, Claude Code, or whatever exists in eighteen months. Tools that read plain directories of instructions have become the norm precisely because this pattern works.

A reasonable target: a colleague clones your repo, opens their preferred agent, and gets roughly the behavior you get. If that is true, no acquisition can strand you.

Put an abstraction between you and the gateway

Routers are genuinely useful. They let you compare prices, fail over, and try a new model without a new integration. The risk is not using one, it is calling it directly from three hundred places in your codebase.

Wrap it. One module in your code that owns model calls, exposes your own small interface, and maps your task names to provider and model identifiers held in configuration rather than in code. Then swapping providers is editing a config file and running your tests. Without the wrapper, the same swap is a search-and-replace across your codebase, with a long tail of subtly different parameter handling.

• Keep model identifiers in configuration, never inline in business logic.
• Pin versions explicitly in production. "Latest" means shipping a slightly different product every time a vendor updates.
• Log every call with the model, latency and token counts, so cost and quality regressions are visible before they are expensive.
• Keep one alternative provider configured and occasionally used, not merely theoretically available.

Write your own evaluation set

Five frontier models shipped in the same week that these two deals landed, including GLM-5.3, Qwen 3.8 27B and Gemini 3.7 Flash. Each arrived with a benchmark table. None of those benchmarks are your product.

The antidote is small and unglamorous: twenty real prompts from your own application, with the outputs you actually want, in a file. Run them against a candidate model, compare, decide. That is your evaluation set, and it is the only number that should determine what runs in production.

Twenty examples sounds too few to be rigorous, and it is, but it is dramatically better than vibes and a leaderboard. Builders who have this file switch models in an afternoon with confidence. Builders who do not, argue on forums about whether a model "feels worse" this month. One of those groups ships.

Contain the blast radius of your agents

Portability is also about what happens on your machine. As agents get more autonomous, the question of where they run stops being cosmetic. Tools like Clawk hand the agent a disposable Linux VM instead of your laptop, and sandboxd builds applications inside isolated sandboxes you host yourself.

The security dimension matters too. Google's Mantis packages security review skills that a coding agent can load and run against the code it just wrote, which is a cheap way to catch the injection and secrets handling problems that generated code is prone to. Running review inside your own pipeline rather than relying on a vendor's hosted checker is another form of not being locked in.

What actually changes, and when

It helps to have a rough timeline, because the fear tends to be either too dramatic or too dismissive. In the first weeks after a deal closes, essentially nothing changes. The team is dealing with paperwork, retention packages and integration planning. Public messaging is reassuring and usually sincere at the time it is written.

Over the following months, the roadmap starts to bend. Work that serves the parent gets resourced first. Integrations with the parent's products appear before the community feature request that has three thousand upvotes. Pricing experiments begin, often framed as new tiers rather than increases. Around the same time, the people who made the original product opinionated start to leave, which is the change that matters most and is the hardest to see from outside.

A year or two in, you find out what the tool is for now. Sometimes it is better, because real resources arrived. Sometimes it is a feature inside something larger. Either way, the decision you make at that point is far easier if your prompts, evaluations and integrations were never welded to it.

When lock-in is actually worth it

Portability is a cost, and pretending otherwise leads to over-engineering. Every abstraction you add is code you maintain, and a wrapper that supports four providers badly is worse than one that uses a single provider well. There are cases where committing deeply is the right call.

If a vendor's specific capability is the reason your product works, use it fully and stop apologizing. If you are pre-launch and still looking for anyone who cares, spending a day on provider abstraction instead of talking to users is procrastination with good branding. If the switching cost is genuinely low because the surface area is small, you do not need the wrapper yet.

The rule of thumb: pay for portability in proportion to what the dependency touches. A model call that runs on every request in production deserves an abstraction. A one-off script that formats your changelog does not. What is always worth doing, at any stage, is the cheap half: keep your prompts in files and know what you spend.

Know your numbers before you need them

When a vendor changes pricing, the builders who react calmly are the ones who already know what they spend and where. Track monthly spend per provider, cost per thousand requests for your main workflows, and the share of your traffic that a single vendor handles. If any one provider is above roughly seventy percent of critical path traffic, that is a concentration risk worth reducing on a quiet week rather than a loud one.

This is also how you spot the good news. Cheaper inference and more capable open weights arrive constantly, and the team that knows its per-task costs can act on a price drop immediately. Portability cuts both ways: it protects you from bad changes and lets you capture good ones.

Practical takeaways

• Move prompts, rules and agent configuration out of vendor UIs and into version-controlled files in your repo.
• Wrap model calls in one module of your own, with provider and model identifiers in configuration.
• Pin model versions in production and log model, latency and token counts on every call.
• Keep twenty real prompts from your product as an evaluation set, and run them before you switch anything.
• Keep a second gateway or provider configured and periodically exercised, not just bookmarked.
• Run autonomous agents in disposable VMs or sandboxes rather than on your primary machine.
• Review spend per provider monthly, and treat any provider above about seventy percent of critical traffic as concentration risk.

The bottom line

Consolidation in developer tooling is not a temporary phase. Capable tools attract capital, capital buys them, and the incentives shift afterward. That is the normal life cycle of infrastructure, and it will keep happening to whatever you switch to next.

So the goal is not to pick tools that will never be acquired, because you cannot. The goal is to hold your tools loosely enough that the news is interesting rather than threatening. Configuration in files, one abstraction over your model calls, your own evaluation set, and honest numbers on spend. That is an afternoon of work, and it converts every future acquisition headline from a problem into a paragraph you read over coffee.

Portability is not loyalty to open source or hostility to vendors. It is leverage, and leverage is the only thing that makes you a customer rather than a tenant.