Providers Overview
Purpose and Scope
LangChain’s provider ecosystem is built around a simple developer promise: application code should talk to a stable model interface while provider-specific packages handle API details, credentials, dependencies, and model capabilities. A provider is the company, platform, router, gateway, or self-hosted endpoint that serves a model. A model integration is the LangChain implementation that adapts that provider’s API into the shared interfaces used by agents, chains, runnables, callbacks, and streaming consumers. This page orients Python developers to that separation so they can choose an integration without coupling the rest of their application to one vendor.
The repository evidence for this page is the core language-model layer, not an individual provider package. That layer defines the contract that first-party maintained partner packages and broader third-party integrations are expected to satisfy. Chat models are the primary modern abstraction: they accept message sequences and return chat messages. Legacy LLMs still exist for string-in, string-out models, and LangChain normalizes them enough that message input can be formatted into text before reaching the underlying model. Sources: libs/core/langchain_core/language_models/init.py, libs/core/langchain_core/language_models/base.py
Official integration docs describe provider packages as separately installable packages such as OpenAI, Anthropic, Google, and others. In Python, first-party maintained partner packages generally live as dedicated distributions and implement the same core contracts. Broader third-party integrations can also implement those contracts, and model routers or OpenAI-compatible endpoints can sit behind a provider package or gateway. The important design point is that the application should depend on the LangChain interface first, then opt into provider-specific features only where the use case requires them.
Core Provider Model
The core module exports the public language-model vocabulary that provider implementations share: BaseChatModel, BaseLanguageModel, BaseLLM, LLM, SimpleChatModel, LanguageModelInput, LanguageModelOutput, LanguageModelLike, LangSmithParams, ModelProfile, and ModelProfileRegistry. These names are dynamically imported from their implementation modules so downstream packages can use stable import paths without eagerly importing every implementation detail. Provider packages should be read as adapters around this vocabulary, not as isolated APIs with unrelated semantics. Sources: libs/core/langchain_core/language_models/init.py
LanguageModelInput is the key input union for model interoperability. It accepts a prompt value, a string, or a sequence of message-like representations. LanguageModelOutput is correspondingly either a base message or a string, and LanguageModelLike is a runnable from the input shape to the output shape. Those type aliases matter because provider choice is often late-bound: an agent might receive a model from configuration, a factory, or a runtime selector, yet the rest of the system can still invoke it through runnable semantics. Sources: libs/core/langchain_core/language_models/base.py
Tracing and observability also participate in provider portability. LangSmithParams includes fields such as ls_provider, ls_model_name, ls_model_type, ls_temperature, ls_max_tokens, ls_stop, and ls_integration. These fields give integrations a standard place to report which provider and model generated a run without exposing the full provider request. The utility layer also filters large invocation fields such as tools, functions, messages, and response formats before tracing, which keeps provider calls observable without turning traces into oversized request dumps. Sources: libs/core/langchain_core/language_models/base.py, libs/core/langchain_core/language_models/_utils.py
Relevant Source Files
libs/core/langchain_core/language_models/__init__.py- Defines the public language-model package exports and describes chat models versus legacy LLMs.libs/core/langchain_core/language_models/_compat_bridge.py- Converts AI message chunk streams into protocol events for provider-neutral streaming behavior.libs/core/langchain_core/language_models/_utils.py- Contains utility behavior used across providers, including tracing parameter filtering and OpenAI-format multimodal data detection.libs/core/langchain_core/language_models/base.py- Defines shared language-model input and output types, tracing metadata, and tokenizer fallback behavior.libs/core/langchain_core/language_models/chat_model_stream.py- Implements per-message stream objects and accumulated projections for protocol event streams.libs/core/langchain_core/language_models/chat_models.py- Hosts the base chat model implementation referenced by the public package exports and streaming APIs.
System-to-Code Mapping
| Ecosystem concept | Core code contract | Why it matters |
|---|---|---|
| Provider package | BaseChatModel, BaseLanguageModel, BaseLLM | Provider integrations plug into shared model abstractions rather than forcing application-specific branches. |
| Model input portability | LanguageModelInput | Prompts, strings, and message-like sequences can be accepted through a common type. |
| Observability metadata | LangSmithParams | Provider, model, type, and generation settings can be reported consistently in traces. |
| Multimodal compatibility | is_openai_data_block | Integrations can recognize OpenAI Chat Completions-style image, audio, and file blocks. |
| Streaming protocol | chunks_to_events, achunks_to_events, ChatModelStream, AsyncChatModelStream | Streaming consumers can process deltas, tool calls, usage, and final output across providers. |
This mapping explains why provider integrations can be installed and swapped independently. A chat model implementation is responsible for translating provider requests and responses into LangChain messages, chunks, content blocks, and tracing metadata. Once that translation is complete, agent code can call invoke, use streaming, bind tools, or pass the model into higher-level orchestration without knowing whether the response came from a first-party partner package, a community integration, a router, or an OpenAI-compatible endpoint. Sources: libs/core/langchain_core/language_models/init.py, libs/core/langchain_core/language_models/base.py, libs/core/langchain_core/language_models/chat_models.py
Streaming and Content Compatibility
Provider interoperability is most visible during streaming because different APIs emit different event shapes. The compatibility bridge treats AIMessageChunk.content_blocks as the single protocol view for a chunk. Its documentation states that content blocks are resolved through a tiered lookup that can handle registered partner providers, unregistered community models, or messages without provider tags. Each chunk is considered a delta slice rather than accumulated state, so the bridge forwards content-block deltas and accumulates only enough indexed state to emit final content-block finish events. Sources: libs/core/langchain_core/language_models/_compat_bridge.py
The streaming layer exposes both raw protocol events and typed projections. ChatModelStream is returned by BaseChatModel.stream_events(version="v3"), while AsyncChatModelStream is returned by BaseChatModel.astream_events(version="v3"). These stream objects provide .text, .reasoning, .tool_calls, .usage, and .output projections that accumulate as events arrive, while still allowing direct iteration over raw events with replay-buffer semantics. This is the provider-neutral surface application UIs and agents should prefer when they need token deltas, reasoning blocks, tool-call chunks, or final outputs. Sources: libs/core/langchain_core/language_models/chat_model_stream.py, libs/core/langchain_core/language_models/_compat_bridge.py
Multimodal content is another compatibility boundary. is_openai_data_block recognizes OpenAI Chat Completions-style image, audio, and file blocks, including image URLs, input audio payloads, base64 file data, and pre-uploaded file IDs. This helper is exported from the language-model package because provider implementations and content translation logic need shared rules for detecting common block formats. The helper does not make every provider OpenAI-specific; rather, it gives integrations a precise interoperability check for a widely used wire format. Sources: libs/core/langchain_core/language_models/_utils.py, libs/core/langchain_core/language_models/init.py
Choosing First-Party and Third-Party Integrations
Use a first-party maintained partner package when it exists for the provider you need and you want the most direct fit with LangChain’s current abstractions, release process, examples, and API reference. These packages usually expose provider-specific capabilities while still implementing the shared model contract, which lets you start with portable application code and then opt into features such as provider-native tool calling, response APIs, extended reasoning, or model-specific parameters as needed. The core contract makes that specialization safe because the model remains invokable through the same LangChain interfaces.
Use a broader third-party integration, router, proxy, or OpenAI-compatible endpoint when your target model is not covered by a maintained partner package, when your organization centralizes model access through a gateway, or when you want to compare many upstream providers behind one endpoint. In those cases, validate the same practical capabilities you would validate for a partner package: message input handling, structured content translation, tool-call chunks, streaming event support, token usage metadata, and tracing parameters. If an integration implements the core interfaces well, the surrounding agent and runnable code should remain stable.
Compact Reference
| Name | Kind | Provider-facing behavior |
|---|---|---|
BaseChatModel | Base class | Primary abstraction for chat providers that accept message sequences and return chat messages. |
BaseLanguageModel | Base class | Shared superclass for model implementations. |
BaseLLM / LLM | Base classes | Legacy string-oriented model path, still normalized for LangChain use. |
LanguageModelInput | Type alias | `PromptValue |
LanguageModelOutput | Type alias | `BaseMessage |
LanguageModelLike | Type alias | Runnable[LanguageModelInput, LanguageModelOutput]. |
LangSmithParams | Typed dictionary | Standard tracing fields for provider, model, model type, generation settings, and integration name. |
is_openai_data_block(block, filter_=None) | Utility | Detects OpenAI-format image, audio, or file data blocks. |
chunks_to_events / achunks_to_events | Bridge APIs | Convert live AIMessageChunk streams into protocol event lifecycles. |
message_to_events / amessage_to_events | Bridge APIs | Replay a finalized AIMessage as synthetic protocol events. |
ChatModelStream / AsyncChatModelStream | Stream objects | Expose raw events plus accumulated projections for text, reasoning, tool calls, usage, and output. |
Next, read the provider-specific integration page for the model family you want to use, then check the language model and streaming API references when you need to implement or debug a custom provider adapter. If you are comparing providers, keep your application code typed against the core model interfaces first and isolate provider-specific parameters near initialization or configuration.