LangChain Core 1.6.4 Deprecates Chat History Classes in Favor of Graph State Checkpoints

LangChain released version 1.6.4 of the Python package langchain-core on September 21, marking `BaseChatMessageHistory` and `InMemoryChatMessageHistory` as deprecated, with removal targeted for 2.0.0. This gives applications still using the older classes to store multi-turn conversations a clear signal to migrate. Existing message operations remain supported; upgrading to this patch release does not immediately remove chat history functionality. [Release announcement](https://github.com/langchain-ai/langchain/releases/tag/langchain-core==1.6.4), [PyPI release record](https://pypi.org/project/langchain-core/1.6.4/).

These two classes provided interfaces for reading, appending, and clearing messages. The pull request directs users to the official short-term memory documentation and specifically addresses the deprecation decorator’s effects on multiple inheritance: cooperative initialization calls along the inheritance chain preserve Pydantic initialization. Teams that extend history storage classes should therefore include object construction and field validation in their upgrade checks. [Pull request details](https://github.com/langchain-ai/langchain/pull/40711).

The officially recommended approach is to place conversations in the agent’s graph state and persist that state through a checkpointer. Pass a checkpointer when creating the agent, then specify a `thread_id` when invoking it. The same conversation can continue from its previous state, while different IDs keep conversations separate. Short-term memory is updated as agent invocations or tool steps complete and read again at the start of the next step, tying the memory lifecycle to the execution flow. [Short-term memory documentation](https://docs.langchain.com/oss/python/langchain/short-term-memory).

The technical difference is that persistence expands to encompass graph state. LangGraph creates full checkpoints at super-step boundaries and separately saves intermediate writes from completed nodes. If another node fails within the same step, recovery can reuse the successful nodes’ results. This mechanism supports human-in-the-loop interaction, reviewing past states, and fault recovery, but actual durability still depends on the write mode and storage backend. [Checkpointing mechanism](https://docs.langchain.com/oss/python/langgraph/checkpointers).

Development environments can use `InMemorySaver`, while the production deployment documentation recommends a database backend, such as `PostgresSaver`. Long conversations still require trimming or summarization strategies; storing the full history does not expand the model’s context window. [Deployment and memory management guidance](https://docs.langchain.com/oss/python/langchain/short-term-memory).

For migration, the engineering priorities are to inventory where the older classes are called, conversation IDs, and existing data formats, then verify conversation resumption after a restart, tool response ordering, and clearing behavior. Teams maintaining both synchronous and asynchronous storage implementations should test both paths with real conversation data. These suggested checks follow from the differences between the two interfaces; they do not imply that this release guarantees automatic migration. Teams should continue tracking the scope of removal in 2.0.0 and compatibility with integration packages, rather than simply replacing class names.