If losing one model forces your team to rebuild the environment, you do not control your AI strategy. You only have access to it.
On June 12, companies outside the United States lost access to Fable 5 and Mythos 5. There was no outage. Capacity did not run out. The US government issued a directive, and Anthropic switched off access for foreign nationals, including its own foreign employees inside the United States.
Access was partly restored later. That does not erase what happened. For several days, a government decision made two of the market’s most capable models unavailable.
Then came Cursor. After the company became part of SpaceX, OpenAI notified SpaceX that it intends to wind down the contract providing its models to Cursor. The proposed shutoff date is November 12, 2026. Future OpenAI models will not be offered through that route.
Days later, OpenRouter announced that it is joining Stripe. OpenRouter says its mission and commitments will not change. I hope they do not. But control of another important gateway is changing hands.
Three events. Three different causes. The same operational problem: your access to AI depends on decisions you do not make.
You can choose the right model and still lose access
None of these examples means that Cursor, OpenRouter, or Anthropic was the wrong choice. They show that a good choice today does not guarantee access tomorrow.
It is easy to call this vendor risk. It is broader than that. A government can restrict a model. A lab can end a contract. An acquisition can realign incentives. The model your team relies on can simply disappear from the tool where they use it.
If that happens to an individual subscription, a developer changes apps. Inside an enterprise, the change reaches identity, security, procurement, spend limits, retention, audit, client configuration, and training. The model was only one component. The real switching cost lives in everything attached to it.
A model catalogue is not control
A vendor can offer twenty models and still confine your company to a single route. The menu changes. The contract, credentials, logs, and control plane remain with the vendor.
Real optionality asks for more. It means changing the model without changing the operating system around it.
The model can change. Identity, policy, spend, and audit should keep working.
That is the test. Can your team redirect the same Codex, Claude Code, Cursor, or internal workflow to another model without distributing new keys, recreating policies, and losing its history? If not, you have variety. You do not yet have portability.
That test points to the architecture: keep volatile components at the edges and make the governance layer durable.
Put the durable layer in the middle
Elevata’s AI Governance Gateway separates the user experience from the model provider.
Engineers stay in the tools they prefer. The gateway runs in the customer’s AWS environment and handles what must survive the next change: enterprise sign-in, approved models, spend limits, protocol translation, and a record of every request.
Protocol translation makes that separation practical: the Gateway acts as a reverse proxy in the customer environment, exposes OpenAI- and Anthropic-compatible endpoints, and translates requests in flight. Developers point OPENAI_BASE_URL or Claude Code’s endpoint configuration to the Gateway; it routes each request to Bedrock, a direct provider, or an approved VPC model without changing the tool or distributing another set of credentials.
In practical terms, a team can:
- change a model without reinstalling tools on every machine;
- keep one set of rules across several tools and model families;
- see who used which model, on which codebase, and at what cost;
- stop a request before the spend when a team reaches its limit;
- keep governance data inside its own environment.
The benefit is not an abstraction called “flexibility.” It is avoiding an emergency migration every time a contract, policy, or ranking changes.
Bedrock provides the catalogue. The gateway provides the control plane.
For an AWS-centred enterprise, I do not know a more flexible practical setup today than Amazon Bedrock combined with a customer-controlled gateway.
Bedrock brings different model families into the platform the company already uses for identity, networking, security, contracts, and billing. OpenAI itself presented its frontier models and Codex on AWS as a way to use existing enterprise workflows for security, compliance, procurement, and governance.
The gateway turns that catalogue into an operating capability. It authenticates the user, applies policy, records usage, and selects the route. When the best model changes, the company changes the destination. It does not throw away everything else.
This does not eliminate dependencies. Bedrock is a platform too. AWS, model labs, and governments will keep making decisions. The difference is that none of them needs to control the layer you use to respond.
Our gateway already places Claude Code, Claude Desktop, and Codex behind the same control plane. It can also add a direct provider or customer-operated model route. The point is not to become locked into Bedrock. It is to start with the broadest useful path and keep an exit designed in.
Bedrock provides ZDR without requiring an enterprise commitment to one provider
On Bedrock, the default posture for enterprise inference is already close to Zero Data Retention. The customer can lock account retention to none; model invocation logging stays disabled until the customer enables it; and AWS says prompts and responses are not made available to model providers. The relevant exception today is Fable 5 and Mythos 5, which require provider data sharing and 30-day retention.
Direct access to OpenAI or Anthropic follows a different model. To obtain ZDR, a company must pass approval and enter a significant enterprise contract with each lab. Those commitments concentrate budget with one provider and reduce the funding and negotiating flexibility available for competing models. A data-protection requirement can therefore become a source of commercial dependence on the provider.
A customer-controlled gateway prevents that contract from becoming the control plane for the AI strategy. The company can make Bedrock its default ZDR route, block Fable and Mythos for workloads that require zero retention, and add direct routes only when the contract makes sense. Identity, policy, audit, and developer tools remain under customer control; model labs remain replaceable destinations.
OpenRouter proves the value of the category
OpenRouter solves part of the same problem as a hosted service. One API opens access to hundreds of models, several providers, routing, observability, and cost controls. Its ZDR control can limit each request to endpoints with a declared zero-retention policy. For teams comfortable giving the control plane to another company, it is a strong option.
The announced Stripe transaction does not diminish that value. It makes the ownership question impossible to ignore: who controls the route, and what happens if that company’s interests change?
A shared service prioritizes convenience and reach. A gateway in the customer’s AWS account prioritizes control, customization, and continuity. Both validate the need for a layer between the tool and the model. The difference is who owns it.
Choose the ownership boundary
The architecture can support different ownership and operating boundaries without giving up customer control. Elevata offers three models.
1. Customer-operated perpetual version
Elevata deploys the Gateway in the customer’s AWS account and grants the customer a perpetual license to the delivered version’s codebase. This is not access to a hosted service that stops when payments stop: the customer can inspect, operate, maintain, and continue using that licensed version indefinitely without an active Elevata subscription.
2. Managed operation in the customer environment
The Gateway remains in the customer environment. Elevata operates, monitors, and evolves it for a monthly fee. The team keeps architectural control without carrying the full operational load.
3. Customer-specific architecture
We apply what we have learned across our deployments to build a version around the customer’s protocols, controls, integrations, residency requirements, and operating model.
In all three paths, the answers should be clear before work begins: where the code runs, who owns the governance data, which routes can be added, and what happens if the commercial relationship ends.
Ask these questions before the next decision
- If the best model changes on Friday, can we use it on Monday without rebuilding the environment?
- If a lab removes our tool’s access, what is the approved alternative route?
- If a government restricts a model by country or nationality, which policy takes over?
- Can we export our own usage, cost, and audit history?
- Who has the right to operate the gateway if we change partners?
The best model a year from now probably has not launched yet. The company controlling your favourite tool may be acquired. The current contract may be cancelled.
Your strategy should not try to predict every change. It should make the next change survivable.
Do not ask which model your company should standardize on forever. Ask whether it can change models without asking permission.
Ready to audit your AI routing resilience?
Explore the AI Governance Gateway architecture or schedule an environment review with Elevata →.
