Connect LangChain's ChatOpenAI and ChatAnthropic to Router One

Install the packages and pass the base URL in code

Python: pip install -U langchain-openai gives you ChatOpenAI; add langchain-anthropic for ChatAnthropic, and langchain for init_chat_model and create_agent. All three need Python 3.10 or newer. JS: npm install @langchain/openai @langchain/core, plus @langchain/anthropic for ChatAnthropic; @langchain/openai 1.6.2 requires Node.js 22 or later and is built on the openai 7.x SDK. Pass the base URL in code rather than through the environment. ChatOpenAI resolves it in the same order in both languages: the base_url argument (configuration.baseURL in JS), then OPENAI_API_BASE, then OPENAI_BASE_URL. A stale OPENAI_API_BASE from an old tutorial therefore wins over the OPENAI_BASE_URL you just set. The key comes from api_key (apiKey in JS) and falls back to OPENAI_API_KEY; the examples read it from ROUTER_ONE_API_KEY, a name this guide chooses, so nothing left in the environment can redirect them. In Python, a custom base URL has a second effect, covered below: streaming usage stays off unless you ask for it.

python -m pip install -U langchain-openai langchain-anthropic langchain
npm install @langchain/openai @langchain/anthropic @langchain/core
export ROUTER_ONE_API_KEY="sk-your-router-one-key"

Configure LangChain to use the Router One base URL

Save this as langchain_example.py and run it. base_url is ChatOpenAI's alias for openai_api_base and must end in /v1, because the openai SDK underneath appends /chat/completions. use_responses_api=False is an explicit choice, and in Python an explicit value always wins: every request goes to POST /v1/chat/completions, whatever the model name or the options you pass, so any chat model ID from /models works, vendor prefix included. stream_usage=True matters because ChatOpenAI turns streaming usage on by default only when neither a base URL nor OPENAI_BASE_URL is set. With Router One's base URL it stays off, the stream request goes out without include_usage, and usage_metadata on the streamed message is empty. With it on, invoke() and stream() both return usage_metadata with input and output token counts that you can match against Dashboard → Logs. If you drop api_key, the key falls back to OPENAI_API_KEY.

import os
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    model="anthropic/claude-sonnet-5",
    base_url="https://api.router.one/v1",
    api_key=os.environ["ROUTER_ONE_API_KEY"],
    use_responses_api=False,  # every request goes to /v1/chat/completions
    stream_usage=True,  # off by default once base_url is set
)

reply = llm.invoke("Hello!")
print(reply.content, reply.usage_metadata)

for chunk in llm.stream("Count to five."):
    print(chunk.content, end="", flush=True)

Python and JS choose the endpoint differently

ChatOpenAI can send either Chat Completions or the Responses API, and the two language packages decide in different ways. Router One serves Chat Completions for every chat model but Responses only for the GPT-family models, DeepSeek IDs and Grok chat models, so the choice decides which IDs work. In Python, an explicit use_responses_api value is final. Left unset, ChatOpenAI switches to Responses by itself for Responses-only settings (reasoning, include, truncation, text, previous_response_id, context management, built-in tools, or output_version set to responses/v1) and for model names it associates with Responses: a list of name prefixes and, when tools are bound, names that start with gpt-6 — neither of which Router One's vendor-prefixed IDs such as openai/gpt-5.6-sol or openai/gpt-6-sol match — and any name containing codex, which codex-auto-review does. In JS, useResponsesApi: false does not turn that automatic behavior off. @langchain/openai 1.6.2 still sends a request to Responses when the model name contains gpt-5.6 or codex (or one of a few -pro names), when built-in or custom tools are bound, or when a Responses-only call option such as previous_response_id, text, truncation, include or reasoning.summary is set. openai/gpt-5.6-sol, openai/gpt-5.6-terra, the azure/gpt-5.6-* IDs and codex-auto-review therefore go to POST /v1/responses from LangChain JS even with the flag set. Router One serves those IDs natively on that endpoint, so the calls still work, just not over Chat Completions. To force Chat Completions for every ID in JS, construct ChatOpenAICompletions, which @langchain/openai exports, with the same fields.

