Google Cloud API Gateway added model routing in public preview on August 4, a serverless ingress layer that takes in OpenAI-compatible chat requests and forwards each one to Gemini, Anthropic’s Claude, or an open-weight OpenAI OSS-GPT model, all hosted on Vertex AI. Developers pick the destination through configuration rather than by wiring a separate client for each provider’s SDK. That single choice says something about which API shape won.
Google did not have to build it this way. It could have asked developers to adopt a Gemini-native request format and pushed Claude or GPT traffic through a translation layer bolted on afterward. Instead the entry point speaks OpenAI’s schema natively, and Gemini is just one of three destinations behind it, alongside a rival’s flagship model. When the company that owns the largest cloud AI platform standardizes its ingress on a competitor’s request format, that is a concession about which interface became the default that developers already write to.
The mechanics are straightforward. A developer adds an x-google-api-management block to the OpenAPI 3.x spec and lists an address, a deadline, and a pathTranslation setting under it for each model. In the example Google published, that includes gemini-3.5-flash-lite reached through generateContent, claude-opus-4-7 reached through rawPredict, and an open-weight gpt-oss-120b model reached through a chat completions endpoint, all addressed at aiplatform.googleapis.com. A router block then maps a default model plus override rules to specific backends, and a path in the spec (for example /v1/chat/gemini-claude) gets tagged with an x-google-model-router reference. One limitation follows directly from that design: every model a single router can reach has to live behind the same base address, since what changes between options is only the model name and path appended to that one Vertex AI endpoint, not the server it points at.
Once deployed, the application only ever sends a standard OpenAI-style POST request, with a model field and a messages array, to that gateway path. The Gateway intercepts the call, transcodes the payload into whatever native schema the chosen backend expects, and forwards it. Google’s own curl example targets a Claude Opus 4.7 backend by simply naming "model": "claude-opus-4-7" in an otherwise unremarkable chat payload. The post did not disclose pricing, quota limits, or rate-limit thresholds for the feature; it describes token tracking and rate limiting as available capabilities without giving numbers.
Google frames this as optional infrastructure: API Gateway can run standalone for rate limiting and usage tracking, or sit alongside the Gemini Enterprise Agent Platform, with an Agent Gateway handling outbound security governance before requests hit the model router. That pairing matters more for enterprise buyers already committed to Google’s agent stack than for a solo developer testing model choices.
This is public preview, not general availability. Google gives no service-level agreement for it, and the configuration surface, supported models, and routing behavior can all change before it ships broadly. Teams should treat any production dependency on it as provisional.
For a builder, what this buys over a client-side router or an existing open-source proxy is one thing: the routing logic lives in infrastructure Google already operates, versioned inside the same OpenAPI spec as the rest of an API, rather than in a process a team has to run and patch. What it costs is a Google request in the path of every model call, including calls meant for a competitor’s model, plus a preview-stage dependency with no committed stability guarantee. Teams evaluating multi-model routing this quarter should weigh that trade before pointing production traffic at claude-opus-4-7 through someone else’s gateway.
Google published this guide to API Gateway’s public preview of model routing on August 4, 2026, written by Mak Ahmad and Sanjay Pujare.
