Vercel AI Gateway Adds Routing Rules for Model Swaps and Bans

Vercel has added routing rules to its AI Gateway, giving teams a way to control which models are actually used without touching application code. According to the announcement, the feature is in beta now.

The problem it solves

If you've hardcoded a model name in your app and that model gets deprecated or goes down, someone has to ship a code change to move traffic elsewhere. That's slow, and it happens at the worst time — usually mid-incident. Routing rules move that decision to the gateway layer, so a single rule change reroutes every request instantly, across your whole team.

Two types of rules

Routing rules come in two flavors:

• Rewrite — serves a request for one model using a different model. The gateway swaps the destination in transparently, so the application keeps requesting the original model name. Vercel lists several use cases: keeping traffic flowing when a model is unavailable, migrating off a retired model, standardizing the team on one model, or routing an expensive model to a cheaper one.
• Deny — blocks requests for a specific model outright. Requests return a 403. This is meant for keeping a team off models that haven't been approved.

Both are described as "firewall-style" — set once, enforced everywhere, rather than scattered across if/else logic in application code.

How rules are applied

Routing rules apply to every request made with a team's AI Gateway credentials, which means they're a team-wide control point rather than a per-project setting. You manage them through the Vercel CLI. Creating a rewrite looks like this:

vercel ai-gateway rules add --type rewrite \
  --source anthropic/claude-opus-4.8 \
  --destination anthropic/claude-haiku-4.5

And a deny rule:

vercel ai-gateway rules add --type deny --source openai/gpt-5.5

Importantly, a routing rule only changes which model actually serves the request. Everything else you've already configured for that request still applies to the destination model. That includes request-level settings — BYOK, model fallbacks, sorting, the "only" filter, and provider options — as well as team-level settings like Zero Data Retention and the provider allowlist. So swapping Claude Opus for Claude Haiku via a rewrite doesn't quietly drop your data retention policy or fallback chain; those carry over to whichever model ends up serving the request.

Why this matters for gateway design

The underlying shift here is treating model selection as infrastructure configuration rather than application logic. Teams building on multiple LLM providers already deal with models being deprecated, rate-limited, or priced differently over time. Baking that logic into the code means every model change is a deploy. Baking it into the gateway means it's a config change — closer to how a load balancer or a firewall rule works, and consistent with the