---
title: Checkpoints & resume
description: How session state is captured so work can be resumed after the machine is gone.
status: verified
sidebar:
  order: 4
---

Sessions are ephemeral, but their work doesn't have to be. **Checkpoints**
capture session state durably so a run can outlive the machine it ran on.

## What a checkpoint captures

After every completed agent turn, the platform snapshots the session
workspace — the working tree, including git state and untracked files, minus
build artifacts like `node_modules` — into a compressed archive in durable
storage. Retention and size caps are in the
[limits reference](/sessions/reference/limits/).

## Resume

Replying in a session's thread resumes it through the first tier that
applies: if the machine is still claimed, the session re-attaches in place
with full working state; if the machine is gone, the last consistent
checkpoint restores onto a fresh machine. In Slack, `!resume` opens a picker
of recent sessions. The full contract — and its boundary: a session is
resumable whenever a checkpoint exists and it wasn't explicitly released —
is in the [lifecycle reference](/sessions/reference/lifecycle/).

:::note
Checkpoints move sessions between *cloud* machines. Moving a session between
your terminal and the cloud is Handroll's job, and is currently limited —
see [hand-off & resume](/sessions/handroll/handoff-and-resume/).
:::

## Next steps

- [Session lifecycle reference](/sessions/reference/lifecycle/) — resume tiers, timeouts, failure modes.
- [Limits](/sessions/reference/limits/) — checkpoint retention and size caps.