LangChain OpenAI Integration: Use Multiple Models Through One API

The LangChain OpenAI integration is useful beyond OpenAI-hosted models: ChatOpenAI can target an OpenAI-compatible Chat Completions endpoint when you set a custom base_url. That gives a Python application one model interface for prompts, streaming, structured output, and basic tool calls while the backend model changes through configuration.

This guide uses langchain-openai with LinkModel as the compatible endpoint. LinkModel's documented base URL is https://api.linkmodel.ai/v1, and its chat models are available at the bearer-authenticated POST /chat/completions endpoint. LangChain cautions that non-standard provider fields may not be preserved by ChatOpenAI, so use a provider-specific integration when you depend on proprietary response metadata.

Install and configure credentials

Install the integration in an isolated environment:

python -m pip install -U langchain-openai

Keep the API key in the environment rather than source code:

export LINKMODEL_API_KEY="your_api_key"
export LINKMODEL_BASE_URL="https://api.linkmodel.ai/v1"
export LINKMODEL_MODEL="gpt-5.4-mini"

The model ID must be one that is currently available and supports the operation you need. LinkModel's model reference currently lists gpt-5.4-mini as a chat model with an OpenAI-compatible endpoint. Treat the catalog as the source of truth when you deploy.

LangChain's official ChatOpenAI integration guide documents the package, credentials, invocation, streaming, and tool-calling surface. If your application is TypeScript rather than Python, the Vercel AI SDK OpenAI-compatible guide uses the same base-URL idea with a server-side provider module.

Create a ChatOpenAI client with a custom base URL

import os
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    model=os.environ["LINKMODEL_MODEL"],
    api_key=os.environ["LINKMODEL_API_KEY"],
    base_url=os.environ["LINKMODEL_BASE_URL"],
    timeout=30,
    max_retries=2,
)

answer = llm.invoke("Give me three concise names for a support triage bot.")
print(answer.content)

The important settings are model, api_key, and base_url. A custom base URL does not make every provider feature identical. Confirm whether the target model accepts tools, structured output, images, or reasoning-specific parameters before relying on them.

If you are testing a direct OpenAI deployment and LinkModel in the same application, create two clients with the same chain interface:

direct = ChatOpenAI(model="gpt-5.4-mini", api_key=os.environ["OPENAI_API_KEY"])

linkmodel = ChatOpenAI(
    model="gpt-5.4-mini",
    api_key=os.environ["LINKMODEL_API_KEY"],
    base_url=os.environ["LINKMODEL_BASE_URL"],
)

Do not select a model by string concatenation from untrusted user input. Use an allowlist such as {"fast": linkmodel, "review": direct} and choose the client in application code.

Switch models without rewriting the chain

LangChain's model interface lets the rest of a simple chain stay stable:

from langchain_core.prompts import ChatPromptTemplate

prompt = ChatPromptTemplate.from_messages([
    ("system", "You write precise, plain-English support replies."),
    ("human", "Classify this message and draft a reply: {message}"),
])

chain = prompt | llm
result = chain.invoke({"message": "My invoice contains a duplicate charge."})
print(result.content)

Use a faster or lower-cost model for classification and a stronger model only for cases that need deeper reasoning. The switching policy should be observable: log the selected model, request ID, latency, token usage when returned, and whether a human accepted the output.

If several applications need centralized routing, compare this application-level approach with the LiteLLM Proxy guide. If the provider sits behind a self-hosted chat interface, the Open WebUI API setup covers the separate model-discovery layer.

For a real comparison, hold the prompt, input set, temperature policy, timeout, and retry policy constant. Compare task success and accepted-output cost, not just response speed.

Stream a response to a client

ChatOpenAI supports token streaming for compatible chat endpoints:

for chunk in llm.stream("Explain why API keys should stay server-side in two sentences."):
    print(chunk.content, end="", flush=True)
print()

Streaming improves perceived latency, but it changes error handling. The server may have already sent partial text when a later network or provider error occurs. Buffer enough metadata to associate the stream with a request ID, and tell the client how to render a failed or cancelled stream.

Add a tool with explicit boundaries

from langchain_core.tools import tool

@tool
def lookup_order(order_id: str) -> str:
    """Read the status of one order. Never changes billing or shipping data."""
    if not order_id.strip():
        raise ValueError("order_id is required")
    # Replace this with an authenticated service call.
    return f"Order {order_id}: lookup service not connected in this example."

llm_with_tools = llm.bind_tools([lookup_order])
message = llm_with_tools.invoke("Check order 1842 before drafting a reply.")
print(message.tool_calls)

This code demonstrates the tool schema; it does not pretend to have a live order system. In production, authorize the caller inside the tool, validate the ID, set a timeout, and return structured success or failure data. LangChain notes that ChatOpenAI targets the official OpenAI specification; if your provider adds fields such as custom reasoning blocks, those fields may not be extracted or preserved.

Structured output and compatibility limits

Structured output is valuable for routing, but compatibility depends on the model and endpoint. Start with ordinary JSON or a tool schema, then test malformed input, missing fields, refusal cases, and provider errors. If the endpoint does not implement the required structured-output behavior, validate a plain response yourself and fail closed.

Do not pass every OpenAI-specific parameter through a generic compatible endpoint. Unknown fields can be ignored, rejected, or interpreted differently. Keep provider-specific options behind a small adapter and document which ones are tested.

Retries, timeouts, and cost control

Use retries only for transient failures. A retry of a tool call or a paid generation can duplicate a side effect. Separate model retries from tool retries, and make writes idempotent with a request key.

At minimum, record:

• model ID and endpoint;
• input and output token usage when returned;
• latency and timeout count;
• retry count and final error class;
• tool calls and their results;
• accepted or rejected result status.

For repeated prompts, keep stable instructions at the front of the message and avoid adding irrelevant history. Context growth is both a quality and cost problem. Set a maximum history size and summarize older turns with a trusted application step.

Troubleshooting

401 or 403: check the environment variable, bearer-token handling, and whether the base URL points to the API root rather than a dashboard URL.

404: verify that the endpoint is compatible with the method you are using and that the base URL is not duplicated with /chat/completions.

Tool calls are empty: check model capability, tool schema, and whether the provider returns standard OpenAI tool-call fields.

Reasoning text disappears: this can be expected when a provider returns non-standard fields. Use the provider's native LangChain package if that metadata is part of your product behavior.

Next step

Put model selection behind configuration, run a fixed evaluation set, and promote only the model that meets your quality and cost thresholds. For media workflows driven by the same application, see the n8n workflow templates for AI media. If your agent also needs terminal-based image or video creation, review the LinkModel CLI.

Sources: LangChain ChatOpenAI documentation, LangChain's custom base URL guidance, LinkModel's first API call, and LinkModel's model reference.