Skip to main content
Applicable to: Users who manage routing rules in AI Gateway → Models → Policies → Routing Config, or who apply gateway-load-balancing-config YAML via tfy apply. If you already use Virtual Models for routing, this change does not affect you.

What Is Changing

The global Routing Config — the tenant-level YAML file (type: gateway-load-balancing-config) that defines load balancing, fallback, and retry rules across all requests — is deprecated. It will be fully removed in a future release. Existing routing configurations will continue to work during the transition period. No changes are required immediately, but we strongly encourage migrating to Virtual Models before the removal date.

Why This Change

Virtual Models supersede the global routing config in every way:
  • Per-model ownership — each virtual model is an independent, named resource rather than a rule buried in a shared YAML file.
  • Access control — you can grant teams access to specific virtual models without exposing the full routing config.
  • Simpler mental model — routing targets, strategies, retries, and fallbacks are configured on the model itself, not matched via a rule evaluated at request time.
  • Full feature parity — weight-based, priority-based, and latency-based routing; per-target retries, fallbacks, header overrides, and metadata filtering are all supported on virtual models.

What You Need to Do

1

Identify all active routing rules

Open AI Gateway → Configs → Routing Config and note every rule — the models it matches on, the routing strategy, targets, weights/priorities, retries, and fallbacks.
2

Create a Virtual Model for each distinct model

For every model name your applications send (the models field in a routing rule), create a corresponding Virtual Model with the same routing strategy and targets.See Virtual Models for the full configuration guide.
3

Handle subject- and metadata-based rules

If existing rules filter on subjects or metadata, create separate virtual models per team or environment — for example booking-app/gpt-prod and booking-app/gpt-dev — instead of a single shared rule.
4

Point clients at the Virtual Model

Update your applications to use the virtual model name or its slug instead of the original model name.
5

Validate and remove the old routing rules

Test end-to-end in staging, then remove or empty the global routing config once traffic is fully on virtual models.

Migration Guidance

The full migration walkthrough — including a step-by-step translation of common rule patterns (priority chains, canary rollouts, environment-based routing) into virtual model configuration — is available on the Routing Config page.

Timeline

MilestoneDate
Deprecation announcement8th June, 2026
Routing Config fully removed15th June, 2026
We strongly encourage migrating to Virtual Models well ahead of the removal date to avoid disruptions to your routing and fallback workflows.

If you have questions or need help migrating your routing rules to Virtual Models, reach out to support@truefoundry.com — we’re happy to assist.