Your app summarizes support tickets with one model while your coding agent uses another. A cheaper option appears, but changing model IDs across repositories and redeploying just to test it is an expensive way to learn. Vercel AI Gateway Virtual Models, announced on October 28, 2026, put a stable name in front of the underlying model. You can point `vmc/support` to a candidate and switch back without editing app code. The important work is evaluating that candidate before moving real traffic.

Vercel's announcement and documentation say a virtual ID can also carry provider options, fallbacks, compliance settings, and observability tags. This differs from configuring a fallback for a failed request: the decision here is who controls the active model for a task and how it changes after an evaluation.

Example: triage support tickets without breaking the contract

Imagine an app that classifies support messages as `urgent`, `normal`, or `missing_context` and drafts a suggested reply. Its contract requires valid JSON, the right category, and no automatic response when context is missing. Create `vmc/support` for current traffic and `vmc/support-candidate` for the new model. Keep the first unchanged until the candidate passes the same tests.

In Vercel's dashboard, open Virtual Models, create a slug, and choose a model available in your catalog. The docs also show a CLI pattern. Check the active team with `vercel whoami` and `vercel switch` first because virtual models are created in the current scope:

vercel ai-gateway virtual-models create support --model anthropic/claude-opus-5.5

vercel ai-gateway virtual-models create support-candidate --model openai/gpt-6.1-sol

These model names and commands follow Vercel's examples; I did not execute them in a SoyJB account. Use two models your own account exposes. The virtual slug cannot be renamed after creation, so name it for a task rather than a provider. `vmc/support` should still make sense after a model change.

Connect the app and test the same cases

In AI SDK, the virtual ID goes where a model name normally goes. Configure AI Gateway authentication for your environment; never embed API keys in the sample or repository:

import { generateText } from 'ai';

const result = await generateText({
  model: 'vmc/support',
  prompt: 'Classify this ticket: I cannot access my account',
});
console.log(result.text);

Run the same 20 anonymized tickets against `vmc/support` and `vmc/support-candidate`. Include ambiguous messages and cases that must escalate to a person. Record valid-JSON rate, human-reviewed category accuracy, missed urgent cases, latency, and cost per resolved ticket. Token price alone is a weak proxy for product value. If output triggers actions, also test tool behavior and schema compatibility.

Once the candidate passes a threshold written before the test, switch the stable ID in the dashboard or with the documented command:

vercel ai-gateway virtual-models edit support --model openai/gpt-6.1-sol

Vercel says new requests adopt the configuration within a few minutes without redeployment. Watch metrics for the virtual ID and compare results over a comparable traffic window. If quality drops, point `vmc/support` back to the previous model. This configuration rollback cannot undo replies already sent, so use a gradual rollout in your own product for consequential customer-facing tasks.

Two limits that matter

Virtual-model settings take precedence over equivalent per-request settings. That can enforce approved providers or zero data retention, but surprise an app that expects to control fallbacks in code. Anthropic-specific provider options do not magically transfer to OpenAI when you switch providers. Recheck saved settings, tool calls, output formats, and data handling. Team roles govern who may edit the alias; grant that ability to the people responsible for the experiment.

A useful first step today is to prepare the 20-ticket dataset and acceptance criteria. I did not run the CLI or a paid model benchmark here, so I cannot claim either candidate is faster or cheaper for your app. The documented product feature separates the model ID in your code from the concrete model configured at the gateway. A business benefit depends on measured quality, cost, and operational friction in your workflow.

Sources

Vercel, October 28, 2026 announcement; Vercel Docs: Virtual Models. Reviewed November 10, 2026.