I've watched two teams ship the exact same product in 2026. One spent a week migrating from GPT-5.3 to Claude Opus 4.7 when Anthropic shipped it. The other spent a quarter — and still hadn't finished when GPT-5.5 launched and made the migration moot.
The difference wasn't the model. It was how tightly they'd coupled their agent to one provider.
Here's how to build agents that stay portable as the frontier moves.
What actually couples you to a vendor
Most teams think model lock-in is about the API. It's not — those are interchangeable in an afternoon. The real lock-in lives in five places:
1. Prompts. Every model has its own quirks. Claude responds well to long structured prompts with XML tags. GPT-5 wants concise instructions and clear JSON schemas. Gemini handles multi-document context differently. Prompts tuned for one model regress on another by 5–20% on quality unless you re-tune.
2. Tool / function-call schemas. OpenAI's function-calling spec is the de facto standard, but Anthropic and Google handle it with subtle differences (parameter validation, parallel tool calls, error formats). Code that hard-codes tool_use blocks for one provider breaks on another.
3. Output parsers. Models phrase things differently. "Yes" vs "Yes." vs "Yes, here's why...". A regex that works perfectly on GPT-5 will silently break 8% of the time on Claude.
4. Fine-tunes. If you fine-tuned, you're locked. Fine-tunes don't transfer between vendors. Most teams who fine-tune find it was a mistake by the time the next model generation makes the base capability free.
5. Pricing assumptions. "We can afford 100k tokens per task" works on GPT-5.4 mini ($1.69/M) and breaks the budget on Opus 4.7 ($75/M output). If your product economics depend on a specific model's price, a model swap is a re-pricing.
How to build for portability
Abstract the provider. Wrap every model call in a single function with a consistent input/output shape: runModel(messages, tools, opts) → response. The function takes provider, model, and fallback chain as parameters. Vendor SDKs are an internal detail.
Keep prompts model-agnostic. Avoid model-specific syntax — no XML tags optimized for Claude, no JSON-mode-specific phrasing for GPT. Test prompts on at least two providers before shipping.
Standardize tool schemas to OpenAI-style. It's the de facto standard and every other vendor maps to it. If your tools are defined in Anthropic-specific format, port them.
Use structured outputs, not regex. Every major vendor now supports JSON-schema-validated output. Parsing model outputs with regex is fragile across model swaps; parsing structured JSON is stable.
Avoid fine-tuning until you've exhausted prompting. Modern models are smart enough that fine-tunes are rarely the right answer in 2026. Save the lock-in for cases where you've measurably hit the ceiling of the base model.
Run your eval suite per release. Build a 50–100-task eval suite once. Re-run it every time a model ships. Teams that ship eval-first can swap models in a day; teams without evals burn weeks debating "does it feel worse?"
The fallback pattern
The most important pattern: never depend on one provider being up. Wire 2–3 vendors in production with automatic fallback. If Anthropic has an outage, GPT-5 takes over. If both are degraded, Gemini.
This sounds expensive. It isn't. You only pay for the model that actually serves the request. The fallback model costs nothing 99% of the time.
What it requires: provider-agnostic abstraction (the wrapper above), tested fallback paths, and consistent enough prompts that the secondary model produces acceptable output.
Why agent platforms have an advantage here
Building all of this yourself is a non-trivial chunk of infrastructure. Per-vendor SDKs, prompt portability tests, an eval harness, fallback logic, billing reconciliation across vendors. It's the kind of thing that can be built but rarely is well — especially at smaller companies where the AI work is one piece of a broader product.
This is the actual case for using an agent platform. Klaws abstracts the provider entirely — you describe what your agent should do; under the hood the platform routes across Anthropic, OpenAI, Google, and Moonshot, with automatic fallback. When a new model ships, we swap it in for everyone simultaneously. Your agent gets faster and cheaper without you doing anything.
That's why our Fast and Deep mode pricing didn't change when Gemini 3 Flash and Qwen 3.6 Plus replaced earlier defaults this spring — the routing changed under the hood; the price didn't.
A migration checklist
If you're stuck on one model and want the next swap to be painless:
- Audit how many places your code references a specific model name. Centralize them in one config.
- Build an eval suite that captures your 20 highest-stakes tasks. Score them today on your current model so you have a baseline.
- Run the eval on at least one alternative provider. Note what regresses and why.
- Add a fallback path for at least one outage scenario. Test it.
- Decouple any fine-tune from your application logic, or replace the fine-tune with prompting + retrieval.
The teams that do this once stop worrying about model launches. They evaluate, they swap if it's better, they move on. The rest spend their roadmap migrating.
Try Klaws free for 3 days → — the routing and switching is already built. You just describe what you want.
For more: How to choose the right AI model, how to mix fast and deep models, and the 2026 model leaderboard.
Top comments (0)