OpenAI or Anthropic is a portability question
The model that ranks best this quarter is not the one you will be running in a year. A well-built system should not care which one wins.
The short version
5 things that decide this
- 01The question is not which model is smarter this month. It is what a provider switch costs when the ranking changes next quarter.
- 02Lock-in is not a vendor doing something wrong. It is a codebase that only talks to one API, with no abstraction layer between the app and the model call.
- 03An eval suite tied to one provider's output format cannot tell you whether a competitor would do the job better. Build evals that run against either model from day one.
- 04Skip any feature that exists only because one vendor ships it and the other does not, unless that feature is the entire reason for the build.
- 05A system built for portability costs a little more up front and a lot less the day a model gets deprecated, a price changes, or a new model simply performs better.
Why "which model is better" is the wrong question to start with
Ask a founder which model to build on and most reach for a benchmark. Coding, reasoning, agentic tool use. Someone ranks it every week. The leader changes hands often enough that betting a whole architecture on this quarter's winner is a bet against the calendar.
A benchmark score is not what actually costs you money later. How the code was written is. A system can call one vendor's SDK directly. It can format prompts around that vendor's quirks. It can store output shaped to that vendor's response schema. Do all three and the team has made a permanent decision while thinking it made a temporary one.
Both OpenAI and Anthropic ship strong models and both change pricing, deprecate versions and shift capabilities on their own schedule, not yours. Treat the choice as final and the codebase pays for that decision the day it stops being true.
Lock-in is an architecture problem, not a vendor problem
Neither provider builds their SDK to be swapped. That is normal, not a complaint. Each one wants its own tool-calling format, its own streaming shape, its own way of representing a conversation. The lock-in only happens if the application code absorbs those choices directly.
One pattern creates a hard switch: provider-specific calls scattered through business logic. A checkout flow imports the OpenAI client. A support tool imports the Anthropic client. Each has its own prompt formatting and its own parsing of the response. Multiply that across a dozen features and a provider swap is no longer a config change. It becomes a rewrite touching every file that ever called the model.
The fix is one layer between the application and the provider. A single interface the rest of the codebase calls. Provider-specific request and response shaping happens in one place, not many. Swapping the model behind that interface becomes a change in one file, not a search-and-replace across the whole application.
- 01One interface the application calls, never the provider SDK directly from business logic.
- 02Provider-specific prompt formatting and response parsing live behind that interface.
- 03A model swap becomes a change in one place.
- 04Not a rewrite of everything that ever called it.
- Direct SDK calls in business logicEvery feature that imports the provider client owns a piece of the lock-in.
- Provider-shaped promptsFormatting tuned to one vendor's quirks does not transfer as-is.
- Evals tied to one output formatA suite that only reads one provider's response cannot judge the other.
- One-vendor-only featuresA capability only one provider ships becomes a feature you cannot easily replace.
Each of these is a place the switch cost hides. None of them show up until the day you actually try to switch.
Three habits that keep the switch cheap
Build a provider-neutral interface first. Define the shape of a request and a response your application cares about, then write a thin adapter for each provider that maps to it. New code calls the interface. When a new model launches, only the adapter needs a look, not every feature that uses it.
Keep evals portable. An eval suite is only useful for a switch decision if it can run against a candidate model with no rewrite. Write the eval cases against your own task and your own success criteria. Not against one provider's response format. A candidate model can then be scored on the same test the incumbent already passed.
Build on capabilities both vendors ship. Tool calling, structured output and long context all work on both OpenAI and Anthropic today. A feature built on any of those transfers with an adapter change. A feature built on a capability unique to one provider is different: you cannot swap it without cutting the feature or rebuilding it. Save that trade-off for cases where the unique capability is the whole reason the feature exists.
None of this is free. An abstraction layer takes longer to write than a direct SDK call. Portable evals take more thought than pointing a test script at one provider's playground. That cost shows up early, once, on a schedule you control. A different cost shows up later, on the vendor's schedule. It arrives the day a model is deprecated or a price changes, and the switch has to happen anyway.
Questions this raises
01Does building for portability mean staying on the weaker model to avoid lock-in?
No. Portability is about how the switch is built, not about refusing to pick a leader. Choose the model that wins the evaluation today. The discipline is making next year's switch a config change instead of a rewrite, not avoiding the current best choice.
02Is an abstraction layer worth it for a small feature?
For a single prototype, often not. Anything going to production and staying there past one release, yes. The layer costs a few hours once. A scattered rewrite later costs far more, on a timeline the vendor picked, not you.
03What if a feature genuinely needs a capability only one provider ships?
Then build it, and know the deal: that one feature is locked to that provider until the other ships an equivalent, or you rebuild it. Make that a deliberate, scoped choice. Do not let it happen by default across the whole codebase.
Related
- OpenAI vs Anthropic →The side-by-side on data residency, compliance and what a switch actually costs.
- Model deprecation risk, defined →What happens to a production system when the model it was built on gets retired.
- Self-hosted vs managed LLM →The other axis of the same lock-in question: who runs the weights.
