This feature requires the LangGraph Agent Server. Run your agent locally with
langgraph dev or deploy it to LangSmith to use this pattern.What is branching chat?
Branching chat treats a conversation as a checkpointed timeline rather than a flat list. Each message has metadata that points to the checkpoint before that message was created. Editing a message or regenerating a response submits a new run from that checkpoint. Key capabilities:- Edit any user message: rewrite a previous prompt and re-run the agent from that point
- Regenerate any AI response: ask the agent to produce a different answer for the same input
- Inspect history: use the LangGraph client to load checkpoints when you need a branch timeline
Set up stream metadata
Use the root stream for messages, then read per-message checkpoint metadata in the component that renders each message. The metadata includes the parent checkpoint ID to fork from.The code examples use
useStream<typeof myAgent> for type-safe stream state. See Type inference for Python or JavaScript backends.Understand message metadata
TheuseMessageMetadata(stream, messageId) helper returns MessageMetadata
for one message. Use it in the component that renders each message so the
metadata stays scoped to that message ID:
parentCheckpointId is the checkpoint just before the message. Use it as the
fork point for edits and regenerations.
Edit a message
To edit a user message and fork the conversation:- Get
parentCheckpointIdfrom the message’s metadata - Submit the edited message with
forkFrom: checkpointId - The agent re-runs from that point
- The agent re-runs from the fork point with the updated message
- The original path remains available in the thread history
Regenerate a response
To regenerate an AI response without changing the input:- Get
parentCheckpointIdfrom the AI message’s metadata - Submit with
undefinedinput andforkFrom: checkpointId - The agent produces a fresh response from that point
undefined input to null to continue from the checkpoint
without supplying new input. An empty object ({}) supplies new input instead.
Each regeneration creates a new path in the same thread.
How branching works under the hood
LangGraph persists state at super-step boundaries as checkpoints. Nodes that run in parallel in one super-step share a checkpoint boundary. When you submit withforkFrom, the backend starts a new execution path from that point instead
of appending to the current conversation. The result is a tree structure:
stream.client.threads.getHistory(threadId) when you want to build a separate
timeline view across checkpoints. History is newest first and defaults to 10
entries. Use each state’s parent_checkpoint to reconstruct ancestry; list
position alone does not identify a branch.
Best practices
- Read metadata near the message: call
useMessageMetadatain the component that renders the message controls. - Show fork controls on hover: edit and regenerate buttons should appear on hover to keep the UI clean.
- Refresh history on demand: call
client.threads.getHistory()only when rendering a timeline or after a fork settles. - Disable controls while streaming: don’t allow edits or regeneration
while the agent is actively streaming a response. Check
stream.isLoadingbefore enabling these actions. - Preserve edit text on cancel: if the user starts editing, then cancels, reset the textarea to the original message content.
- Test with deep checkpoint trees: users who edit and regenerate frequently can create many paths. Ensure timeline rendering remains performant.
Connect these docs to your agent of choice via MCP for real-time answers.

