Edition 4 · 04 / 06
The Price of an Escape Route
Portability has a real cost. This decision framework helps judge when the price of an AI escape route is worth paying.
The natural response to model dependency is often, “Use more than one provider.” That is occasionally right. It is not free, and it is not automatically sensible.
A single-model architecture can be easier to build, observe, secure and operate. It may have lower latency, lower inference cost and better quality because the team has invested in the particular capability it needs. An organisation may have one data-processing relationship, one security review and one set of service behaviours to understand.
The alternative creates a portability premium. It buys the option to leave or survive a change. Like other forms of insurance, the option has an ongoing price.
What the premium contains
Maintaining a credible alternative can require another integration, alternative prompts, duplicate evaluation, security assessment, data agreements, procurement, monitoring and regression testing. It can require a decision about what data may be sent to the secondary provider and what happens when the alternative does not meet the primary model’s standard.
There are architectural costs too. Teams need stable internal contracts, versioned tool definitions, observable routing, practical incident ownership and enough time to retest after either model changes. A claimed fallback that is never exercised is not an asset; it is an untested assumption.
These costs do not make portability wasteful. They make it a decision rather than a slogan.
Compare the consequence, not the number of providers
The useful comparison is between the expected cost of a dependency and the cost of maintaining an escape route. No organisation can calculate an exact probability of every model change or outage. It can still reason about consequence, duration and tolerable loss.
Low-criticality service
Pause may be the sensible fallback
A short interruption is inconvenient, but it does not breach a commitment or prevent the underlying work.
Business-critical service
The escape route has more value
Lost availability affects revenue, service levels, regulated activity or the ability to keep operating.
This is a decision framework, not a prediction model. The comparison is between the expected dependency cost and the ongoing price of portability.
For a low-criticality drafting tool, a temporary pause may be acceptable. The work can be postponed or completed with ordinary office tools. Maintaining a continuously tested secondary route may cost more than the disruption it prevents.
For a service that supports revenue, customer commitments, regulated activity or a critical operational process, the equation changes. The cost of an interruption includes more than lost tokens or developer time. It can include breached service levels, customer harm, manual workload, audit issues and the time spent rebuilding trust in the result.
AI unit economics still matter
Resilience spending does not negate the economic case for AI. A workflow can remain substantially less expensive, faster or more capable with AI than with a wholly manual process while still justifying investment in testing, a safe fallback or retained human capacity.
The comparison should include the whole service. An inexpensive model call can sit inside an expensive failure if it causes delayed customer resolution, wrong tool use or a long recovery. Conversely, a high-cost multi-model architecture can be disproportionate if the underlying task can safely wait.
The goal is not a universal standard. It is an explicit decision about the service’s recovery objective and the evidence required to meet it.
Three questions for an investment decision
First, what is the business consequence of losing this capability for an hour, a day and a week? Second, what would actually restore it: another endpoint, a model-specific rework, reduced functionality or people? Third, which parts of that recovery need to exist before the event rather than being improvised during it?
The answer may be a hot fallback. It may be a periodically tested secondary model. It may be a documented manual route and clear customer communication. It may be a conscious decision that a non-critical feature can stop.
In each case, the organisation has chosen the premium to pay.
If portability is worth buying for this service, what does good portability actually look like in the architecture?