Model initialization with init_chat_model
Use `init_chat_model()` from `langchain.chat_models` (Python) or `langchain` (JavaScript) to configure language models with parameters. Common parameters: `temperature` (0.5 for balanced responses), `timeout` (in seconds or milliseconds), `max_tokens` (25000 for complex tasks), `streaming` (True/false for streaming responses). JavaScript uses `await initChatModel()` and camelCase parameters (`modelProvider`, `maxTokens`). For provider-specific options, refer to model documentation.
Python model initialization with Google Gemini
```python
from langchain.chat_models import init_chat_model
model = init_chat_model(
"gemini-3.1-pro-preview",
model_provider="google-genai",
temperature=0.5,
timeout=600,
max_tokens=25000,
streaming=True,
)
```
This initializes a Google Gemini model with specific parameters for balanced responses and streaming.
Required environment variables for model providers
Set provider API keys as environment variables: OpenAI uses `OPENAI_API_KEY`, Google Gemini uses `GOOGLE_API_KEY`, Anthropic/Claude uses `ANTHROPIC_API_KEY`, OpenRouter uses `OPENROUTER_API_KEY`, Fireworks uses `FIREWORKS_API_KEY`, Baseten uses `BASETEN_API_KEY`, Ollama uses `OLLAMA_API_KEY` (for cloud inference, local Ollama must be running), Azure uses `AZURE_OPENAI_API_KEY`, `AZURE_OPENAI_ENDPOINT`, and `AZURE_OPENAI_DEPLOYMENT_NAME`, AWS Bedrock uses `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_REGION`, HuggingFace uses `HUGGINGFACEHUB_API_TOKEN` (starts with `hf_`).
Supported model provider strings for create_agent
Model strings follow the pattern `provider:model-name`. Supported formats include: `openai:gpt-5.5`, `google_genai:gemini-2.5-flash-lite`, `claude-sonnet-4-6` (Anthropic), `openrouter:anthropic/claude-sonnet-4-6`, `fireworks:accounts/fireworks/models/qwen3p5-397b-a17b`, `baseten:zai-org/GLM-5.2`, `ollama:devstral-2`, `azure_openai:gpt-5.5`, `bedrock_converse:us.anthropic.claude-sonnet-4-6` (Python), `bedrock:gpt-5.5` (JavaScript), `huggingface:microsoft/Phi-3-mini-4k-instruct`. For Azure, use `init_chat_model()` with `azure_deployment` parameter from `AZURE_OPENAI_DEPLOYMENT_NAME` env var.
Model parameters: model, api_key, temperature, max_tokens, timeout, max_retries
Chat models accept the following standard parameters: model (string, required) - the name or identifier of the model, optionally in format 'provider:model'; api_key/apiKey (string) - authentication key, often set via environment variable; temperature (number) - controls randomness (higher = more creative, lower = more deterministic); max_tokens/maxTokens (number) - limits total tokens in response; timeout (number) - maximum time in seconds to wait for response; max_retries/maxRetries (number, default 6) - maximum retry attempts for failed requests using exponential backoff with jitter.
max_retries default and configuration for unreliable networks
The default max_retries value is 6. Network errors, rate limits (429), and server errors (5xx) are retried automatically. Client errors such as 401 (unauthorized) or 404 are not retried. For long-running agent tasks on unreliable networks, consider increasing max_retries to 10-15.
Model retry behavior with exponential backoff
LangChain chat models automatically retry failed API requests with exponential backoff. By default, models retry up to 6 times for network errors, rate limits (429), and server errors (5xx). Client errors like 401 (unauthorized) or 404 are not retried.
Model profiles expose supported features and capabilities
LangChain chat models expose a dictionary of supported features and capabilities through a 'profile' attribute (Python) or 'profile' property (JavaScript). The profile includes fields like max_input_tokens, image_inputs, reasoning_output, tool_calling, and others. Model profile data is powered by the models.dev project, an open source initiative providing model capability data, augmented with additional fields for LangChain use.
Model profile data enables dynamic capability handling
Applications can work around model capabilities dynamically using profile data. Examples include: summarization middleware can trigger based on a model's context window size; structured output strategies in create_agent can be inferred automatically; model inputs can be gated based on supported modalities and maximum input tokens; Deep Agents Code filters the model switcher to models with tool_calling support.
Override or update model profile data
Model profile data can be changed if it is missing, stale, or incorrect. Quick fix: instantiate a chat model with a custom profile dictionary passed to init_chat_model. The profile can also be updated in place or via model_copy to avoid mutating shared state. For upstream fixes, update models.dev project data, then update LangChain integration package profile_augmentations.toml, then use langchain-model-profiles CLI tool to refresh the data.
Multimodal content blocks in messages
Certain models can process and return non-textual data such as images, audio, and video. You can pass non-textual data to a model by providing content blocks in messages. All LangChain chat models with underlying multimodal capabilities support: cross-provider standard format (per messages guide), OpenAI chat completions format, and provider-native formats (e.g., Anthropic native format).
Multimodal output from models
Some models can return multimodal data as part of their response. If invoked to do so, the resulting AIMessage will have content_blocks (Python) or contentBlocks (JavaScript) with multimodal types like text, image with base64 data and mime_type.
Model reasoning capability for multi-step problem solving
Many models are capable of performing multi-step reasoning to arrive at a conclusion. This involves breaking down complex problems into smaller, more manageable steps. If supported by the underlying model, you can surface this reasoning process to better understand how the model arrived at its final answer.
Model interface works standalone and with agents
Models can be utilized in two ways: with agents where models can be dynamically specified when creating an agent, or standalone where models can be called directly outside of the agent loop for tasks like text generation, classification, or extraction without needing an agent framework. The same model interface works in both contexts.
LangChain supports all major model providers
LangChain supports all major model providers through dedicated integration packages. Each provider package implements the same standard interface, so you can swap providers without rewriting application logic. New model names work immediately without LangChain updates because provider packages pass model names directly to the provider's API.
Chat model must be used for message-based invocation
If the return type of your invocation is a string, ensure that you are using a chat model as opposed to an LLM. Legacy, text-completion LLMs return strings directly. LangChain chat models are prefixed with 'Chat', e.g., ChatOpenAI.
Timeout parameter configuration for slow connections
The timeout parameter specifies the maximum time to wait for a response from the model before canceling the request. For Python, timeout is specified in seconds; for JavaScript, it is specified in milliseconds. For slow connections, increase this value accordingly.
Model initialization with inline kwargs
Using init_chat_model (Python), pass parameters as inline **kwargs. Using initChatModel (JavaScript), pass parameters as inline parameters in the options object. Example parameters include temperature, timeout, max_tokens, and max_retries.
Provider-specific model parameters
Each chat model integration may have additional parameters used to control provider-specific functionality. For example, ChatOpenAI has use_responses_api to dictate whether to use the OpenAI Responses or Completions API. To find all parameters supported by a given chat model, head to the chat model integrations page.
reasoning_effort parameter for model reasoning control
The reasoning_effort parameter controls the level of effort a model should put into reasoning. Supported values vary by model (e.g., 'low', 'medium', 'high') or may be integer token budgets. It can be set at model construction or per invocation. The parameter is available in langchain-core>=1.5.2 and corresponding partner packages: langchain-anthropic>=1.5.3, langchain-openai>=1.4.1, langchain-fireworks>=1.5.2, langchain-xai>=1.3.0, langchain-google-genai>=4.3.1, langchain-aws>=1.6.5.
Models supporting reasoning_effort parameter
ChatOpenAI, ChatAnthropic, ChatFireworks, ChatXAI, ChatGoogleGenerativeAI, and ChatBedrockConverse support the reasoning_effort parameter. Each provider translates the parameter into its own API format.
Query supported reasoning_effort levels and defaults
To check supported reasoning_effort levels and defaults for a model, access model.profile['reasoning_effort_levels'] and model.profile['reasoning_effort_default'].
Provider-specific reasoning_effort aliases
Some providers accept native aliases for reasoning_effort. ChatAnthropic accepts 'effort' and ChatGoogleGenerativeAI accepts 'thinking_level'. See the chat model integrations page for provider-specific details.
Custom base URL for OpenAI-compatible APIs
Many model providers offer OpenAI-compatible APIs (e.g., Together AI, vLLM). You can use init_chat_model with these providers by specifying model, model_provider='openai', base_url, and api_key parameters.
HTTP proxy configuration for model integrations
Some model integrations support proxy configuration. For ChatOpenAI: model = ChatOpenAI(model='gpt-5.5', openai_proxy='http://proxy.example.com:8080'). Proxy support varies by integration; check the specific provider's reference.
Warning about OpenAI model_provider with routers and proxies
model_provider='openai' targets the official OpenAI API specification. Provider-specific fields from routers and proxies may not be extracted or preserved. For OpenRouter, prefer ChatOpenRouter (langchain-openrouter). For LiteLLM, prefer ChatLiteLLM or ChatLiteLLMRouter (langchain-litellm).
Log probabilities configuration
Certain models can be configured to return token-level log probabilities by setting the logprobs parameter when initializing the model or using bind(logprobs=True). Access the log probabilities via response.response_metadata['logprobs'].
RunnableConfig for invocation control
When invoking a model, pass additional configuration through the config parameter using a RunnableConfig dictionary. This provides run-time control over execution behavior, callbacks, and metadata tracking.
RunnableConfig common options
Common RunnableConfig options: run_name (string identifying the invocation, not inherited by sub-calls), tags (string array inherited by sub-calls for filtering), metadata (object inherited by sub-calls), max_concurrency (number controlling parallel calls in batch operations), callbacks (array of callback handlers), recursion_limit (number preventing infinite loops in complex pipelines).
RunnableConfig example
Example: response = model.invoke('Tell me a joke', config={'run_name': 'joke_generation', 'tags': ['humor', 'demo'], 'metadata': {'user_id': '123'}, 'callbacks': [my_callback_handler]}).
Configurable models with init_chat_model
Create a runtime-configurable model using init_chat_model. If you don't specify model value, 'model' and 'model_provider' are configurable by default. Pass different model values at runtime via config={'configurable': {'model': 'model-name'}}.
Configurable model example
Example: configurable_model = init_chat_model(temperature=0); configurable_model.invoke('what\'s your name', config={'configurable': {'model': 'gpt-5-nano'}}); configurable_model.invoke('what\'s your name', config={'configurable': {'model': 'claude-sonnet-4-6'}}).
Configurable model with specific fields and prefixes
When creating a configurable model, use configurable_fields parameter to specify which fields are configurable (e.g., 'model', 'model_provider', 'temperature', 'max_tokens'). Use config_prefix to add prefixes to configurable param names (useful when chaining multiple models).
Configurable model with tools and structured output
You can call declarative operations like bind_tools, with_structured_output, with_configurable, etc. on a configurable model and chain it the same way as a regularly instantiated chat model.
Run models locally with Ollama
Ollama is one of the easiest ways to run chat and embedding models locally. This is useful for data privacy, custom models, or avoiding cloud-based model costs.
init_chat_model for standalone model initialization
The easiest way to get started with a standalone model in LangChain is to use init_chat_model (Python) or initChatModel (JavaScript) to initialize one from a chat model provider of your choice. This function accepts the model name and optional parameters like temperature, timeout, max_tokens, and max_retries.
Model invoke method takes messages as input
The invoke method is the most straightforward way to call a model. It takes messages as input and outputs messages after generating a complete response. A single string message or a list of messages representing conversation history can be provided.