Model configuration, moved out of the codebase

Virtual Models on AI Gateway abstract the model string and its configuration into a named ID that applications and agents reference. Behind a single virtual model ID, a team can change the underlying model, set fallbacks and priority, and enforce Zero Data Retention. The configuration travels with the ID wherever it is used.

The intended pattern is to assign one virtual model ID to an agent task and pass that ID as the model string wherever the task runs. Subsequent model and settings changes happen in AI Gateway, and calling apps and agents adopt the new configuration automatically, with no code changes or redeploys.

Why a stable indirection layer

AI Gateway gained 125 new models from more than 10 labs in the last 90 days, roughly 10 per week. Calling any of them is already a one-line change — requests are routed by model ID to a healthy provider, with fallback to others on failure — but that line still lives in the application code, so switching generally requires a redeploy.

Virtual Models relocate both selection and configuration to the gateway. A task gets an ID such as vmc/coding-agent, and the model plus its settings are configured against it:

vercel ai-gateway virtual-models create coding-agent \
  --model anthropic/claude-opus-5.5 \
  --config '{"speed":"fast","zeroDataRetention":true}'

That ID then serves as the model string at every call site:

import { streamText } from 'ai';
const result = streamText({
  model: 'vmc/coding-agent',
  prompt: 'Remove the deprecated API calls from this module.',
});

For coding agents including Claude Code and Codex, connect them via vercel ai-gateway setup and choose the virtual model in each harness's model picker or configuration. When a different model becomes available, including one from another provider, editing the virtual model propagates to every app and agent calling that ID within a few minutes:

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

Per-task models and safe transitions

Workloads differ in shape: support ticket triage may run hundreds of times an hour and needs to be inexpensive, while legal contract review may run a few times a day and needs strong reasoning. Each task can now have its own purpose-built virtual model that evolves over time, with fallbacks, Zero Data Retention, and tags carried along when the model changes.

Provider options are an exception to that portability: they apply per provider, so an Anthropic-specific setting ceases to apply once the virtual model points at an OpenAI model. Provider options should be reviewed on every provider switch.

For production traffic, the suggested rollout is a second virtual model — say vmc/coding-agent-candidate — aimed at the new model and exercised with your evals. If quality regresses after the switch, the original can be pointed back at the previous model.

Central governance and reporting

Any team member can call a virtual model; team roles determine who can modify one. This lets platform and security teams own models and settings while teams still get access to new releases quickly.

Settings defined on a virtual model take precedence over the same settings in a request, so callers cannot override the chosen provider order, fallbacks, or service tier. Fallback models for something like vmc/storefront-assistant can be fixed centrally, and every app using that ID inherits the same failover behavior even if a request asks for different fallbacks. Likewise, where a virtual model requires Zero Data Retention or providers that don't train on request data, those requirements hold even if a request explicitly sets zeroDataRetention or disallowPromptTraining to false. Tags on the virtual model replace any tags sent with the request, so spend is attributed to the task regardless of how each app tags its calls. The Virtual Models page reports requests, spend, and success rate per task.

Availability and setup

Virtual models can be created from the team dashboard or with the Vercel CLI. They work with every model type on AI Gateway — image, video, speech, embedding, and realtime — and with the AI SDK and the OpenAI- and Anthropic-compatible APIs. The Virtual Models documentation covers every setting.

AI Gateway itself provides a unified API for calling models, tracking usage and cost, and configuring retries, failover, and performance optimizations for higher-than-provider uptime. It includes custom reporting, Zero Data Retention support, budgets for API keys, and routing rules. Pricing reflects provider rates with no markup and no platform fee on inference, including Bring Your Own Key requests.