Stop writing model names into code: Vercel AI Gateway's Virtual Models

The short version

On October 28, 2026, Vercel shipped Virtual Models on AI Gateway. The idea is simple: give each task a fixed model ID, such as vmc/coding-agent, and let apps and agents call only that ID. Which underlying model is used, which fallbacks apply, and which compliance settings hold are all changed centrally in AI Gateway. Switching models no longer requires a code change or a redeploy; every caller picks up the new configuration within minutes.

This sounds like a small configuration improvement, but it lands on a problem that is getting expensive. Vercel's launch post reports that 125 new models from more than 10 labs became available on AI Gateway in the last 90 days — roughly 10 a week. Model generations are now arriving faster than most teams can change code and ship releases. When "switch to a better model" drops from a release to a configuration edit, a team's model strategy can finally keep pace with model releases.

Two boundaries first. Virtual Models are not a new model: a virtual model is an alias pointing at a model plus a configuration, and it does no reasoning of its own. The actual work is still done by the underlying model from Anthropic, OpenAI, or another provider. And this is not the same story as an earlier site article on Vercel AI Gateway's stealth inference model Glyph Cluster: that one covered a single new model launching with a free period, while this one covers the general mechanism for managing all models. The two complement each other but should not be conflated.

What a virtual model actually is

Vercel's own example explains it best. A team creates a virtual model with vercel ai-gateway virtual-models create coding-agent, pointing it at anthropic/claude-opus-5.5 with fast mode and Zero Data Retention enabled. From then on, application code no longer names the vendor model; it names vmc/coding-agent. In the AI SDK, the call looks like streamText with model set to vmc/coding-agent, and nothing else changes.

When the team later wants a different model, it runs vercel ai-gateway virtual-models edit coding-agent --model openai/gpt-6.1-sol. Every app and agent calling vmc/coding-agent picks up the new configuration within a few minutes, with no code change and no deployment. For coding agents such as Claude Code and Codex, the team connects them with vercel ai-gateway setup first, then selects the virtual model in each harness's model picker or configuration.

A virtual model ID carries more than a model name. It bundles reasoning effort, fast mode, prompt caching, fallback models and their priority, Zero Data Retention and similar compliance requirements, and custom reporting tags for cost attribution. In other words, it turns the decision "which model should this task use, and how should it be called" from strings scattered across codebases into a named, auditable, reversible entity on the platform. When the task changes, you edit the task's configuration; when the model changes, you repoint the model. The two are no longer tied to the same code release.

Why this matters most for agent teams

The launch post contrasts two tasks. Support ticket triage might run hundreds of times an hour and needs to be cheap; legal contract review might run a few times a day but demands the strongest reasoning available. If every task shares one model name, either the cheap task burns money or the critical task is underpowered. With virtual models, each task gets its own — vmc/support-triage, vmc/contract-review — each bound to a different model and configuration, each evolving independently.

For agent teams there is a more practical layer. An agent's model choice is often buried in framework settings, prompt templates, and client configurations, and changing it pulls many threads at once. Virtual models move that choice to the gateway layer, so a platform team can do several things without touching agent code: upgrade a task's model across the board, tighten a task's data-retention policy, or add fallback models to a task. The agent's behavior changes, but the agent's code does not — exactly the control point a platform team wants.

Cost attribution is another underestimated benefit. Tags on a virtual model replace any tags sent with a request, so no matter how individual apps tag their calls, spend lands on the task. The Virtual Models page shows requests, spend, and success rate per task. For a team running dozens of agent tasks, that means month-end reconciliation no longer relies on guesswork: what each task cost and how reliably it ran is visible at task granularity.

Three hard rules: the virtual model wins, the request loses

Three "platform wins" rules define how virtual models behave, and using them correctly starts with understanding these rules. First, settings on a virtual model win over the same settings in a request. A caller cannot override the platform's fallback order or service tier by writing different values into its request — the failover configuration chosen centrally applies to every caller.

Second, compliance requirements are enforced even against explicit requests to the contrary. If a virtual model requires Zero Data Retention, or requires providers that do not train on request data, those configurations hold even if a request explicitly sets zeroDataRetention or disallowPromptTraining to false. The goal is clear: compliance red lines cannot rest on each caller's good behavior; they must be held by the platform layer.

Third, tags are replaced. Request tags are overwritten by the virtual model's tags, so spend always attributes to the task. Taken together, these rules communicate a stance: a virtual model is not a convenience alias for callers, but a governance instrument for platform teams. Convenience is the outcome; governance is the purpose.

