Google Cloud put a rival model provider inside its own model garden this week. Selected enterprise customers can now access OpenAI models through Google Cloud, pay through the same marketplace, and use the cloud controls they already have. [1]
That sounds like a clean expansion of choice. A team does not have to open a separate cloud account just to test another model. Procurement, identity, audit, and existing spending commitments can stay where they are.
It also exposes the limit of the word choice. Changing the model inside one platform is different from moving the workload. The prompt may be portable while the data, permissions, logs, network rules, evaluation history, and support process remain attached to the place where the system was built.
Three announcements this week make the distinction useful. Model distribution is opening, familiar software is reaching more hardware, and cloud controls are stretching into customer-operated environments. The operator question is whether those options create a real route out or only another route in.
01 / THE MENU
Buying another model is getting easier.
Google Cloud says OpenAI's GPT-6 Astra, GPT-6.1 Sol, and GPT-6 Luna are rolling out in private preview through its model garden. Usage appears on a Google Cloud invoice, draws down existing commitments, and sits behind the platform's identity and audit controls. Google says more access will follow. [1]
For a team already operating on Google Cloud, that can remove real friction. A model comparison no longer has to begin with a new purchasing path, a separate access system, and another set of logs. The company can test cost, latency, and quality inside an environment it already knows.
Google describes this as a way to swap models without architectural lock-in. That claim needs a real migration before it earns the phrase. The same announcement also makes the workload easier to attach to Google Cloud billing, governance, networking, and operations. More model choice can increase leverage while the surrounding platform becomes harder to leave.
The distinction matters in ordinary work. If a research assistant changes from one model to another but still depends on the same document store, retrieval service, identities, evaluation set, and approval path, the team changed a component. It did not prove that the workload can move.
02 / THE STACK
Familiar tools remove one layer of friction.
Google's TPU release shows the same pattern closer to the infrastructure. The company added PyTorch-native backends for vLLM and SGLang, two open serving engines used to run models. Developers can keep familiar PyTorch tensors, worker processes, schedulers, cache managers, and API servers while TPU implementations handle the hardware underneath. [2]
This is meaningful portability. A team can carry more of its software habits and model-serving code to another kind of accelerator. It creates another option when capacity, price, or performance changes.
The engineering page is also refreshingly specific about what does not stay generic. The stack still uses XLA compilation, TPU-specific Pallas kernels, TPU Sync, and Google Cloud storage for some cache behavior. Google reports production use with preview customers and public benchmark submissions, but those results do not tell a new team how much work its own migration will take.
Compatibility is layered. A familiar interface may preserve code and skills while the production system still depends on provider-specific kernels, storage, networking, and operating knowledge. The option may still be worth adopting, as long as the team records which layer became portable and which one did not.
03 / THE CONTROL
An exit route has to carry the operation.
Microsoft's sovereignty announcement takes the portability question beyond models and code. Its new control panel is designed to help customers see workload dependencies and assess portability across public cloud, customer-operated systems, and partner environments. Other additions cover external encryption keys, records of operator access, disconnected operation, local data services, and local model inference. [3]
The availability labels matter. External key management is generally available. The control panel, connected-to-disconnected transition, and several local services are previews or future releases. This is a product direction with concrete pieces, not evidence that a complicated workload can already move cleanly.
It still gives us a better definition of an exit plan. The question is not only where the model runs. It is whether the data remains usable, the identities still mean the same thing, the logs survive, the keys stay controlled, and the service can continue while people change the underlying environment.
Maximum portability is not free. Supporting two environments can create duplicated controls, slower feature adoption, and a recovery plan nobody rehearses. A low-risk internal helper may not justify that cost. A regulated workflow or essential service may justify much more.
The practical decision is proportional. Name the consequence of being stuck, then pay for enough options to match it. If the team cannot identify the dependencies or test one small move, the exit route exists only in a slide.
What these announcements do not establish
They do not prove that changing models, accelerators, or operating environments is quick or inexpensive. They are vendor announcements with a mix of private preview, public preview, generally available features, and reported benchmarks. The useful move is to test one workload against its real dependencies before a contract, outage, or policy change makes the test urgent.
04 / PUT IT INTO PRACTICE
Run a small exit rehearsal.
Choose one AI-assisted workload that matters enough to keep running. Spend forty-five minutes mapping the model, data, retrieval, identities, logs, evaluations, network rules, keys, and human approvals it depends on. Then choose one small move you could test without rebuilding the whole system.
The test might replace the model against the same evaluation set, export the source documents and permissions, reproduce one audit record, or run a small sample in a second environment. Compare the result with today's baseline for quality, time, cost, and review effort. Stop if the rehearsal creates exposure or requires authority you do not have.
One workload. One credible route out.
Build: A one-page workload exit brief with its dependency map, decision owner, and first reversible portability test.
Look for: A second person can identify one blocking dependency, one viable substitute, and the controls that must survive, then compare a small test with today's quality, time, cost, and review baseline.
Keep the rehearsal small enough to finish. The useful result is a dependency you can remove, a control you can carry, or a reason to accept the lock-in deliberately.