Providers and Models
Purpose and Scope
Providers are the companies or services that expose model APIs, while models are the concrete language-model products selected for a generation call. The foundations documentation uses OpenAI and Anthropic as examples of providers that each offer multiple large language models with different strengths and capabilities. The problem this page solves is orientation: without a shared abstraction, every provider would require its own request shape, authentication assumptions, streaming behavior, and model naming conventions. AI SDK Core addresses that by presenting a standardized language model interface so application code can focus on prompts, tools, streams, and outputs instead of rewriting integration logic whenever the chosen provider changes.
Sources: content/docs/02-foundations/02-providers-and-models.mdx
The key idea is provider-agnostic model selection. A provider package supplies a provider instance, and that provider instance creates model handles that can be passed into the same AI SDK Core APIs. The documentation describes this as a unified interface that abstracts differences between providers and reduces vendor lock-in. In practice, that means the rest of an application can keep the same mental model for text generation, structured output, tool calling, and streaming while a team evaluates different vendors or moves workloads between model families. The provider choice still matters, but it is isolated behind a common contract.
Sources: content/docs/02-foundations/02-providers-and-models.mdx
Relevant Source Files
- content/docs/02-foundations/02-providers-and-models.mdx — Defines the public foundations page for providers and models, including the vendor-lock-in motivation, the language model specification, the provider architecture diagram, the official provider list, OpenAI-compatible providers, and the custom provider path.
Core Primitives
The first primitive is the provider. In this documentation, a provider is the integration boundary for a model service such as xAI Grok, OpenAI, Azure OpenAI, Anthropic, Amazon Bedrock, Google Generative AI, Google Vertex, Mistral, Together.ai, Cohere, Fireworks, DeepInfra, DeepSeek, Cerebras, Groq, Perplexity, ElevenLabs, LMNT, Hume, Rev.ai, Deepgram, Gladia, AssemblyAI, and Baseten. These entries are documented as AI SDK providers with package names where applicable, which signals that they are first-party integration packages rather than one-off examples. The provider package is the place a reader should look when they need provider-specific setup, authentication, model IDs, or capability notes.
Sources: content/docs/02-foundations/02-providers-and-models.mdx
The second primitive is the model. A model is not just a string label in the conceptual architecture; it is the selected capability exposed by a provider. Different models can vary in strengths, modalities, latency, cost, context windows, tool support, streaming support, and structured-output reliability. The foundations page deliberately separates providers from models because a single provider may expose many models and because the same application can be written against the AI SDK interface while selecting the most appropriate model for a task. This separation helps teams reason about portability: provider integration is one decision, while model choice is a narrower runtime or configuration decision.
Sources: content/docs/02-foundations/02-providers-and-models.mdx
The third primitive is the language model specification. The foundations page points to an open-source language model specification and explains that AI SDK Core uses it to abstract provider differences. This specification is the common contract that provider packages implement, and it is also the extension point for custom providers. For readers building normal applications, the important takeaway is that the specification sits below the everyday API surface. For readers building integrations, the specification becomes the compatibility target that allows a new provider implementation to participate in the same AI SDK Core workflows as the official packages.
Sources: content/docs/02-foundations/02-providers-and-models.mdx
System-to-Code Mapping
The source page maps the system from top to bottom. At the top are application-facing AI SDK Core functions and workflows that should not need to know every provider’s native API. Beneath that is the standardized language model specification, which normalizes the differences between model services. Beneath that sit provider implementations, each connecting to the provider’s own API and exposing models through the shared interface. The architecture diagram in the documentation reinforces this layered relationship: applications talk to the AI SDK abstraction, the abstraction talks to provider packages, and provider packages handle the provider-specific details.
Sources: content/docs/02-foundations/02-providers-and-models.mdx
This mapping is useful when choosing where to solve a problem. If the problem is prompt design, tool definitions, streaming UI, or structured output parsing, it usually belongs above the provider boundary because those are AI SDK Core or UI concerns. If the problem is provider authentication, regional endpoints, model IDs, or feature availability, it belongs in the provider documentation for the selected package. If the problem is implementing a new integration for a service that is not available as an official provider, the custom provider path and the language model specification are the relevant extension points.
Sources: content/docs/02-foundations/02-providers-and-models.mdx
Provider Selection Flow
Start by identifying the task rather than the vendor. For a chat assistant, choose a language model provider with the conversational, tool, and streaming behavior the application requires. For image, speech, transcription, or other multimodal features, verify that the provider family supports the needed modality before designing the user experience around it. The official provider catalog marks capabilities such as image input, image generation, object generation, tool usage, and tool streaming, so model selection should be capability-driven. The foundations page’s provider list is the starting inventory, while each provider’s detailed page should be used for exact setup and supported model names.
Sources: content/docs/02-foundations/02-providers-and-models.mdx
Next decide whether the project should use a first-party provider package, an OpenAI-compatible provider, a community provider, or a custom provider. The foundations page explicitly documents OpenAI-compatible APIs, including LM Studio and Heroku entries, as a separate path from the main AI SDK providers. That distinction matters because OpenAI-compatible services usually share a familiar wire style, but they are still not the same as official OpenAI. Community providers such as Ollama, FriendliAI, Portkey, and Cloudflare Workers AI show that the ecosystem can extend beyond first-party packages while still aligning with the AI SDK provider model.
Sources: content/docs/02-foundations/02-providers-and-models.mdx
API Components and Package Reference
The documented first-party package pattern is a provider page paired with a package name. Examples include @ai-sdk/xai, @ai-sdk/openai, @ai-sdk/azure, @ai-sdk/anthropic, @ai-sdk/amazon-bedrock, @ai-sdk/google, @ai-sdk/google-vertex, @ai-sdk/mistral, @ai-sdk/togetherai, @ai-sdk/cohere, @ai-sdk/fireworks, @ai-sdk/deepinfra, @ai-sdk/deepseek, @ai-sdk/cerebras, @ai-sdk/groq, @ai-sdk/perplexity, @ai-sdk/elevenlabs, @ai-sdk/lmnt, @ai-sdk/hume, @ai-sdk/revai, @ai-sdk/deepgram, @ai-sdk/gladia, @ai-sdk/assemblyai, and @ai-sdk/baseten. These names are important because they make provider choice explicit in dependency management, code imports, and documentation lookup.
Sources: content/docs/02-foundations/02-providers-and-models.mdx
OpenAI-compatible and community providers are part of the same reader workflow but have different ownership expectations. The foundations page calls out an OpenAI Compatible provider route for APIs that follow the OpenAI-compatible pattern, then separately notes that the language model specification can be used to create custom providers. It also identifies community-created providers, including ollama-ai-provider, @friendliai/ai-provider, and @portkey-ai/vercel-provider. Treat these as ecosystem integrations: confirm maintenance status, supported capabilities, and compatibility with the AI SDK version in use before standardizing a production application on them.
Sources: content/docs/02-foundations/02-providers-and-models.mdx
Implementation Guidance
A practical implementation usually starts with the narrowest provider decision that satisfies the product requirement. Pick one provider package, configure the required credentials according to that provider’s own page, then select a model for the first use case. Keep provider-specific options close to the call sites or configuration modules that need them, and keep provider-neutral application logic written against the AI SDK concepts. That separation makes later migration easier: a team can compare Anthropic, OpenAI, Google, or another model family without rewriting message construction, tool schema definitions, or output handling throughout the application.
Sources: content/docs/02-foundations/02-providers-and-models.mdx
Be careful not to assume that a unified interface means identical capabilities. The foundations page says providers expose models with differing strengths and capabilities, and the broader provider catalog highlights that capabilities vary by provider. A model may support image input but not image generation, or tool usage but not the specific streaming behavior a UI expects. The safe workflow is to design against the AI SDK abstraction, then verify the selected provider and model support every required feature. This is especially important for production applications that depend on structured outputs, tool calls, multimodal inputs, or real-time streaming UX.
Sources: content/docs/02-foundations/02-providers-and-models.mdx
Next Steps
After this page, read the provider-specific documentation for the package you plan to install, then continue to the prompt, tools, streaming, and provider options foundations pages. If the provider you need is OpenAI-compatible, follow the OpenAI-compatible provider path before writing a custom integration. If no suitable provider exists, use the language model specification as the extension contract for a custom provider. The goal is to keep application code on the common AI SDK surface while isolating vendor-specific behavior in the provider layer, where it can be configured, tested, and replaced with the least disruption.