Before switching, build a candidate: the recommended rollout

The launch post's recommended switching flow deserves attention on its own, because it reveals how virtual models are actually meant to be used. Do not repoint the production virtual model at a new model directly. Instead, create a second virtual model — vmc/coding-agent-candidate, for example — point it at the new model, and run your evals against it. Only then switch the production virtual model over. If quality drops after the switch, point the original back at the previous model.

Three points in this flow are worth noting. First, evaluation is a precondition for switching, not a post-hoc remedy. Virtual models make switching cheaper, and precisely because switching is cheaper, the temptation to skip evaluation is greater. Second, rollback uses the same mechanism as switching: change one configuration pointer, effective within minutes, with no need to redeploy an old code version. Third, the candidate and the production virtual model are separate entities, so evaluation traffic and production traffic carry separate cost attribution and never mix on the bill.

One more gotcha: provider-specific settings stop applying when you switch providers. The launch post warns explicitly that an Anthropic-specific setting stops applying once the virtual model points at an OpenAI model, and that provider options should be reviewed on every provider switch. The subtext is that virtual models abstract "which model a task uses," not "a universal semantics for all vendor behavior." Cross-provider switches still need a human pass over configuration differences; the platform will not translate them for you.

What virtual models do not solve

Pulling model names out of code has costs. First, the configuration layer itself becomes a critical dependency: one bad gateway configuration change hits every caller at once, whereas a bad code change used to hit only the service that shipped it. Configuration changes need the same review, gradual rollout, and rollback discipline as code — only the reviewed artifact is now configuration, not code. Second, configuration drift does not disappear; it relocates. A task's virtual model — its model, fallbacks, tags, compliance items — evolves over time, and eventually only its original creator may remember why it is configured the way it is. Regular audits of the virtual model inventory should become routine platform work.

Third, virtual models do not solve evaluation itself. They make "changing models" cheap, but they do not tell you whether the new model is better. Eval sets, regression tests, and live quality monitoring still have to be built by the team. Fourth, they do not change pricing fundamentals: AI Gateway reflects provider pricing with no markup and no platform fee on inference, including bring-your-own-key requests. Virtual models reorganize how pricing is attributed; they do not flatten the cost curve of the models themselves.

Finally, there is a scope boundary. Virtual models 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. But they remain an abstraction inside the Vercel ecosystem. If your agents also run across other gateways and clouds, virtual models govern only the Vercel segment; cross-platform model governance still needs a higher-level agreement.

What vibe builders should take away

If you are vibe-building solo or in a small team, the most portable lesson from virtual models is not the Vercel product itself but a habit: do not hardcode model names into business code. Even without AI Gateway, give each agent task a task-level name and carry the model choice in an environment variable or a single centralized configuration. The payoff appears the moment model generations turn over: evaluating a new model means editing one configuration entry, not searching the codebase for model name strings.

Whether to adopt Vercel's virtual models specifically can be judged in three tiers. For a solo project with two or three tasks, environment variables are enough, and a gateway layer adds something else to maintain. Once tasks multiply, or once you already use AI Gateway for unified calls and cost tracking, virtual models are a natural next step. And when a platform team needs to govern models, compliance, and cost attribution centrally, the three hard rules — settings win, compliance enforced, tags replaced — are where the value really starts.

One timing observation closes the loop. The launch post notes 125 new models in 90 days, about 10 a week. At that pace, "pick a model and keep it for years" is no longer a realistic strategy. Model selection is turning from a one-time decision into continuous operations: regular evaluation, regular switching, regular rollback. The value of tools like virtual models is not that they make any single switch easy, but that they make continuous switching manageable.

Sources and scope note

The primary sources for this article are Vercel's official blog post "Introducing Virtual Models on AI Gateway" and its official changelog entry "Virtual models now available on AI Gateway," both read in full via browser.open. The publication date is given as October 28, 2026: the third-party deployment log deployedbyai marks the release as published on Wednesday, October 28, 2026, and the independent tracker techseen records its first read at 16:05 PDT on October 28. Vercel's own pages do not render a date in a text fetch, so the date rests on same-day third-party records; the publishing agent may recheck page metadata before release. All feature descriptions, commands, example model names, and figures such as 125 models, 10+ labs, and 90 days follow Vercel's launch post, and "within a few minutes" is the launch post's own wording. An earlier site article on Vercel AI Gateway's Glyph Cluster covered a single stealth inference model; this article covers the general mechanism for managing all models, and the two are scoped apart.