Model selection is usually framed as a ranking problem.
Which model is strongest for the task? Which one is fast enough? Which one fits the budget? Which one performs best on the evaluation that looks closest to the work?
Those questions matter. I think they are incomplete.
Once real work accumulates around a model, the choice is no longer only about the model. The workflow starts depending on an access path, an API, tool behavior, context assumptions, state, deployment choices, and a collection of small integration decisions that are very easy to ignore while everything is working.
A model can be excellent while the dependency around it is brittle.
The question I want beside capability, quality, and price is this:
If this model or endpoint stopped being a viable operating choice, what would have to change before useful work could resume?
That is the exit route.
Somewhere else to live is not the same thing as being able to move. The flat exists. That was never the hard part. The cost is in the furniture that will not fit through the new door, the address sitting on more accounts than you remember giving it to, and the deposit you cannot get back until the old place is empty. None of that is a problem with the flat, and none of it is visible from the listing.
The comparison stops in one place worth naming: you can see your furniture. Much of what a workflow has attached to a model is not visible until you try to take it somewhere else.
I do not mean a frictionless swap. That is a much stronger claim, and usually not a credible one. I mean a task-specific migration path whose costs and failure points are visible enough that "we can switch later" is more than a sentence people say when they do not want to think about switching yet.
Access can change without capability changing
Two dated examples from June 2026 make the distinction concrete.
On June 17, Anthropic said it was rolling out identity verification for a few use cases. It said verification prompts could appear for certain capabilities or as part of platform-integrity, safety, or compliance checks.
The qualification matters. This does not support a claim that every Claude user or every Claude capability requires identity verification, and it does not establish how often those prompts appear now. It is useful for a narrower reason: practical access can depend on account-level conditions that have nothing to do with raw model capability.
On June 26, OpenAI described GPT-5.6 as beginning in a limited preview for a small group of trusted partners, with broader availability planned.
Again, that is a dated launch record, not proof of August 2026 availability. The useful distinction is simpler.
Capability and availability are different variables.
That sounds obvious when written down. It becomes less obvious after a workflow has quietly started assuming that one particular access path will continue in the same form.
A fallback name is not a fallback system
The easy answer is to keep a second model in mind.
That helps. It does not tell you whether the workflow can actually move.
A technically available alternative can still fail as an exit route because the dependency sits somewhere around the model rather than inside it. I find it useful to separate six layers:
- Access — what conditions outside capability govern whether the current path can be used?
- Interface — how much client code assumes one endpoint, SDK, authentication scheme, request shape, or response format?
- Harness and tools — what depends on model-specific tool syntax, multimodal behavior, parser logic, context handling, or other execution semantics?
- State and control — where do durable task state, instructions, schemas, approvals, and recovery checkpoints live?
- Deployment — can an acceptable alternate path run somewhere the operator is actually willing and able to maintain?
- Fallback fitness — has the alternate path been tested against the real task well enough to know what degradation is acceptable?
A second model can look good at layer six and still be unusable because layer three breaks. A compatible API can make layer two easier and leave layers three through six almost untouched.
That is why "we have another model" is not the same thing as "we have an exit route."
Compatible APIs solve one layer
Hugging Face's guide to running vLLM on HF Jobs is a useful example because it shows both the portability and the remaining work.
The documented server exposes an OpenAI-compatible API shape. An OpenAI client can point at a different base URL and keep a familiar request interface. That can materially reduce client-side integration friction.
But the same guide also includes provider authentication, billing prerequisites, hardware selection, model-serving configuration, context choices, and model-specific tool-calling setup.
So I would not read "OpenAI-compatible" as "interchangeable." It means one boundary can be made more portable.
That is still valuable. A narrow layer of compatibility is better than none — as long as I know which layer it is.
Harness assumptions are where portability gets weird
The less visible coupling often sits in the harness.
Agent and coding workflows do not just send text to a model and receive text back. They may depend on tool schemas, images, reasoning fields, context limits, parser behavior, system-prompt conventions, retry logic, or model-specific quirks.
Nathan Lambert described one concrete example in a June 22 Interconnects post. He had been using GLM-5.2 through Fireworks' API inside Claude Code and reported a compatibility problem where the surrounding setup could try to send images in a way that broke the Fireworks API session and forced a manual context clear.
That is one operator's experience. It is not evidence that alternate providers are generally incompatible, and I am not using the post's broader benchmark, market, pricing, geopolitical, safety, or adoption claims here.
The small example is enough.
The model can be capable. The API can be reachable. The workflow can still fail because the harness assumes behavior the alternate path does not provide in the same way.
A benchmark cannot tell me that.
State is part of the switching cost
Some of the most expensive coupling is not in the API call at all.
Where does the durable work live?
If instructions, task state, tool definitions, schemas, approval rules, and recovery checkpoints exist only inside one provider-specific session or one opaque harness path, changing the model can become a reconstruction exercise. The shelves came with the flat, and they do not leave with you. The endpoint moved, but the actual work did not.
I am not arguing that every workflow should be provider-neutral. Abstraction has a cost, and provider-specific features can be worth using precisely because they are better integrated.
The question is which parts are worth coupling deliberately.
For work that needs a credible exit route, durable state can live outside the model session. Critical schemas and instructions can be versioned separately from provider configuration. Tool boundaries can be explicit enough that a new model can be tested against them. Recovery can mean restoring application state rather than preserving one conversation forever.
That repository-side dependency is the subject of The Reader Changed the Documentation Contract: once instructions and knowledge become working context for an acting agent, addressability, freshness, and authority become part of whether the system can actually resume useful work.
None of that makes models interchangeable. It makes the dependency easier to inspect.
Switching friction is part of the test
Andrew Marble's June 21 essay about switching away from Claude is useful here because he does not describe switching as free.
He wrote that Anthropic's identity-verification rollout contributed to his decision to reconsider his reliance on Claude, that he was already set up to run a range of open-weight models locally or in the cloud, and that he still expected a short-term productivity cost from moving.
That is one person's judgment and setup. It is not evidence that open-weight models are generally equivalent, cheaper, safer, more private, or easier to operate.
The narrower point is stronger anyway: even a prepared operator can expect migration cost.
I think that is the right standard for replaceability.
The goal is not zero switching friction. It is friction that is visible, bounded enough for the dependency, and rehearsed enough that the supposed fallback is not being evaluated for the first time during the failure that made it necessary.
Open versus closed is the wrong boundary
It would be easy to turn this into an argument that the answer is open-weight models.
I do not think that follows.
Open weights can create deployment options outside a single hosted endpoint. They do not automatically solve interface compatibility, tool behavior, infrastructure cost, model quality, evaluation, licensing interpretation, security, or operational maintenance. They are not inherently cheaper, easier, safer, more private, or better.
A provider-hosted model can also sit behind a well-designed boundary. A workflow may be able to change managed providers without much disruption if its state, tools, and control logic are not deeply entangled with one provider's private mechanics.
So the useful distinction is not:
open = portable
closed = locked in
It is closer to:
dependency understood
vs.
dependency assumed
Sometimes accepting deep coupling is the right choice because the provider-specific capability is worth it.
That can be sound architecture too.
The cost of leaving just needs to be part of the decision rather than a surprise discovered later.
The exit-route test
A model-selection review can include one deliberately boring failure exercise:
Assume the current model or endpoint is no longer a viable choice. What has to happen before useful work resumes?
Then walk through the dependency.
- Access: Is there another approved way to obtain sufficient capability?
- Interface: Which client calls, SDK assumptions, authentication paths, or response formats change?
- Harness and tools: Which tools, parsers, multimodal assumptions, context behaviors, or model-specific instructions need to change?
- State and control: Can the workflow resume from durable state, or does it have to reconstruct work from a provider-specific session?
- Deployment: Can the alternate path run in an environment the operator is actually prepared to own?
- Fallback fitness: Has the alternate path been tested on the real task, and is the expected degradation acceptable?
The depth should match the consequence.
The deployment side of that check is visible in The Source Was Correct. The Installed App Wasn't.: source validity, generated output, package identity, provider state, and the installed candidate are separate evidence layers, so a fallback path has to survive more than a source-code swap.
A disposable experiment may need nothing more than a note about the next provider to try. A long-running or consequential workflow may justify adapters, externalized state, fallback evaluations, or a rehearsed migration procedure.
The point is not to build a resilience programme around every API call.
It is to stop treating replaceability as something that can always be added later at negligible cost.
The dependency is part of the choice
Models have names, benchmarks, prices, context windows, and feature lists. Those are easy to compare. So was the flat.
Dependencies are messier. They live in account conditions, APIs, tools, state, deployment choices, and accumulated assumptions around the workflow.
That mess is where the exit route lives.
A strong model choice is not only the model that looks best for the task today. It is a model whose dependency profile makes sense for the system being built — including the parts the operator is deliberately willing to couple and the parts that need a credible way out.
The exit route belongs in the decision before it is needed.
// End of transmission. Keep the exit visible. — ZYANE