There's a version of this decision that sounds easy and leads you somewhere dumb: "all three frontier models are in Google Cloud now, so just use whichever tops the leaderboard this week." It's dumb because the leaderboard isn't your task, this week isn't next week, and the thing that will actually cost you money a year from now isn't the model at all.
Here's what's true as of October 2026. OpenAI's frontier models and Codex are arriving in Google Cloud's Model Garden — private preview now, broader access expected in weeks. They join Gemini (native to Vertex) and Claude (generally available on Vertex AI for a long time, with its own model IDs and regions). For the first time, the three families you'd realistically choose between are buyable inside one cloud account, under one bill.
That makes the choice easier to act on and, oddly, harder to think about — because the integration tax that used to narrow it for you is gone. So you need an actual method. Ask these four questions, in this order.
1. Task fit — and run your own eval#
The single highest-leverage thing you can do, and the thing almost nobody does: evaluate on your own prompts. Take 20–50 real cases from your actual product, write a rough rubric (correct / wrong, or a 1–5 scale), and run all three. The family that wins your task is worth more than the family that wins SWE-bench or a creative-writing leaderboard you will never run in production.
Public benchmarks move monthly, measure generic tasks, and are increasingly gamed. They're fine for a shortlist — and the Model Garden just handed you the shortlist for free. They are a terrible way to make the final call. One click of access to three models is only a gift if you use it to test, not to skim a chart.
2. Data and identity — now a floor, not a tiebreaker#
For years, "which cloud is your data and IAM already in" was the decisive question when picking an enterprise model platform — it's the whole thesis of Bedrock vs Vertex vs Foundry. But once all three models live inside the same Model Garden, they share one IAM, one data-residency region, and one compliance review. The residency and identity differences between vendors collapse into a shared floor you've already cleared.
That's liberating: don't re-litigate a compliance decision the cloud choice already settled. It also means data-residency stops being a reason to pick one model over another here — it's a reason you picked Google Cloud, which is a different decision, and a bigger one.
3. Committed-spend economics — the real lock-in#
Here's where the actual money and the actual lock-in live. Buying through the Marketplace lets you apply committed Google Cloud spend to the purchase, and committed-use discounts work the way they always have: you promise a level of consumption over a term, and you get a lower rate in exchange. The discount only pays off if you concentrate usage in that cloud — which is exactly what makes leaving expensive later.
So size the commitment against consumption you're sure of, not the hockey-stick you're hoping for. Over-committing to chase a deeper discount is the most common way founders turn a flexible model choice into an inflexible cloud bill. The model is now the easy part to swap. The three-year spend floor is not.
4. Exit cost — pick so you can leave#
Whatever you choose, architect so the choice stays reversible. Put a thin interface of your own in front of the model call, so switching providers is a config change rather than a rewrite — the same provider-agnostic discipline that's been right all year. Keep one open-weight model you could self-host warm as a fallback, so your floor price isn't set by a vendor you can't leave. And know your switching cost in days, measured, not guessed.
The Marketplace makes trying every model cheap. Your architecture is what keeps leaving cheap — and leaving cheap is the only thing that keeps your pricing honest.
The decision rule#
Shortlist all three (the Model Garden already did it for you), eval on your own task, then let data-residency and committed spend break the tie — never the other way around.
If you find yourself choosing the model because of the cloud discount before you've run a single eval, stop. You've let the tie-breaker pick the winner. The clouds would love that. Run the eval first.
Fresh from the wire: why OpenAI landing on Google Cloud makes model choice a procurement line, and the portable-stack playbook that keeps any of these reversible.
