Skip to content
Technology and engineering

Google Vertex AI as a single door to Gemini and Claude: why stop writing one adapter per AI provider

November 4, 2026

If your platform runs on Google Cloud, Vertex AI already gives you Gemini, Claude and Mistral through one door. A thin gateway of your own does the rest.

Laptop screen showing metrics and analytics charts on a dark background
Photo by Luke Chesser on Unsplash

In one line: if your platform runs on Google Cloud, you don't need to connect to every AI company on its own. Google Vertex AI is already a single door to Google's models (Gemini) and to partners like Anthropic (Claude) and Mistral, with one identity, one contract and one bill. On top of it, all you need is a thin gateway of your own that does only what sets you apart.

The problem: every AI provider is one more integration

Any product that uses AI wants to be able to switch models. A cheaper one ships, or a faster one, or one that reasons better, and you want to try it without rewriting anything.

The usual start is one adapter per provider: one for Google, another for Anthropic, another for OpenAI. And each one brings its own baggage:

  • its own API and its own way of answering,
  • its own key, which you have to store, rotate and keep from leaking,
  • its own contract and its own legal review,
  • its own bill, almost always in dollars and outside your cloud.

With one provider you don't notice it, and by the third it hurts.

Vertex AI is already a model aggregator

Vertex AI also serves models from other publishers: Model Garden offers them as a service, and you can list them through the API. A query to that list in November 2026 returned this:

  • Google (Gemini): 32 models.
  • Anthropic (Claude): 13 models.
  • Mistral: 4 models.
  • OpenAI: none on that list. Its commercial models still come through OpenAI's own API, with its own key.

That changes the math: for Gemini and Claude there's one door, and it gives you four things that one adapter per provider doesn't.

  • One way in, no keys. The service reaches Vertex AI with its own Google Cloud identity, so there's no Anthropic key, or anyone else's, to store.
  • One contract. Partner models fall under your Google Cloud contract, and if the platform handles customer data, reviewing one contract instead of five matters a lot.
  • One bill. Gemini and Claude usage lands on the Google Cloud bill, which is usually where your cloud credits are.
  • One place for region and network control. Where data is processed, quotas and monitoring all live in the same spot.

The pattern: one adapter per API family

The real shift is how you count adapters. You count one per API family, even when several AI companies sit behind it:

  • The Vertex AI family, the main one. It signs in with the service's identity and builds each request in the format that model expects. Vertex AI has three formats side by side: Gemini's native one, the messages format Claude uses, and one compatible with the OpenAI style.
  • The keyed compatible family, the exception. For providers Vertex AI doesn't offer, like OpenAI's commercial models.

That's two adapters, and it stays two even if you use ten models. Adding Claude, or a new Gemini, becomes a setting you enable from a console, with no new code.

What the architecture looks like

There are three pieces, each with its own job:

  • Products ask for “summarize this conversation” the same way every time, and don't know which model or provider answers.
  • A thin AI gateway of your own decides which model handles each task, falls back to a backup model if the main one fails, checks that the answer meets the contract before it reaches the user, logs usage and cost, and only talks to allowed destinations. Its Google identity can only go out to Vertex AI.
  • An operations console works as the dashboard: it shows the real model behind each task, lets you enable models from the list Vertex AI returns, test them against the contract and pick them with a second person's approval.
Products send tasks to a thin AI gateway of your own, which picks the model, falls back, checks the contract and only talks to allowed destinations. The main path goes to Google Vertex AI, with Gemini, Claude and Mistral, using the service's identity. A secondary keyed path goes to an external provider like OpenAI, and an operations console sits beside the gateway.
One main door with no keys, and a key only for the exception.

Why not an off-the-shelf gateway

There are three alternatives worth a look, and here they are next to the one I'm proposing:

Open source gateway that connects hundreds of providers with keysCostOne more piece to runRiskBrings the key problem backVerdictUseful if you need many providers outside the cloud
Apigee as an AI gatewayCostFixed cost, and operations built for companies with many APIsRiskDoesn't ship its own contract test or two-person approvalVerdictVery complete, built for a different scale
Gateway run by a third partyCostFastest to set upRiskYour users' data goes through another companyVerdictFast, at the price of your data leaving home
Vertex AI with your own thin gatewayCostTwo adapters and a console to maintainRiskDepends on Vertex AI; what isn't there goes through the keyed exceptionVerdictThe one I pick: Vertex AI brings the connection, the gateway brings what sets you apart

An open source gateway makes sense when you need many providers outside the cloud, but it brings the key problem back and adds one more piece to run. Apigee is Google's offering for routing and rate-limiting traffic to models, very complete, with a fixed cost and no contract test or two-person approval. A gateway run by a third party is the fastest to set up, and your users' data goes through another company.

Vertex AI brings the connection to the models, and your own thin gateway brings only what sets the product apart.

An easy mistake: hiding the model

It's tempting to keep the model catalog in a file loaded by script, with nicknames instead of real names, so nobody sees which model you use. That protects the trade secret from the outside and leaves whoever runs the platform blind: the AI can work perfectly and nobody knows which model answered, what it cost or how it did in testing.

The model's name stays out of the code and out of public docs, and in plain sight on the operator's screen.

What this approach costs

  • You depend on Vertex AI. Not every model on the market is there, and a new one may arrive later or in fewer regions. That's what the keyed family is for.
  • Every partner speaks differently. Gemini and Claude use different formats inside Vertex AI, and the adapter handles that through the format stored with each model.
  • You have to measure prices. Compare Claude's price inside Vertex AI with the direct one, and measure the real cost per use in every test.
  • There are human steps. Partner models get enabled once in Model Garden, accepting their terms, and they start with zero quota. Until you request quota, Vertex AI answers 429 even when the request is well formed.

What to keep

  • Before you build a model aggregator, check if your cloud already is one. On Google Cloud, Vertex AI is.
  • Count adapters by API family. If every new provider means new code, your architecture is measuring the wrong thing.
  • The trade secret stays out of the code and on the operator's screen.
  • Test against the real platform. Tests with doubles won't catch a missing project header or a quota set to zero.

It all sits behind a port you own: if another platform makes more sense tomorrow, one API family changes and no product notices.

When the next model you want to try comes out, will it get a new adapter, or a setting someone enables in the console?

Sign in to say it was useful

Notices

I let you know when I publish.

Conversation