> ## Documentation Index
> Fetch the complete documentation index at: https://www.truefoundry.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Deprecation of Routing Config

> The global Routing Config is deprecated in favour of Virtual Models. Existing configurations continue to work during the transition period.

<Warning>
  **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.
</Warning>

## 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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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](/docs/ai-gateway/virtual-model) for the full configuration guide.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Point clients at the Virtual Model">
    Update your applications to use the virtual model name or its [slug](/docs/ai-gateway/virtual-model-advanced#virtual-model-slugs) instead of the original model name.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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](/docs/ai-gateway/load-balancing-overview#migrating-to-virtual-models) page.

## Timeline

| Milestone                    | Date                |
| ---------------------------- | ------------------- |
| Deprecation announcement     | 8th June, 2026      |
| Routing Config fully removed | **15th June, 2026** |

<Warning>
  We strongly encourage migrating to Virtual Models well ahead of the removal date to avoid disruptions to your routing and fallback workflows.
</Warning>

***

If you have questions or need help migrating your routing rules to Virtual Models, reach out to [**support@truefoundry.com**](mailto:support@truefoundry.com) — we're happy to assist.