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.

35
Source files
0
Sub-directories
Models I/O
Category
Python
Language

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

DecisionChoice MadeAlternativesWhy This Approach
Message typesPydantic class hierarchy (HumanMessage, AIMessage, SystemMessage, ToolMessage, FunctionMessage)Plain dictsType checking + IDE autocomplete + serialization for free
Tool calling shapeAIMessage.tool_calls list of {name, args, id}Provider-specific formatProvider-agnostic agent loops
with_structured_outputConvenience method on the baseSeparate parser pipelineHides 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:

  1. Caller invokes the public surface — usually .invoke(input) on a Runnable, or a legacy __call__(inputs_dict) on a Chain subclass.
  2. 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.
  3. CallbackManager.configure — a fresh manager is built per call, fans on_*_start events to all subscribers (LangSmith tracer, stdout handler, custom logging), and stamps a UUID4 run_id for tree reconstruction.
  4. 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.
  5. 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.
  6. Streaming fan-out — if the provider streams tokens, each chunk fires on_llm_new_token through the callback manager so downstream observers (UI, log, tracer) see partial output.
  7. OutputParser pass — if a parser is attached, the raw provider output is parsed into a structured Python object; OutputParserException may trigger a retry chain (RetryWithErrorOutputParser).
  8. Memory write-back — for chains/agents that have a BaseMemory attached, save_context(inputs, outputs) persists the turn before returning to the caller.
  9. on_*_end fan-out — the callback manager closes the run span; tracers serialise the Run tree and ship it to LangSmith asynchronously.
  10. 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

Resource Usage

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