Routes

Name the intent in your code; pin the model on the platform.

A Route is a tenant-prefixed name, like acme/support-chat, that your code sends in the model field. The Gateway resolves it to the model you have pinned server-side.

{ "model": "acme/support-chat", "messages": [...] }

Why route names instead of model ids

Model choice changes more often than application code should. With a Route, flipping a surface to a new model is an API call on the platform, not a pull request in your repo. Your code names the intent; the Route decides the model.

Fallbacks

A Route may declare an ordered fallback list. If the primary model cannot produce output because its provider is down or erroring, the Gateway tries your declared fallbacks in turn, so a single degraded model never fails the call.

This is not a silent swap:

• The served model is returned in the x-allocate-model response header.
• Fallbacks are billed at the served model's own price.
• A fallback only ever fires along the chain you declared. The platform never substitutes a model you did not choose.

Policy always wins

If your organization has a provider policy, it is enforced after route resolution: a request can never reach a provider outside your allowlist, whatever the route or the model field says. See Private Inference Cloud.