This PR changes how we find the cutoff for summarization, summarizing
content more eagerly if the initial cutoff point isn't safe (ie, would
break apart AI + tool message pairs)
This new algorithm is quite simple - it looks at the initial cutoff
point, if it's not safe, moves forward through the message list until it
finds the first non tool message.
For example:
```
H
AI
TM
--- theoretical cutoff based keep=('messages', 3)
TM
AI
TM
```
```
H
AI
TM
TM
--- actual cutoff, more aggressive summarization
AI
TM
```
The `HumanInTheLoopMiddleware` is missing a type annotation for the
context schema. Without the fix in this PR, the following code does not
type check:
```
graph = create_agent(
"gpt-5",
tools=[send_email_tool, read_email_tool],
middleware=[
HumanInTheLoopMiddleware(
interrupt_on={
# Require approval or rejection for sending emails
"send_email_tool": {
"allowed_decisions": ["approve", "reject"],
},
# Auto-approve reading emails
"read_email_tool": False,
}
),
],
context_schema=ContextSchema,
)
```
```
Argument of type "list[HumanInTheLoopMiddleware]" cannot be assigned to parameter "middleware" of type "Sequence[AgentMiddleware[StateT_co@create_agent, ContextT@create_agent]]" in function "create_agent"
"HumanInTheLoopMiddleware" is not assignable to "AgentMiddleware[AgentState[Unknown], ContextSchema | None]"
Type parameter "ContextT@AgentMiddleware" is invariant, but "None" is not the same as "ContextSchema | None"
```
- **Description:** if you dont pass in schema= or schema_= to
StrucutredPrompt(...) today you get a confusing KeyError. Raise a more
readable ValueError instead.
- **Issue:** na
- **Dependencies:** na
* `create_agent`'s `system_prompt` allows `str | SystemMessage`
* added `system_message: SystemMessage` on `ModelRequest`
* `ModelRequest.system_prompt` is a function of `system_message.text`,
now deprecated
* disallow setting `system_prompt` and `system_message`
* `ModelRequest.system_prompt` can still be set (w/ custom setattr) for
custom backwards compat, but the updates just get propogated to the
`ModelRequest.system_message`
---------
Co-authored-by: Chester Curme <chester.curme@gmail.com>
- **Description:** When formatting an error, `PydanticOutputParser`
dumps json with default `ensure_ascii=True`
- **Issue:** Fixes#34005
- **Dependencies:** None
- [x] **Lint and test**: Run `make format`, `make lint` and `make test`
from the root of the package(s) you've modified. **We will not consider
a PR unless these three are passing in CI.** See [contribution
guidelines](https://docs.langchain.com/oss/python/contributing) for
more.
Co-authored-by: Mason Daugherty <mason@langchain.dev>
Fixed a bug where GPT-5 temperature validation was case-sensitive,
causing issues when users
specified Azure deployment names or model names in uppercase (e.g.,
`"GPT-5-2025-01-01"`, `"GPT-5-NANO"`). The validation now correctly
handles model names regardless of case.
Changes made:
- Updated `validate_temperature()` method in `BaseChatOpenAI` to perform
case-insensitive
model name comparisons
- Updated `_get_encoding_model()` method to use case-insensitive checks
for tiktoken encoder
selection
- Added comprehensive unit tests to verify case-insensitive behavior
with various case
combinations
**Issue:** Fixes#34003
**Dependencies:** None
**Test Coverage:**
- All existing tests pass
- New test `test_gpt_5_temperature_case_insensitive` covers uppercase,
lowercase, and
mixed-case model names
- Tests verify both non-chat GPT-5 models (temperature removed) and chat
models (temperature
preserved)
- Lint and format checks pass (`make lint`, `make format`)
---------
Co-authored-by: Mason Daugherty <github@mdrxy.com>
:…l logic
Addresses Issue #34007.
Fixes a bug where aliases like 'mistral:' were inferred correctly as a
provider but the prefix was not stripped from the model name, causing
API 400 errors. Added logic to strip prefix when inference succeeds.
**Description**
This PR resolves a logic error in `init_chat_model` where inferred
provider aliases (specifically `mistral:`) were correctly identified but
not stripped from the model string.
**The Problem**
When passing a string like `mistral:ministral-8b-latest`, the factory
logic correctly inferred the provider as `mistralai` but failed to enter
the string-splitting block because the alias `mistral` was not in the
hardcoded `_SUPPORTED_PROVIDERS` list. This caused the raw string
`mistral:ministral-8b-latest` to be passed to the `ChatMistralAI`
constructor, resulting in a 400 API error.
**The Fix**
I updated `_parse_model` in
`libs/langchain/langchain/chat_models/base.py`. The logic now attempts
to infer the provider from the prefix *before* determining whether to
split the string. This ensures that valid aliases trigger the stripping
logic, passing only the clean `model_name` to the integration class.
**Issue**
Fixes#34007
**Dependencies**
None.
**Verification**
Validated locally with a reproduction script:
- Input: `mistral:ministral-8b-latest`
- Result: Successfully instantiates `ChatMistralAI` with
`model="ministral-8b-latest"`.
- Validated that standard inputs (e.g., `gpt-4o`) remain unaffected.
Co-authored-by: ioop <ioop@Sidharths-MacBook-Air.local>
Closes https://github.com/langchain-ai/langchain/issues/33983
* Adds `ModelRetryMiddleware` modeled after `ToolRetryMiddleware`
* Uses `on_failure` modes of `error` and `continue` to match the
`exit_behavior` modes of model + tool call limit middleware
* In a backwards compatible manner, aligns the API of
`ToolRetryMiddleware`'s `on_failure` with the above
* Centralize common "retry" utils across these middlewares
