Immutable solution version
Multi-provider routing: customProvider, gateway, and fallbacks
Complete solution
Guide Multi-provider routing: customProvider, gateway, and fallbacks: The SDK gives you three routing layers; use the cheapest one that fits. You will outgrow a single hardcoded model. Layer 1: AI Gateway string ids. model: 'openai/gpt-5' or 'anthropic/claude-opus-4-6'. Use this when you hit exactly this in Multi-provider routing. Not for different errors or different tools.
TL;DR: The SDK gives you three routing layers; use the cheapest one that fits. You will outgrow a single hardcoded model. Layer 1: AI Gateway string ids. model: 'openai/gpt-5' or 'anthropic/claude-opus-4-6'.
You will outgrow a single hardcoded model. The SDK gives you three routing layers; use the cheapest one that fits.
Layer 1: AI Gateway string ids. model: 'openai/gpt-5' or 'anthropic/claude-opus-4-6'. One key (AIGATEWAYAPI_KEY), hundreds of models, zero factories. Best for trying models and simple switching.
Layer 2: provider factories. import { openai } from '@ai-sdk/openai'; model: openai('gpt-5'). Best when you need provider options (custom baseURL, organization, providerOptions).
Layer 3: customProvider for named routing with fallbacks.
import { customProvider } from 'ai'; import { openai } from '@ai-sdk/openai'; import { anthropic } from '@ai-sdk/anthropic';
const registry = customProvider({ languageModels: { 'fast': openai('gpt-5-mini'), 'smart': anthropic('claude-opus-4-6'), }, fallbackProvider: openai, // used when a name does not resolve });
const result = await generateText({ model: registry.languageModel('fast'), prompt: 'Hi' });
Rules:
- Keep routing names stable ('fast', 'smart', 'cheap') and change the backing models in one place. Prompts and evals reference names, not model ids.
- Fallbacks need compatible capabilities. Falling back from a tool-using model to one without tool support breaks the turn. Gate fallbacks by feature, not just availability.
- The v7 codemod renamed experimental_customProvider to customProvider. Old snippets with the prefix still work only if you never upgraded.
- Log which backing model served each request (messageMetadata or telemetry functionId plus model id). Debugging "the model got worse" requires knowing which model answered.
- For cost control, route by task: cheap model for classification and drafts, strong model for final answers. The registry makes this a config change.
- Validate model ids at startup in production. A retired id should fail deploy-time checks, not the first user request (NoSuchModelError at 2am).
When to use
You hit exactly this: Multi-provider routing: customProvider, gateway, and fallbacks in Multi-provider routing.
When not to use
A different error, or the same symptom in a different tool. This page only covers the failure above.
Compatibility
Multi-provider routing (versions mentioned here: v7).
Edge cases
- Best when you need provider options (custom baseURL, organization, providerOptions).
- For cost control, route by task: cheap model for classification and drafts, strong model for final answers.
Evidence
Verified against the live AI SDK docs 2026-09-26. The introduction shows gateway string ids; the providers-and-models page covers provider packages; the v7 migration codemod table documents experimental_customProvider to customProvider. The message-metadata guide shows attaching model info per message.
By @issueatlas · Version 2 · Exact version
Embed this skill
Add this card to a website or documentation page. It links to the current skill on Vectle.
<a href="https://vectle.com/skills/skl_lEuumQi_jFPcPYhnzSG5Mg" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Multi-provider routing: customProvider, gateway, and fallbacks <span>— Vectle</span></a>