Choose a Provider

Purpose and Scope

Choosing a provider is the first practical decision in an AI SDK project because it determines how your application authenticates, how model identifiers are written, and which model capabilities are available. The AI SDK is designed to reduce the long-term cost of that decision: application code calls the same core functions, such as text generation, while the model value can come from Vercel AI Gateway, a dedicated provider package, an OpenAI-compatible service, a community provider, or a custom provider. This page explains the default path for new projects and the tradeoffs behind direct provider setup.

Sources: content/docs/02-getting-started/00-choosing-a-provider.mdx, content/docs/02-foundations/02-providers-and-models.mdx, packages/ai/README.md

Relevant Source Files

• content/docs/02-getting-started/00-choosing-a-provider.mdx — The first-party getting-started page that presents the provider decision, Gateway setup, dedicated provider installation, global provider behavior, and custom provider example.
• content/docs/02-foundations/02-providers-and-models.mdx — The foundations page that defines providers, models, vendor lock-in concerns, the unified language model specification, and the list of first-party, OpenAI-compatible, and community provider categories.
• packages/ai/README.md — The package README that describes the AI SDK as a provider-agnostic TypeScript toolkit, states the Node.js requirement, shows the default Gateway model-string workflow, and shows direct provider package usage.

Core Decision Model

The recommended first choice for most readers is Vercel AI Gateway. The getting-started provider page calls Gateway the fastest way to begin because it can access models from OpenAI, Anthropic, Google, and other providers while letting application code pass a plain model string. The package README reinforces that this is the default provider behavior for the main package: examples call generation functions with strings such as an Anthropic, OpenAI, or Google model identifier. That means a new project can install the core package, configure Gateway credentials, and postpone dedicated provider package choices until it has a specific reason.

Sources: content/docs/02-getting-started/00-choosing-a-provider.mdx, packages/ai/README.md

A dedicated provider package is the better starting point when your application needs a provider-specific account, provider-specific model naming, or capabilities exposed through that package. The getting-started page demonstrates this with Anthropic: install the package, import the provider factory, and pass the provider-created model to the same AI SDK call. The important distinction is not the outer generation API, which remains unified, but the source of the model object. Direct provider packages make provider setup explicit and can be useful when teams already manage separate vendor credentials or want to use provider-specific tools and options.

Sources: content/docs/02-getting-started/00-choosing-a-provider.mdx, packages/ai/README.md

The foundations page explains why the provider abstraction exists. Providers such as OpenAI and Anthropic expose different APIs, model catalogs, and configuration surfaces, and those differences can make switching expensive. AI SDK Core standardizes access through a language model specification so the same high-level application code can target different providers. The practical takeaway is that provider choice affects authentication and model selection more than the shape of common calls. You should still evaluate model quality, latency, price, and feature support, but you do not need to rewrite the entire application just to try another provider.

Sources: content/docs/02-foundations/02-providers-and-models.mdx

Provider Paths and Setup

There are three common setup paths. The first is Gateway with string model identifiers, which uses the AI Gateway as the global provider and requires an AI Gateway API key or supported deployment authentication. The second is direct provider installation, where packages such as the Anthropic provider are installed and imported in application code. The third is custom provider integration, where a provider implementation follows the AI SDK language model specification. These paths are intentionally compatible with the same generation functions, so a team can prototype with Gateway, harden with a direct package, or add an internal provider later.

Sources: content/docs/02-getting-started/00-choosing-a-provider.mdx, content/docs/02-foundations/02-providers-and-models.mdx

AI_GATEWAY_API_KEY=your_api_key_here

import { generateText } from 'ai';
 
const { text } = await generateText({
  model: 'anthropic/claude-sonnet-4.5',
  prompt: 'What is love?',
});

