A checkpoint is a named snapshot of a running sandbox. Fork new sandboxes from it to start from a known-good environment — like git branches for VMs.Documentation Index
Fetch the complete documentation index at: https://docs.opencomputer.dev/llms.txt
Use this file to discover all available pages before exploring further.
Checkpoints vs Hibernation
| Checkpoint | Hibernation | |
|---|---|---|
| Purpose | Fork new sandboxes from saved state | Pause and resume the same sandbox |
| Original sandbox | Keeps running | Stopped |
| Can fork | Yes — unlimited new sandboxes | No |
| Count | Up to 10 per sandbox | One hibernation state |
| Use case | Parallel testing, branching experiments | Cost savings, idle timeout |
What Gets Preserved
Checkpoints capture the filesystem and installed state. Forked sandboxes start with a fresh boot from that disk state — the platform attempts warm restore when possible, but may fall back to a cold boot. Don’t assume running processes carry over.API Reference
Create Checkpoint
processing to ready (or failed).
List Checkpoints
Fork from Checkpoint
Creates a new sandbox from a checkpoint:Restore Checkpoint
Revert a sandbox in-place. All changes since the checkpoint are lost:Delete Checkpoint
CheckpointInfo
| Field | TypeScript | Python | Description |
|---|---|---|---|
| ID | id | id | Checkpoint UUID |
| Sandbox ID | sandboxId | sandboxID | Source sandbox |
| Name | name | name | Human-readable name |
| Status | status | status | processing, ready, or failed |
| Size | sizeBytes | sizeBytes | Snapshot size in bytes |
| Created | createdAt | createdAt | Timestamp |
The TypeScript SDK returns typed
CheckpointInfo objects. Python returns raw dictionaries with the HTTP API field names.