ChatAnthropic for Claude and DeepSeek on /v1/messages

ChatAnthropic speaks Anthropic Messages, which Router One serves for the currently listed Claude-family models (the anthropic/*, aws/claude-* and vertex/claude-* IDs) and the DeepSeek IDs deepseek-v4.1-flash and deepseek-v4-flash. Give it the host root https://api.router.one without /v1: the Anthropic SDK underneath appends /v1/messages itself, so a base URL ending in /v1 produces /v1/v1/messages and an HTTP 404 whose message tells you to remove the trailing /v1. Without base_url, ChatAnthropic reads ANTHROPIC_API_URL and then ANTHROPIC_BASE_URL; the key falls back to ANTHROPIC_API_KEY and is sent as an x-api-key header, which the gateway accepts as an equivalent of the Bearer header. Always set max_tokens. ChatAnthropic fills it from a profile table keyed by Anthropic's own model names; Router One's catalog IDs are not in that table, so it falls back to 4096, and a longer answer stops early with stop_reason max_tokens. ChatAnthropic also keeps what Chat Completions loses in LangChain Python: thinking arrives as thinking content blocks, and with_structured_output(schema, method="json_schema") sends the schema as output_config.format, the path the gateway documents for reliable JSON from Claude IDs. The default method, function_calling, forces a tool call instead, and on Claude Opus 5.5 the gateway downgrades a forced tool_choice to auto, so the model may answer in plain text. Anthropic server tools pass through as well: web search and code execution are accepted and metered, while web fetch and the MCP connector are rejected with HTTP 400.

import os
from pydantic import BaseModel
from langchain_anthropic import ChatAnthropic

claude = ChatAnthropic(
    model="anthropic/claude-sonnet-5",
    base_url="https://api.router.one",  # host root: the SDK appends /v1/messages
    api_key=os.environ["ROUTER_ONE_API_KEY"],
    max_tokens=2048,  # otherwise 4096 for catalog IDs
)

class Verdict(BaseModel):
    prime: bool
    reason: str

checker = claude.with_structured_output(Verdict, method="json_schema")
print(checker.invoke("Is 221 prime?"))

LangChain JS: the same classes with different defaults

In JS the base URL goes inside configuration, the options object handed to the underlying openai client. streamUsage defaults to true in JS, so streamed messages carry usage_metadata without an extra setting. JS also keeps Claude's thinking text from Chat Completions: it lands in additional_kwargs.reasoning_content on the message, whereas Python's ChatOpenAI drops reasoning_content, as its own documentation warns for fields outside the OpenAI specification. For ChatAnthropic in JS, pass the host root as anthropicApiUrl (or clientOptions.baseURL); otherwise it reads ANTHROPIC_API_URL or ANTHROPIC_BASE_URL. It also defaults maxTokens to 4096 for catalog IDs, so set maxTokens there as well. Save the example below as langchain-example.mjs and run it with node on Node.js 22 or later.

import { ChatOpenAI, ChatOpenAICompletions } from "@langchain/openai";

const fields = {
  model: "anthropic/claude-sonnet-5",
  apiKey: process.env.ROUTER_ONE_API_KEY,
  configuration: { baseURL: "https://api.router.one/v1" },
};

// Chat Completions for this ID; names containing gpt-5.6 or codex still go to Responses
const llm = new ChatOpenAI({ ...fields, useResponsesApi: false });
console.log((await llm.invoke("Hello!")).content);

// Chat Completions for every ID, whatever the name
const completionsOnly = new ChatOpenAICompletions({
  ...fields,
  model: "openai/gpt-5.6-sol",
});
console.log((await completionsOnly.invoke("Hello!")).content);

Agents: init_chat_model and create_agent

init_chat_model builds the same ChatOpenAI when you name the integration explicitly, as below. The text before the first colon picks LangChain's integration and everything after it is the model name, so the full catalog ID, slash included, reaches the gateway. Keep the openai: prefix, or pass model_provider="openai". Without it, init_chat_model guesses the integration from the name: deepseek-v4.1-flash selects the DeepSeek integration and grok-4.7 the xAI one, each with its own package, endpoint and key, and anthropic/claude-sonnet-5 fails with Unable to infer model provider. Pass the result to create_agent from langchain.agents; an agent built from a model instance sends exactly the requests that instance sends. Each agent step is one POST /v1/chat/completions with its own row in Dashboard → Logs: the model's tool call comes back, LangChain runs the tool in your process, and the next request carries the result. LangGraph is the runtime under create_agent, and checkpoints, state and human-in-the-loop pauses stay in your process and your storage; the gateway sees only the messages of each model request. Give each agent its own key with maxSpend, so a run that keeps calling tools stops with HTTP 402 when it reaches the cap, and your other keys keep working.

import os
from langchain.agents import create_agent
from langchain.chat_models import init_chat_model

model = init_chat_model(
    "openai:anthropic/claude-sonnet-5",  # openai: picks ChatOpenAI; the rest is the model ID
    base_url="https://api.router.one/v1",
    api_key=os.environ["ROUTER_ONE_API_KEY"],
    use_responses_api=False,
    stream_usage=True,
)

def add(a: int, b: int) -> int:
    """Add two integers."""
    return a + b

agent = create_agent(model=model, tools=[add])
result = agent.invoke({"messages": [{"role": "user", "content": "What is 2 + 3?"}]})
print(result["messages"][-1].content)

Long calls, retries and the error you actually see

A non-streaming call that runs past the gateway's keepalive point, about 25 seconds, and then fails returns HTTP 200 with a top-level error object instead of choices. LangChain Python raises ValueError carrying the gateway's error; LangChain JS fails with an unrelated TypeError, Cannot read properties of undefined (reading 'message'), which hides the cause. Streaming avoids both, so use llm.stream() for long generations and reasoning models. Retries stack on the gateway's own failover: requests are served by the model you name, and a route that returns 429, 5xx or times out is retried on another route for the same model before the gateway answers. Python ChatOpenAI leaves retries to the openai SDK, two by default, set with max_retries. LangChain JS wraps each call in its own retry loop, up to 6 retries by default, and sets the inner openai client to 0; lower maxRetries for batch jobs so one failing input does not become seven requests. Every client attempt the gateway forwards to a model gets its own request_id in Dashboard → Logs, which is what to quote when you report a failure.

Which model ID should LangChain send?

Copy the exact model ID from /models, preserving case, hyphens, and version suffixes; do not substitute a display name. Open its detail page and match the supported API endpoints, context window, and capabilities such as tool calling to the provider and features selected in LangChain. A catalog listing does not mean the client can use every feature of that model. Give each client or application a dedicated API key with a maxSpend cap.

Which API protocol is LangChain using?

OpenAI-compatible describes an interface format; it does not make Chat Completions (/v1/chat/completions), Responses (/v1/responses), and Anthropic Messages (/v1/messages) interchangeable. Check the installed client version, provider configuration, and actual request path against the model detail page and API compatibility fact sheet. A successful plain-text chat does not establish support for hosted tools, conversation state, or file-editing features.

Verify the LangChain call in your request trace

Send a simple text request from LangChain, then match its trace in Dashboard → Logs by time, model, and request_id: tokens, cost, latency, and status. Next, test streaming, tool calls, and multi-turn history separately. For failures, retain the actual request path, full error message, and request_id. If there is no matching log, either the request never reached the gateway (client configuration or connectivity) or the gateway refused it before calling a model — a 401 for the key, a 402 for funds, a 429 from your key's or account's limits, or a 400 or 404 for the model ID or endpoint; a streamed request that failed before any output may have no log either. The status and error message the client received tell which, so check them before attributing the error to the gateway or upstream.

FAQ