Vercel AI Gateway Adds Virtual Models: One Stable Model ID per Task, Swapped Centrally, With Zero Data Retention the Gateway Enforces
Vercel's virtual models give each agent task one stable model ID, edited centrally at AI Gateway. Swaps propagate without redeploys; ZDR holds when the virtual model requires it.
Vercel introduced Virtual Models on AI Gateway on October 28, 2026. A virtual model is an abstraction of the model string and configuration your apps and agents use: you create one ID per task — the launch post’s example is vmc/coding-agent — assign it wherever that task runs, and manage the real model, its fallbacks and its data-handling rules from the gateway. Edit the virtual model and every caller picks up the new configuration within a few minutes, with no code change or redeploy (Vercel’s announcement; a changelog entry the same day confirms it is available now, not in preview).
The significance is not that switching models got easier — AI Gateway already made switching a one-line change. It is where that line lives, and who is allowed to change the rules attached to it.
The gap: ten new models a week, one line per app
Vercel counts 125 new models from more than 10 labs added to AI Gateway in the last 90 days — roughly 10 a week. Calling any of them by ID already routed each request to a healthy provider with failover. But the ID lived in your code, so every switch meant a redeploy, and a team running the same model string across a dozen agents and apps made that change a dozen times.
Virtual models move selection and configuration to the gateway. Create one from the team dashboard or the CLI:
vercel ai-gateway virtual-models create coding-agent \
--model anthropic/claude-opus-5.5 \
--config '{"speed":"fast","zeroDataRetention":true}'
Then pass the virtual model ID as the model string wherever the task runs:
const result = streamText({
model: 'vmc/coding-agent',
prompt: 'Remove the deprecated API calls from this module.',
});
Swapping the underlying model is one edit at the gateway — the post shows the same ID moving to openai/gpt-6.1-sol — and every app and agent that calls it picks up the change within a few minutes. For coding agents such as Claude Code and Codex, connect with vercel ai-gateway setup, then select your virtual model in each harness’s model picker or configuration.

Enforcement is the real feature
The governance rules matter more than the convenience. Settings on a virtual model win over the same settings in a request, so callers cannot override what the platform team chose:
| Setting | Who wins | Practical effect |
|---|---|---|
| Provider order, fallbacks, service tier | Virtual model | Every app on the ID shares one failover configuration; a request cannot change it |
zeroDataRetention, disallowPromptTraining |
Virtual model | When the virtual model requires ZDR or no-training providers, a request-level false does not opt out |
| Tags | Virtual model | Spend lands on the task no matter how each app tags its calls |
| Provider-specific options | Per provider | An Anthropic-specific setting stops applying when the ID points at another provider |
The ZDR row is conditional: Vercel describes enforcement when the virtual model itself requires Zero Data Retention or no-training providers, not as a default on every virtual model. That last row is the operational trap. The post tells you to review provider options whenever you switch providers, because the settings that shaped the old provider’s behavior do not travel with the virtual model.
The task ID also becomes the unit of audit. Anyone on the team can call a virtual model, team roles decide who can change it, and the Virtual Models page shows requests, spend and success rate per task — so cost attribution and access review happen at the level of the job, not the app or the API key. Vercel’s AI Gateway page separately describes Zero Data Retention as enforced on every request across a team, routing only to providers under a ZDR agreement.
The switch runbook Vercel recommends
Before pointing a production virtual model at a new model, point a second one — the post’s example is vmc/coding-agent-candidate — at the candidate model, run your evals against it, then flip the production ID. If quality drops, point the original back at the previous model. That is a canary pattern applied to model configuration: the blast radius of a bad model choice becomes one reviewed config edit, and so does the rollback.
Scope, pricing and what to verify
Virtual models work with every model type on AI Gateway — image, video, speech, embedding and realtime included — and with the AI SDK plus the OpenAI- and Anthropic-compatible APIs.
On pricing, the launch post’s statement that AI Gateway “reflects provider pricing with no markup and doesn’t charge a platform fee on inference, including on Bring Your Own Key (BYOK) requests” covers AI Gateway inference in general; the AI Gateway docs add that the gateway is available on all plans with zero markup on provider token prices. None of Vercel’s pages states which plans include virtual models or whether they are metered, and the product page’s pricing FAQ notes that certain capabilities are available at higher plan tiers and metered separately — plan coverage and metering for virtual models specifically are worth confirming in your own tenant.
Two further claims deserve verification before you rely on them. The “within a few minutes” propagation figure comes from the launch post; none of the sources we reviewed state a propagation guarantee. And enforcement against an explicit request-level zeroDataRetention: false is exactly the kind of guarantee to test once, reading the response metadata to confirm which provider served the request.
This extends the direction Vercel has been taking the gateway. Session affinity and per-session cost tracking made gateway-level observability reach coding agents; virtual models move the same control plane from observing calls to governing them — the consolidation we described in the agent gateway as the control plane for enterprise agents. Because model swaps now happen without deploys, the model-deprecation continuity drill shifts from rehearsing a redeploy to rehearsing a config edit and its eval gate. And for teams weighing what a gateway can and cannot govern, our zero-retention vs agent memory breakdown covers the part that stays outside the gateway.
Bottom line: virtual models turn a per-task model ID into the enforcement point for model choice, failover, spend attribution and data handling. For fleets running many agents through one gateway, that collapses changes that used to be N code edits and N redeploys into one reviewed, reversible configuration change.