When using Gateway, model access is expressed as a provider-qualified string. That string is concise, easy to pass through configuration, and works because Gateway is documented as the default global provider. The getting-started page also shows an explicit Gateway import for teams that prefer provider factories over bare strings. This matters in larger applications where central configuration, provider registries, or aliases may be introduced later. Starting with a string does not prevent a future move to an explicit provider object; both represent model selection for the same AI SDK Core call surface.

Sources: content/docs/02-getting-started/00-choosing-a-provider.mdx

npm install @ai-sdk/anthropic

import { anthropic } from '@ai-sdk/anthropic';
 
const model = anthropic('claude-sonnet-4-5');

Direct providers make installation and imports part of the application boundary. The package README gives the broader pattern by showing dedicated installs for OpenAI, Anthropic, and Google and then creating a model with a provider function. The getting-started page uses the same idea for Anthropic specifically. Choose this path when your operations team wants separate vendor credentials, when the provider package documents specialized capabilities, or when you want to make provider ownership obvious in source code. The tradeoff is additional package management and per-provider setup instructions instead of Gateway’s single access layer.

Sources: content/docs/02-getting-started/00-choosing-a-provider.mdx, packages/ai/README.md

System-to-Code Mapping

The mapping also shows what not to optimize too early. If your first milestone is a chatbot, agent prototype, or server-side generation route, Gateway keeps provider setup small and lets the rest of the application focus on prompts, messages, tools, and streaming behavior. If the milestone is a production integration with a specific vendor contract, start with that direct provider so authentication, billing, and model naming match the target environment from day one. In both cases, keep model selection centralized so future changes are a configuration decision rather than a codebase-wide edit.

Sources: content/docs/02-getting-started/00-choosing-a-provider.mdx, packages/ai/README.md

Provider Categories

The foundations provider list is broader than just chat completions. It names first-party AI SDK providers for language-model vendors and also points to OpenAI-compatible and community providers. This categorization helps readers avoid treating every integration as the same kind of dependency. A first-party provider package is maintained in the AI SDK ecosystem and follows the shared public contract. An OpenAI-compatible provider targets services that expose an API shaped like OpenAI’s. A community provider can be the right fit for local models, platform-specific APIs, or integrations that are useful but maintained outside the core provider set.

Sources: content/docs/02-foundations/02-providers-and-models.mdx

Custom providers are the extension point when none of the existing packages match your service. The getting-started page shows a custom provider imported from an application-defined package and passed into the same text-generation call. The foundations page connects that capability to the published language model specification. For readers, the important constraint is compatibility: a custom provider should behave like a language model provider from the perspective of AI SDK Core. That lets application code continue to use the same generation, streaming, tool-calling, and structured-output workflows as it would with first-party providers.

Sources: content/docs/02-getting-started/00-choosing-a-provider.mdx, content/docs/02-foundations/02-providers-and-models.mdx

Practical Selection Checklist

Use Gateway first when you need the shortest route to a working application, want to compare multiple vendors, or prefer one authentication layer for major providers. Use a dedicated provider first when you already know the target vendor, need explicit provider package behavior, or want source code to reveal the exact vendor dependency. Use an OpenAI-compatible or community provider when your model endpoint lives outside the first-party catalog. Use a custom provider when you control the service or need an integration that should participate in the same AI SDK Core interface as the built-in providers.

Sources: content/docs/02-getting-started/00-choosing-a-provider.mdx, content/docs/02-foundations/02-providers-and-models.mdx

After choosing a provider path, install the main package, add any dedicated provider package if needed, configure credentials, and make one minimal generation call before adding UI, tools, or agents. Keep the first test small: a single prompt proves that authentication, model naming, and the provider boundary are correct. Then move to provider management if you need aliases, a central registry, or a changed global provider. From there, continue to the provider and model foundations page for architecture, or the getting-started framework pages for Next.js, Svelte, Nuxt, Node.js, Expo, or TanStack Start integration.

Sources: content/docs/02-getting-started/00-choosing-a-provider.mdx, content/docs/02-foundations/02-providers-and-models.mdx, packages/ai/README.md