The day Anthropic announced it was adjusting the API pricing for one of its models, a one-person translation agency found itself stuck. The quote sent to a client had been calculated using that model's token costs. The owner knew which model could serve as a backup, but matching the same quality with it meant rebuilding the prompts from scratch — a job that would take days. And in the meantime, there was the separate problem of what to tell the client.
Anyone who has never faced this situation has either been lucky, or just hasn't faced it yet.
Reports surfaced that Stripe, the payments infrastructure company, was acquiring OpenRouter, an AI model router. OpenRouter distributes traffic across multiple AI models — Claude, GPT-4, Gemini, Llama, and others. Instead of picking a model directly, developers set cost or performance criteria, and requests get routed automatically to whichever model fits. Stripe's interest reads as a single bet: once AI models become a commodity traded like electricity, whoever controls the router that directs that flow ends up holding long-term pricing power.
People who use electricity don't care which power plant it came from — they only care about price and reliability. Signs are piling up that AI models are heading in the same direction. In early 2023, processing a GPT-3.5-level task cost $0.002 per 1,000 tokens. Today, open-source models of comparable performance handle the same task for less than a tenth of that cost. In certain domains, open-source models have started to overtake commercial ones, and the range in which proprietary models hold a clear edge keeps shrinking.
Against that backdrop, there's a question that demands a real answer from anyone running a small operation: can you actually switch your current AI provider?
Figure Out Which Tasks Only Work With One Provider
Lock-in is the point where switching away from a provider costs more than simply accepting whatever terms that provider sets. With AI, this builds up gradually, growing with every prompt and every integration you add.
The most common route is what you might call prompt dialect. A prompt tuned to one model's particular response pattern won't produce the same result on another. Claude tends to respond well to clearly formatted instructions, while GPT-4 tends to do better with longer context. Once you've optimized dozens of prompts around those differences, switching providers turns every one of them into a rework item. It might look like a few days' work at first, but once those prompts are wired into real workflows, the actual scope changes.
Next comes API format dependency. Once you've built an integration around one provider's specific API structure, moving to another provider means rewriting that integration code. The same problem shows up even if you don't touch code directly. If you use a SaaS tool with AI features baked in, that tool rarely discloses which model it relies on internally. The first step is figuring out whether swapping the tool also means swapping the underlying provider, or whether the tool alone can be changed.
Per-unit pricing needs checking too. If your "cost per job" figure is pegged to a specific model's token cost, your entire margin structure moves when that model's price goes up. For anyone running high-volume repetitive work, changing a single pricing assumption means redoing the margin math from scratch.
Go through the AI-dependent tasks you currently run and list out which ones would grind to a halt if you switched providers tomorrow. Call this your dependency map. If the list comes up empty, either you have no dependencies, or you simply haven't checked yet.
When Pressure to Switch Turns Lock-in Into a Real Cost
Lock-in itself isn't the problem. If what you're using right now is cheap enough and works well enough, none of this matters. What actually requires judgment is how long that condition holds.
Price increases arrive without warning. AI API pricing has generally trended down over the past two years, but that overall trend doesn't apply evenly to every individual product. OpenAI has adjusted pricing on specific features in stages since GPT-4 launched, and Anthropic's pricing policy has shifted from one Claude version to the next. If the feature you're using now happens to be free or bundled into a cheap plan, you need to work out your response before that policy changes, not after.
Performance gaps shift too. Model A might clearly outperform the alternatives on a given task today, but that could be different six months from now. In areas like Korean-language processing and code generation, open-source models are catching up fast. If performance is the reason you're paying for a pricier provider, the moment that gap narrows is the moment to switch. The only way to catch that moment is to periodically run your current model's tasks through alternative models and compare.
Outages and policy changes are the hardest to predict. If a provider discontinues a feature, restricts usage patterns, or goes down for several hours and you have no fallback, that downtime is a straight loss. In 2024 alone, several major AI API services suffered temporary outages. Whether you have a fallback you can switch to immediately in that situation comes down entirely to whether you tested one beforehand.
If switching costs are high when any one of these pressures hits, lock-in stops being theoretical and turns into a real cost.
Until You Actually Try an Alternative Model, Switching Cost Is Just a Guess
Integrating a router like OpenRouter directly, or building out a multi-model architecture, may not be realistic for a solo operator right now. But there's something you can do well before that.
Pick the single task from your dependency map that carries the most weight, or that seems hardest to replace, and actually run that same task through an alternative model. The goal isn't to switch right away. It's to measure two things.
The first is the gap in output quality. See for yourself, concretely, how different the results from your current model and the alternative actually are, and whether that difference is significant enough to require rework. Rather than a vague impression like "Model B just doesn't work for this," you want a concrete finding like "switching to Model B requires this much rework, specifically in this part."
The second is the scope of rework. Track directly how many prompts need to change, which parts of your integration code need modifying, and how your unit-price math shifts — and you'll know the real scale of the switching cost.
You might find the switch is easier than expected. You might find it's far more complicated than you assumed. Either way, it's better to know now. If conditions change while you're still in the dark about your switching cost, you're not responding anymore — you're just cleaning up after the fact.
