chat_models — Message-based chat model wrappers (BaseMessage in/out)
Message-based chat model wrappers (BaseMessage in/out)
Module langchain_classic/chat_models/ — Message-based chat model wrappers (BaseMessage in/out). Part of the Models I/O group.
🎯 Why This Module Exists
Chat models accept a list of BaseMessage objects (Human/AI/System/Tool/Function) and return an AIMessage. The split from BaseLLM was forced when OpenAI introduced /v1/chat/completions: completion-style chains and agents kept working, while new code adopted the message-list interface. Tool-calling support (bind_tools, with_structured_output) lives here because it's tightly coupled to the message format.
BaseChatModel Tool calling Streaming
Architecture
flowchart LR
subgraph Core["langchain_classic/chat_models/"]
BASE["Base abstraction"]
IMPLS["Concrete implementations"]
BASE --> IMPLS
end
subgraph Up["Upstream callers"]
U1["chains/"]
U2["agents/"]
end
subgraph Down["Downstream"]
D1["langchain_core"]
D2["External providers"]
end
Up --> Core
Core --> Down
Data Flow
sequenceDiagram participant Caller as Caller participant Chat_Mod as chat_models participant Core as langchain_core participant Ext as External Caller->>Chat_Mod: invoke(input) Note over Chat_Mod: Validate & route Chat_Mod->>Core: delegate primitive Core->>Ext: provider call Ext-->>Core: response Core-->>Chat_Mod: typed output Chat_Mod-->>Caller: result
Design Decisions
| Decision | Choice Made | Alternatives | Why This Approach |
|---|---|---|---|
| Message types | Pydantic class hierarchy (HumanMessage, AIMessage, SystemMessage, ToolMessage, FunctionMessage) | Plain dicts | Type checking + IDE autocomplete + serialization for free |
| Tool calling shape | AIMessage.tool_calls list of {name, args, id} | Provider-specific format | Provider-agnostic agent loops |
| with_structured_output | Convenience method on the base | Separate parser pipeline | Hides the JSON schema dance behind a single call |
Subclasses: ChatOpenAI, ChatAnthropic, ChatVertexAI, ChatBedrock, AzureChatOpenAI, ChatOllama, ChatGroq, ... — same surface, different transport.
Step-by-Step Walkthrough
Follow a typical operation through the chat_models/ module:
-
Caller invokes the public surface — usually
.invoke(input)on a Runnable, or a legacy__call__(inputs_dict)on aChainsubclass. - Pydantic validation — every entry point is a BaseModel; constructor args, input dicts, and tool args_schema are validated before any expensive work runs. Fail-fast on type errors.
-
CallbackManager.configure — a fresh manager is built per call, fans
on_*_startevents to all subscribers (LangSmith tracer, stdout handler, custom logging), and stamps a UUID4run_idfor tree reconstruction. - chat_models-specific logic — the module's core method runs: prompt rendering, retrieval, tool execution, memory load, document split, etc. See the deep-dive sections above.
- Provider call — typically a single HTTP request to OpenAI/Anthropic/etc., or a local SDK call. Retries are handled by tenacity with exponential backoff and a configurable max-attempts knob.
-
Streaming fan-out — if the provider streams tokens, each chunk fires
on_llm_new_tokenthrough the callback manager so downstream observers (UI, log, tracer) see partial output. -
OutputParser pass — if a parser is attached, the raw provider output is parsed into a structured Python object;
OutputParserExceptionmay trigger a retry chain (RetryWithErrorOutputParser). -
Memory write-back — for chains/agents that have a
BaseMemoryattached,save_context(inputs, outputs)persists the turn before returning to the caller. -
on_*_end fan-out — the callback manager closes the run span; tracers serialise the
Runtree and ship it to LangSmith asynchronously. - Result returned — caller receives a typed object (AIMessage, dict, BaseModel, list[Document], ...) matching the module's declared output schema.
What Could Go Wrong
| Failure Mode | Trigger | Detection | Recovery |
|---|---|---|---|
| Provider 5xx / rate-limit | OpenAI/Anthropic/etc. transient error | HTTP status from SDK | tenacity retries with exponential backoff up to max_retries; then surface to caller |
| Output parser failure | LLM returned malformed JSON / wrong schema |
OutputParserException in parser |
RetryWithErrorOutputParser re-prompts with the parser error included; or surface |
| Pydantic validation | Caller passes wrong-shaped dict |
ValidationError at __init__ / invoke
|
Surface immediately — no fallback is correct here |
| Callback handler exception | User-supplied tracer raises | Try/except around each fan-out | Logged and swallowed by default; raise_error=True to opt in to propagation |
| Provider auth missing |
OPENAI_API_KEY unset |
SDK AuthenticationError
|
Surface with a helpful message; no retry (would just fail again) |
Performance Profile
Hot Paths
- Provider HTTP round-trip dominates wall-clock time (100ms–30s depending on model and prompt length).
-
Pydantic validation is repeated on every
invoke; cached schema parsing keeps it under 1ms for typical inputs. - Callback fan-out is synchronous by default — a slow handler will slow every call. Async tracers (LangSmith) push work to a background thread to avoid blocking.
Resource Usage
-
Memory: token-history buffers (in
memory/) and document caches (in retrieval pipelines) are the largest steady-state allocations. - I/O: bounded by provider rate limits; vector store I/O for retrieval-flavored modules.
-
Concurrency: async support via
a*methods; agents and parallel chains useasyncio.gatherfor concurrent tool calls.
Directory Map
Source tree for chat_models
chat_models/
├── __init__.py
├── anthropic.py
├── anyscale.py
├── azure_openai.py
├── azureml_endpoint.py
├── baichuan.py
├── baidu_qianfan_endpoint.py
├── base.py
├── bedrock.py
├── cohere.py
├── databricks.py
├── ernie.py
├── everlyai.py
├── fake.py
├── fireworks.py
├── gigachat.py
├── google_palm.py
├── human.py
├── hunyuan.py
├── javelin_ai_gateway.py
├── jinachat.py
├── konko.py
├── litellm.py
├── meta.py
├── minimax.py
├── mlflow.py
├── mlflow_ai_gateway.py
├── ollama.py
├── openai.py
├── pai_eas_endpoint.py
├── promptlayer_openai.py
├── tongyi.py
├── vertexai.py
├── volcengine_maas.py
└── yandex.py