OpenAI-compatible endpoints with ChatOpenAI
Many providers offer endpoints compatible with OpenAI's Chat Completions API. You can connect to these using ChatOpenAI with a custom base_url parameter. Python example: ChatOpenAI(base_url="https://your-provider.com/v1", api_key="your-api-key", model="provider-model-name"). JavaScript example: new ChatOpenAI({ configuration: { baseURL: "https://your-provider.com/v1" }, apiKey: "your-api-key", model: "provider-model-name" }).
ChatOpenAI limitations with non-OpenAI providers
ChatOpenAI targets official OpenAI API specifications only. Non-standard response fields from third-party providers are not extracted or preserved. Use a dedicated provider package or router when you need access to non-standard features.
LangChain unified API for multiple providers
LangChain gives you a single, unified API to work with models from any provider. The same code works whether you use OpenAI, Anthropic, Google, AWS Bedrock, or any other supported provider. Every LangChain chat model, regardless of provider, implements the same interface.
Benefits of LangChain's unified interface
With LangChain's unified interface, you can swap providers without rewriting application logic, compare models side-by-side with identical code, and use advanced features like tool calling, structured output, and streaming across all providers.
Provider definition in LangChain
A provider is a company or platform that hosts AI models and exposes them through an API. Examples include OpenAI, Anthropic, Google, and AWS Bedrock. In LangChain, each provider has a dedicated integration package (such as langchain-openai, langchain-anthropic) that implements the standard LangChain interface for that provider's models.
Provider integration packages
Each provider has a dedicated integration package with proper versioning and dependency management. Provider-specific features are available when needed, and automatic API key handling occurs through environment variables. For Python: use 'uv add langchain-openai', 'uv add langchain-anthropic', 'uv add langchain-google-genai'. For JavaScript/TypeScript: use 'npm install @langchain/openai', 'npm install @langchain/anthropic', 'npm install @langchain/google-genai'.
init_chat_model function syntax
The init_chat_model function accepts a provider:model format string to initialize a chat model. Example in Python: init_chat_model("openai:gpt-5.5"). Example in JavaScript/TypeScript: await initChatModel("openai:gpt-5.5"). LangChain automatically resolves the provider and loads the correct integration package. You can omit the provider prefix if the model name is unambiguous (e.g., "gpt-5.5" resolves to OpenAI).
Direct class instantiation for chat models
You can instantiate chat models directly by importing the provider-specific class and passing the model parameter. Python example: from langchain_openai import ChatOpenAI; model = ChatOpenAI(model="gpt-5.5"). JavaScript example: import { ChatOpenAI } from "@langchain/openai"; const model = new ChatOpenAI({ model: "gpt-5.5" }).
New models available immediately without LangChain update
Because LangChain provider packages pass model names directly to the provider's API, you can use new models the moment a provider releases them without requiring a LangChain update. Simply pass the new model name through the provider:model format or direct class instantiation. New model names work immediately as long as your provider package version supports the API version the model requires.
Routers and proxies overview
Routers (also called proxies or gateways) give you access to models from multiple providers through a single API and credential. They can simplify billing, let you switch between models without changing integrations, and offer features like automatic fallbacks and load balancing.
Router providers and integrations
Available routers include: OpenRouter (ChatOpenRouter) providing unified access to models from OpenAI, Anthropic, Google, Meta, and more; FuturMix (ChatOpenAI) providing unified AI gateway for 22+ models with OpenAI-compatible API and 99.99% SLA; LiteLLM (ChatLiteLLM) providing unified interface for 100+ providers with routing, fallbacks, and spend tracking.
When to use routers
Routers are useful when you want to access many providers with a single API key and billing account, switch models dynamically without managing multiple provider credentials, or use fallback models that automatically retry with a different model if the primary one fails.
Using routers with init_chat_model
You can use routers with init_chat_model by passing the router provider:model format. Example in Python: init_chat_model("openrouter:anthropic/claude-sonnet-4-6"). Example in JavaScript: await initChatModel("openrouter:anthropic/claude-sonnet-4-6").
OpenWiki supported model providers
OpenWiki supports OpenAI, Anthropic, Gemini, Bedrock, OpenRouter, GitHub Copilot, and other providers out of the box.
OpenRouter provider pinning
When OpenRouter serves a model through multiple upstream providers, restrict routing by setting OPENWIKI_PROVIDER=openrouter, OPENROUTER_API_KEY to your key, and OPENWIKI_OPENROUTER_PROVIDER_ONLY to a specific provider name (e.g., Novita).
OpenWiki provider retry configuration
Provider retries after the first request are configured with OPENWIKI_PROVIDER_RETRY_ATTEMPTS. The value must be a positive integer. If unset, OpenWiki defaults to 3 retries.
OpenWiki model providers table
OpenWiki supports the following inference providers and their credential requirements. Provider: openai, Credential: OPENAI_API_KEY, Notes: Optional OPENAI_BASE_URL for OpenAI-compatible gateways that expose the Responses API. Provider: openai-chatgpt, Credential: ChatGPT OAuth tokens, Notes: Sign in with ChatGPT; usage draws on Plus/Pro/Team Codex allowance. Provider: copilot, Credential: GitHub CLI session or COPILOT_API_KEY, Notes: Optional COPILOT_BASE_URL. CI needs an OAuth token, not a classic PAT. Provider: openrouter, Credential: OPENROUTER_API_KEY, Notes: Optional OPENWIKI_OPENROUTER_PROVIDER_ONLY allowlist. Provider: anthropic, Credential: ANTHROPIC_API_KEY, Notes: Optional ANTHROPIC_BASE_URL. Provider: gemini, Credential: GEMINI_API_KEY, Notes: Google AI Studio. Provider: gemini-enterprise, Credential: Google ADC + GOOGLE_CLOUD_PROJECT, Notes: Optional GOOGLE_CLOUD_LOCATION (defaults to global). Provider: bedrock, Credential: AWS credentials + region, Notes: Explicit Bedrock keys or the AWS SDK default chain. Provider: baseten, Credential: BASETEN_API_KEY, Notes: Optional BASETEN_BASE_URL. Provider: fireworks, Credential: FIREWORKS_API_KEY, Notes: Optional FIREWORKS_BASE_URL. Provider: nebius, Credential: NEBIUS_API_KEY, Notes: Nebius Token Factory. Provider: nvidia, Credential: NVIDIA_API_KEY, Notes: Optional NVIDIA_BASE_URL. Provider: openai-compatible, Credential: OPENAI_COMPATIBLE_API_KEY, Notes: Requires OPENAI_COMPATIBLE_BASE_URL and a custom model ID.
OpenWiki credentials storage location
Credentials and defaults are stored in ~/.openwiki/.env. Process environment values take priority over file values.
GitHub Copilot with OpenWiki
To use GitHub Copilot with OpenWiki: select it during openwiki --init. If you have an active GitHub CLI session, OpenWiki can reuse it. Otherwise, run gh auth login from the credential prompt. Choose a model such as gpt-5.5. OpenWiki leaves the GitHub CLI token in the GitHub CLI credential store and does not copy it into ~/.openwiki/.env. For CI or headless environments without a GitHub CLI session, set COPILOT_API_KEY to a GitHub OAuth token; Personal Access Tokens (classic or fine-grained) are rejected by the Copilot API for third-party integrations.
OpenAI ChatGPT login with OpenWiki
The openai-chatgpt provider calls OpenAI's Codex backend using your ChatGPT subscription instead of a metered API key. The wizard opens the OpenAI auth page in your browser (and prints the URL for headless use). After sign-in, OpenWiki stores managed OAuth tokens in ~/.openwiki/.env and refreshes the access token automatically. The refresh token should be treated like a password.
Gemini Enterprise (Vertex AI) with OpenWiki
The gemini-enterprise provider uses Google Application Default Credentials and does not require an API key. Configuration requires OPENWIKI_PROVIDER=gemini-enterprise, GOOGLE_CLOUD_PROJECT set to your GCP project, and optional GOOGLE_CLOUD_LOCATION (defaults to global). The credentials need Vertex AI access (roles/aiplatform.user), and the models you use must be enabled in Model Garden. Partner and open-weight (MaaS) models are region-specific, so GOOGLE_CLOUD_LOCATION should be set explicitly when using them.
AWS Bedrock configuration
To use AWS Bedrock with OpenWiki, set OPENWIKI_PROVIDER=bedrock and provide BEDROCK_AWS_ACCESS_KEY_ID, BEDROCK_AWS_SECRET_ACCESS_KEY, BEDROCK_AWS_REGION, and OPENWIKI_MODEL_ID (e.g., anthropic.claude-sonnet-5). When explicit Bedrock credentials are not set, OpenWiki uses the AWS SDK default credential provider chain. Paste the Bedrock model ID directly. Some newer models require a cross-region inference profile ID (for example us.anthropic.claude-sonnet-5) instead of the bare model ID.
OpenAI-compatible endpoints with OpenWiki
Use the openai-compatible provider for gateways or local servers that expose OpenAI-compatible chat completions. Set OPENWIKI_PROVIDER=openai-compatible, OPENAI_COMPATIBLE_API_KEY to your gateway key, OPENAI_COMPATIBLE_BASE_URL to your gateway URL (e.g., https://your-gateway.example.com/v1), and OPENWIKI_MODEL_ID to your gateway model name. Local examples such as Ollama (http://localhost:11434/v1) and LM Studio (http://localhost:1234/v1) use the same pattern. OpenWiki requires OPENAI_COMPATIBLE_API_KEY even when the local server ignores the key value.
Set OpenWiki active provider and model
The active provider and model are set using environment variables: OPENWIKI_PROVIDER and OPENWIKI_MODEL_ID. Example: OPENWIKI_PROVIDER=openai and OPENWIKI_MODEL_ID=gpt-5.6-terra.