Skip to main content
This will help you get started with OpenRouter chat models. OpenRouter is a unified API that provides access to models from multiple providers (OpenAI, Anthropic, Google, Meta, and more) through a single endpoint.
API ReferenceFor detailed documentation of all features and configuration options, head to the ChatOpenRouter API reference.
For a full list of available models, visit the OpenRouter models page.

Overview

Integration details

Model features

Setup

To access models via OpenRouter you’ll need to create an OpenRouter account, get an API key, and install the langchain-openrouter integration package.

Installation

The LangChain OpenRouter integration lives in the langchain-openrouter package:

Credentials

Head to the OpenRouter keys page to sign up and generate an API key. Once you’ve done this set the OPENROUTER_API_KEY environment variable:
To enable automated tracing of your model calls, set your LangSmith API key:

Instantiation

Now we can instantiate our model object and generate chat completions:

Invocation


Streaming

Async streaming is also supported:

Tool calling

OpenRouter uses the OpenAI-compatible tool calling format. You can describe tools and their arguments, and have the model return a JSON object with a tool to invoke and the inputs to that tool.

Bind tools

With ChatOpenRouter.bind_tools, you can pass in Pydantic classes, dict schemas, LangChain tools, or functions as tools to the model. Under the hood these are converted to OpenAI tool schemas and passed in every model invocation.

Tool calls

The AIMessage has a tool_calls attribute. This contains tool calls in a standardized format that is model-provider agnostic.

Strict mode

Pass strict=True to guarantee that model output exactly matches the JSON Schema provided in the tool definition:
For more on binding tools and tool call outputs, head to the tool calling docs.

Structured output

ChatOpenRouter supports structured output via the with_structured_output method. Two methods are available: function_calling (default) and json_schema.
Use with_structured_output to generate a structured model response. Specify method="json_schema" to use JSON Schema-based structured output; otherwise the method defaults to function calling.
Specify response_format with ProviderStrategy to engage structured output when generating the agent’s final response.
You can pass strict=True with the function_calling and json_schema methods to enforce exact schema adherence. The strict parameter is not supported with json_mode.

Reasoning output

For models that support reasoning (e.g., anthropic/claude-sonnet-4.5, deepseek/deepseek-r1), you can enable reasoning tokens via the reasoning parameter. See the OpenRouter reasoning docs for details:
For more on content blocks, see the standard content blocks guide. The reasoning dict supports two keys:
  • effort: Controls reasoning token budget. Values: "xhigh", "high", "medium", "low", "minimal", "none".
  • summary: Controls verbosity of the reasoning summary returned in the response. Values: "auto", "concise", "detailed".
Reasoning token usage is included in usage_metadata:
The effort-to-budget mapping is model-dependent. For example, Google Gemini models map effort to an internal thinkingLevel rather than an exact token budget. See the OpenRouter reasoning docs for details.

Multimodal inputs

OpenRouter supports multimodal inputs for models that accept them. The available modalities depend on the model you select—check the OpenRouter models page for details.

Supported input methods

Not all models support all modalities. Check the OpenRouter models page for model-specific support.

Image input

Provide image inputs along with text using a HumanMessage with list content format.

Audio input

Provide audio inputs along with text. Audio is passed as base64 inline data.

Video input

Video inputs are automatically converted to OpenRouter’s video_url format.

PDF input

Provide PDF file inputs along with text.

Token usage metadata

After an invocation, token usage information is available on the usage_metadata attribute of the response:
When the underlying provider includes detailed token breakdowns in its response, they are surfaced automatically. These fields are omitted when the provider does not report them or when their values are zero.

Reasoning tokens

output_token_details.reasoning reports the number of tokens the model used for internal chain-of-thought reasoning. This appears when using reasoning models (e.g., deepseek/deepseek-r1, openai/o3) or when reasoning is explicitly enabled:

Cached input tokens

input_token_details.cache_read reports the number of input tokens served from the provider’s prompt cache, and input_token_details.cache_creation reports tokens written to the cache on the first call. Prompt caching requires explicit cache_control breakpoints in message content blocks. Pass {"cache_control": {"type": "ephemeral"}} on the content block you want cached:
Without cache_control on message content blocks, the provider will not cache the prompt and these fields will not appear.
When streaming, access token usage from the full output:

Response metadata

After an invocation, provider and model metadata is available on the response_metadata attribute:
The native_finish_reason field, if present, contains the underlying provider’s original finish reason, which may differ from the normalized finish_reason.

Provider routing

Many models on OpenRouter are served by multiple providers. The openrouter_provider parameter gives you control over which providers handle your requests and how they’re selected.

Ordering and filtering providers

Use order to set a preferred provider sequence. OpenRouter tries each provider in order and falls back to the next if one is unavailable:
To restrict requests to specific providers only, use only. To exclude certain providers, use ignore:

Sorting by cost, speed, or latency

By default, OpenRouter load-balances across providers with a preference for lower cost. Use sort to change the priority:

Data collection policy

If your use case requires that providers do not store or train on your data, set data_collection to "deny":

Filtering by quantization

For open-weight models, you can restrict routing to specific precision levels:

Route parameter

The route parameter controls high-level routing behavior:
  • "fallback": enable automatic failover across providers (default behavior).
  • "sort": route based on the sorting strategy configured in openrouter_provider.

Combining options

Provider options can be composed together:
See the OpenRouter provider routing docs for the full list of options.

App attribution

OpenRouter supports app attribution via HTTP headers. You can set these through init params or environment variables:

Observability and tracing

OpenRouter can broadcast request data to configured observability destinations. ChatOpenRouter exposes two related parameters: session_id for grouping related requests under a single logical workflow, and trace for per-request trace metadata. See the OpenRouter broadcast docs for details.

Grouping requests with session_id

Pass a session_id to associate multiple requests with the same workflow (a conversation, an agent run, a batch job, a CI run, and so on). Maximum 256 characters.
The OPENROUTER_SESSION_ID environment variable is read at instantiation when no explicit session_id is provided, which lets a process tag every request without threading the value through application code. You can also override the value per call:

Adding trace metadata with trace

Pass trace to attach per-request metadata that OpenRouter forwards to broadcast destinations. Recognized keys are trace_id, trace_name, span_name, generation_name, and parent_span_id; additional keys are passed through as custom metadata.
session_id and trace are independent — session_id groups requests into a logical workflow on the OpenRouter side, while trace annotates the individual request.

API reference

For detailed documentation of all ChatOpenRouter features and configurations, head to the ChatOpenRouter API reference. For more information about OpenRouter’s platform, models, and features, see the OpenRouter documentation.