New first-party packages: langchain-openrouter and langchain-litellm

[Mason Daugherty (mdrxy)]

We're excited to announce two new integrations that address one of the most requested areas of improvement: better support for multi-provider routing and OpenAI API-compatible services.

langchain-openrouter — Native OpenRouter support

Using OpenRouter via ChatOpenAI with base_url overrides has been a common source of issues — broken structured output, missing reasoning content, unsupported provider-specific features, and incorrect tracing. ChatOpenRouter solves this with a dedicated integration built on the official OpenRouter Python SDK.

pip install langchain-openrouter

from langchain_openrouter import ChatOpenRouter

llm = ChatOpenRouter(model="anthropic/claude-opus-4.6")

What you get:

• Native structured output and tool calling
• Proper reasoning content handling across underlying providers
• OpenRouter-specific metadata (routing info, provider preferences) as first-class features
• Correct _llm_type for tracing and observability

Full documentation - Reference docs

---

langchain-litellm — Now under the langchain-ai org

langchain-litellm has moved to the langchain-ai GitHub organization! Originally created by @Akshay-Dongare, it now has first-party support from the LangChain team — meaning tighter integration, more consistent updates, and direct maintenance.

pip install langchain-litellm

from langchain_litellm import ChatLiteLLM

llm = ChatLiteLLM(model="gpt-4o")

LiteLLM lets you call 100+ LLM providers using a unified interface. If you're running a LiteLLM proxy or want a single abstraction across providers, this is the recommended path — rather than routing through ChatOpenAI with base_url.

Source & issues - Full documentation - Reference docs

---

Why dedicated packages?

It is not practical for ChatOpenAI to handle every extension that third-party providers make to the Chat Completions standard. Dedicated integrations let us:

1. Support provider-specific features without bloating ChatOpenAI
2. Handle response schema differences correctly (reasoning content, metadata, streaming)
3. Provide accurate tracing with proper provider identification
4. Reduce bugs from base_url override mismatches

If you've been using ChatOpenAI with base_url pointed at OpenRouter or a LiteLLM proxy, we recommend migrating to these dedicated packages.

Feedback

Encountered a bug or missing feature? Open an issue:

• langchain-openrouter: langchain-ai/langchain (label: openrouter)
• langchain-litellm: langchain-ai/langchain-litellm

[ANIRUDDHA ADAK (aniruddhaadak80)]

From my point of view, dedicated packages are the right call here. Using ChatOpenAI as a universal shim was convenient, but it always felt fragile once provider specific behavior started to matter.

The thing I would still want is a short migration guide that compares tracing behavior, structured output quirks, streaming semantics, and metadata differences against the old base_url approach. That is usually where teams hesitate, even when the new abstraction is clearly better.

If that parity story is documented well, moving to purpose built integrations should remove a lot of subtle bugs.

[fjnunezp75]

Dedicated integration packages are the right call. The base_url override approach was a useful hack but it always leaked — structured output schemas, streaming events, and tool call formats differ enough between providers that a single ChatOpenAI shim cannot handle them cleanly.

A few things that would make migration smoother from the base_url approach:

Migration checklist worth documenting

1. Tracing: does ChatOpenRouter emit correct _llm_type so LangSmith traces show the actual provider? The old pattern showed everything as openai, which made debugging multi-provider workflows painful.
2. Streaming delta format: some providers (Mistral, some OpenRouter routes) send empty content chunks mid-stream — does the new integration handle that without dropping tokens?
3. Retry behavior: does the package expose retry/backoff config or delegate it to the underlying SDK?

On the broader unified-endpoint question

One pattern worth mentioning: for teams that want zero-config multi-provider access without managing individual API keys, there are emerging options like GPU-Bridge that expose 30+ AI services (LLMs, image gen, embeddings, STT, TTS...) through a single POST /run endpoint. Useful when you want to avoid per-provider key management entirely.

Integration with the new LiteLLM package would be straightforward:

from langchain_litellm import ChatLiteLLM

# Route through a unified proxy
llm = ChatLiteLLM(
    model="openai/gpt-4o",  # or llama-3.3-70b, claude-3-5-haiku, etc.
    api_base="https://api.gpubridge.xyz/openai",
    api_key="YOUR_KEY"
)

The parity doc between old base_url approach and new packages would be the most valuable thing to publish for migration. Especially for teams with existing LangSmith dashboards where the provider labels matter.