On 28 October 2026 Vercel launched Virtual Models on its AI Gateway. The feature itself is Vercel's to sell, but the number Vercel used to justify it is worth a look by anyone who builds software that calls AI models: "In the last 90 days, 125 new models from more than 10 labs became available on AI Gateway. That adds up to about 10 a week."
That is Vercel's count of its own catalogue, not a census of the industry, and it's published as the case for a product. But even as a rough signal, it raises a design question: where in your system does the choice of model live?
The problem with a model name in your code
Most AI features start the same way: a model name typed into the code where the request is made. Vercel describes the limit of that plainly. Its gateway "already makes switching a one-line change", but "That one line still lives in your code, so switching usually means a redeploy."
That sounds minor until you multiply it. If a better or cheaper model appears, or the one you use is retired, or a provider has an outage, the change goes through your whole release process: a code edit, a review, a build, a deploy. Your release schedule ends up tied to vendors' release calendars, which you don't control.
Indirection: one name, configured elsewhere
The general fix is old and simple: give each task its own name, and decide elsewhere which model that name points to. Vercel's version is a virtual model ID such as vmc/coding-agent, which the code uses in place of the provider's model ID. In Vercel's words: "With a single virtual model ID, you can change and update models, configure fallbacks and priority, and enforce Zero Data Retention centrally."
The same pattern works without any particular product: a config file, an environment variable, or your own small routing layer that maps "contract-review" or "ticket-triage" to a model. What you gain is the same:
- Swapping models without a code change. The task name stays put; what it points to changes.
- A model per task. A high-volume task can use something cheap and fast, a rare high-stakes one something stronger, each chosen deliberately.
- Policy in one place. Fallbacks, data-retention rules and provider restrictions set once, instead of copied into every call. Vercel says settings on a virtual model win over the same settings in a request, so individual callers can't quietly override them.
- Costs you can attribute. If every call names its task, spend can be reported per task rather than as one blended bill.
What you take on
Indirection isn't free, and the trade-off is the honest core of this decision.
- A change with no deploy also has no diff in your repo. When the model behind a name changes in a dashboard or a config store, it doesn't go through the code review and history your team already relies on. Decide who can change it, and make sure changes are logged and visible.
- Someone else's system now decides which model answers. With a hosted gateway, that's a dependency and a place to look when behaviour changes. With your own config layer, it's code you maintain.
- A new model is a behaviour change. Same task name, different answers. Vercel's own advice is sound here: before switching a virtual model that serves production traffic, point a second one at the new model and "run your evals against it", and if quality drops, point the original back.
- Provider-specific settings don't travel. Vercel notes that a setting specific to one provider stops applying when you switch to another, and says to review them on every switch.
A sensible default
Name tasks, not models, in your code. Keep the mapping from task to model in one place, versioned and reviewable. Change it on purpose, after evals, with a quick way back. That's true whether the mapping lives in a gateway or in a file in your own repository.
It's also the natural companion to choosing the model in the first place, which we wrote about in A 2015 Model Beat Two 2026 LLMs at One Narrow Task. Picking the right model for a task is one decision. Making sure you can change that decision without a release is the next one.
Sources: Vercel, "Introducing Virtual Models on AI Gateway" and the changelog entry (both 28 October 2026, read 29 October 2026). The 125-model figure is Vercel's count of models added to its own gateway.