This feature requires the LangGraph Agent Server. Run your agent locally with
langgraph dev or deploy it to LangSmith to use this pattern.How checkpoints work
LangGraph persists agent state after every node execution. Each persisted state is a ThreadState object that captures:- checkpoint: metadata identifying this specific snapshot (ID, timestamp)
- values: the full agent state at this point (messages, custom keys)
- tasks: the graph nodes that were scheduled to run next
- next: the names of upcoming nodes in the execution plan
Setting up useStream
Create the stream for your agent, then fetch checkpoint history explicitly from
the LangGraph client for the active thread. Resuming from a checkpoint uses
forkFrom: { checkpointId }.
The code examples use
useStream<typeof myAgent> for type-safe stream state. See Type inference for Python or JavaScript backends.Building a checkpoint timeline
The timeline sidebar shows every checkpoint as a clickable entry. Each entry displays the node that ran and how many messages existed at that point:Inspecting checkpoint state
Clicking a checkpoint should show the full state at that point. A JSON viewer gives developers complete visibility into what the agent knew and decided:Resuming from a checkpoint
The core of time travel is the ability to resume execution from any prior checkpoint. When a user selects a checkpoint, callsubmit with null input
and pass the checkpoint ID:
- Roll back to the selected checkpoint’s state
- Re-execute the graph from that point forward
- Stream the new results to the client
Resuming from a checkpoint does not delete the original timeline. The previous
checkpoints remain available in the history. This means users can always go back
and try a different path without losing any prior work.
The SplitView layout
Time travel works best with a split layout, with the main chat on the left and the timeline on the right:Extracting checkpoint metadata
Transform raw checkpoint data into display-friendly entries for your timeline:Use cases
Time travel is invaluable across many scenarios:- Debugging agent behavior: step through the agent’s decisions to understand why it chose a particular path
- Undoing actions: if the agent took a wrong turn, resume from an earlier checkpoint and try again
- Exploring alternatives: fork from a mid-conversation checkpoint to see how different inputs change the outcome
- Auditing: review the complete history of an agent’s actions for compliance, quality assurance, or post-incident analysis
- Teaching: walk through an agent’s execution step by step to explain how multi-step reasoning works
Time travel is especially powerful when combined with
human-in-the-loop patterns. If a human reviewer
rejects an agent’s action at an interrupt, they can resume from the checkpoint
before the action was taken and provide corrective input.
Handling interrupts in the timeline
Checkpoints that contain interrupts (human-in-the-loop pauses) deserve special visual treatment. They represent moments where the agent stopped and waited for human input:Best practices
- Load history lazily: for threads with hundreds of checkpoints, paginate or load only the most recent N entries to keep the UI responsive.
- Show meaningful labels: display node names and message counts instead of raw checkpoint IDs. Users need context, not UUIDs.
- Confirm before resuming: resuming from an old checkpoint replaces the current execution path. Show a confirmation dialog so users don’t accidentally lose the current conversation state.
- Highlight the current checkpoint: make it visually obvious which checkpoint corresponds to the current state of the conversation.
- Support keyboard navigation: power users will want to step through checkpoints with arrow keys. Add keyboard handlers to the timeline for a smooth debugging experience.
- Diff state between checkpoints: for advanced users, showing what changed between two consecutive checkpoints can reveal exactly how the agent’s state evolved at each step.
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

