Language Model Providers

Purpose and Scope

Language model providers are the adapter packages that let AI SDK Core call different hosted model APIs through the same application-facing functions. In everyday use, your app imports a provider instance, calls it with a model identifier or deployment name, and passes the resulting model into generateText, streamText, structured generation, or agent APIs. The important design point is that provider choice affects authentication, model IDs, endpoint routing, and provider-specific options, but it does not usually change the core generation workflow. Sources: content/providers/01-ai-sdk-providers/04-azure.mdx, packages/azure/README.md

This page groups the major language model providers by the common pattern they expose rather than by every package implementation detail. OpenAI, Anthropic, Google, Azure OpenAI, Amazon Bedrock, xAI, Groq, Cohere, and Mistral are all documented as AI SDK providers, and the public examples consistently show provider functions being used as model factories. For a first integration, choose the provider whose models, account requirements, latency, and deployment environment match your product, then keep the rest of your code on the provider-agnostic AI SDK Core surface.

Relevant Source Files

• content/providers/01-ai-sdk-providers/04-azure.mdx — Documents the Azure OpenAI provider setup, provider instance creation, Microsoft Entra ID token-provider authentication, instance options, URL construction, and the language-model factory call.
• packages/azure/README.md — Shows the package-level Azure provider install command, default azure import, generateText example, and AI Gateway note.
• packages/anthropic/README.md — Shows the Anthropic provider package, default anthropic import, Messages API positioning, and generateText usage.
• packages/amazon-bedrock/README.md — Documents Bedrock provider setup, bedrock import, Converse API support, API-key and SigV4 authentication precedence, and examples.
• packages/cohere/README.md — Shows Cohere provider setup, default cohere import, and a language model call with command-r-plus.
• packages/anthropic-aws/README.md — Documents Claude Platform on AWS as an Anthropic-compatible provider hosted in AWS with SigV4 or AWS-provisioned API-key authentication.

Shared Usage Pattern

The shared provider pattern has three steps. First, install the provider package when you are not using AI Gateway. Second, import the default provider instance or a factory such as Azure’s createAzure when you need custom settings. Third, call the provider instance with the model ID or deployment name and pass that model into an AI SDK Core function. Azure’s docs make the model-factory contract explicit: azure('your-deployment-name') creates a language model, and the first argument is the Azure deployment name. Sources: content/providers/01-ai-sdk-providers/04-azure.mdx

import { azure } from '@ai-sdk/azure';
import { generateText } from 'ai';
 
const { text } = await generateText({
  model: azure('gpt-4o'), // your deployment name
  prompt: 'Write a vegetarian lasagna recipe for 4 people.',
});

The same shape appears across provider README examples. Anthropic imports anthropic from @ai-sdk/anthropic and calls anthropic('claude-3-haiku-20240307'); Bedrock imports bedrock from @ai-sdk/amazon-bedrock and calls a Bedrock model identifier such as meta.llama3-8b-instruct-v1:0; Cohere imports cohere from @ai-sdk/cohere and calls cohere('command-r-plus'). The prompt and generateText call remain stable, so provider migration is primarily a matter of changing package imports, model IDs, credentials, and provider options. Sources: packages/anthropic/README.md, packages/amazon-bedrock/README.md, packages/cohere/README.md

Provider Selection Guide

Choose OpenAI when you want the default OpenAI provider behavior described in the official docs: the provider instance can be called as openai('gpt-5'), and since AI SDK 5 the OpenAI Responses API is selected by default unless you explicitly choose APIs such as chat or completion. Choose Anthropic when you want Claude models through the Anthropic Messages API with the straightforward @ai-sdk/anthropic package flow. Choose Google or Mistral when those model families, regional availability, or provider-native features are the best fit for your workload.

Choose Azure OpenAI when your organization provisions OpenAI-compatible deployments inside Azure. Azure is different from model-ID-only providers because the language-model call uses your deployment name, and provider creation may need Azure-specific routing and credentials. The docs support a default azure import for simple cases and createAzure for customized setup with resourceName, apiKey, Microsoft Entra ID tokenProvider, apiVersion, baseURL, custom headers, custom fetch, and useDeploymentBasedUrls. Sources: content/providers/01-ai-sdk-providers/04-azure.mdx

Choose Amazon Bedrock when your deployment standardizes on AWS-hosted models and Bedrock’s Converse API. The Bedrock README documents automatic authentication fallback: direct apiKey in provider settings first, then AWS_BEARER_TOKEN_BEDROCK, then AWS SigV4 credentials through the standard AWS credential chain. Choose Claude Platform on AWS when you specifically need Anthropic’s Messages API hosted at AWS endpoints while preserving the same wire format and feature set as the first-party Claude API. Sources: packages/amazon-bedrock/README.md, packages/anthropic-aws/README.md

Authentication and Configuration Differences

Authentication is the largest practical difference among language model providers. Some providers primarily use an API key supplied by environment variable or direct configuration. Azure additionally supports Microsoft Entra ID by accepting a tokenProvider that returns an access token for the Authorization header; when provided, that token provider is used instead of apiKey. Bedrock supports both an API-key path and SigV4 fallback, making it well suited to applications already running with AWS credentials. Sources: content/providers/01-ai-sdk-providers/04-azure.mdx, packages/amazon-bedrock/README.md

Endpoint construction also varies. Azure can assemble https://{resourceName}.openai.azure.com/openai/v1{path} from resourceName, or it can use a custom baseURL where the resolved URL is {baseURL}/v1{path}. Its useDeploymentBasedUrls option switches to a legacy deployment URL format, which is useful for compatibility with some Azure OpenAI models or deployments. These settings are provider-instance concerns; once the model object is constructed, downstream code can still call AI SDK Core functions in the normal way. Sources: content/providers/01-ai-sdk-providers/04-azure.mdx

Compact Reference

Next Steps

Start with the provider whose account and model access you already have, then keep your application code centered on generateText, streamText, and the message and tool abstractions from AI SDK Core. If you are deploying on Vercel and want to avoid per-provider package and key setup, evaluate AI Gateway before wiring a direct provider package. After selecting a provider, read the provider-specific page for supported model IDs, options, streaming behavior, and authentication edge cases, then continue to the Core generation and provider-options pages to understand how request-level settings flow into model calls.