One sandbox,
now two.
Open a terminal, make a mess, then press Split. Chalk snapshots the running sandbox and restores it into a second one beside it, with the same files and the same in-memory state, in about two seconds. Then the two go their separate ways.
Press split
Press Launch sandbox, write a file or two, then press Split on the pane. The new pane is a different sandbox restored from a snapshot of the first: same files, same /tmp, same history behind the up arrow. Split up to four panes; running processes start fresh in each fork.
What happens when you split
Sandboxes run under gVisor, which can checkpoint a whole sandbox, memory included, and boot another from the checkpoint. Split is three API calls on top of that.
Snapshot
Split checkpoints the running sandbox: its memory, its file system, and its in-memory /tmp. The source never stops, and in this demo a snapshot takes under a second.
Restore
The snapshot boots a brand-new sandbox with the same limits and the same isolation. It is running about a second later, and the snapshot is deleted once it is.
Attach
A second terminal opens on the fork, in the same directory and with the same shell history. From here the two diverge: a change in one never reaches the other.
Fork a sandbox in two calls
Snapshot a running sandbox, then create a new sandbox from the snapshot. Restore the same snapshot as many times as you like; each restore is its own sandbox. Snapshots need a host-backed sandbox (ComputeClass.HOST).
The example calls the sandbox API directly with the SDK's credentials. Dedicated sandbox.snapshot() and snapshot.restore() methods are on their way to chalkcompute. To pause a sandbox rather than copy it, see the suspend demo.
import time
import httpx
from chalkcompute import ComputeClass, Sandbox
from chalkcompute._connect import ConnectClient # the SDK's credentials
auth = ConnectClient()
auth._ensure_auth()
def call(method: str, body: dict) -> dict:
headers = {**dict(auth._rpc_metadata()), "content-type": "application/json"}
url = f"{auth._api_server.rstrip('/')}/chalk.sandbox.v2.{method}"
resp = httpx.post(url, json=body, headers=headers, timeout=120)
resp.raise_for_status()
return resp.json()
source = Sandbox(cpu="500m", memory="1Gi", lifetime="600s", compute_class=ComputeClass.HOST)
source.run()
source.exec("bash", "-c", "echo hello > /workspace/notes.txt")
# Snapshot the running sandbox; the source keeps running.
snapshot = call("SandboxSnapshotService/CreateSandboxSnapshot", {"sandboxId": source.id})["snapshot"]
# Every restore is a new sandbox, so restoring twice forks the same state twice.
fork = Sandbox.from_id(call("SandboxService/CreateSandbox", {"snapshotId": snapshot["id"]})["sandbox"]["id"])
while fork.refresh().status != "running":
time.sleep(0.2)
fork.exec("bash", "-c", "echo changed > /workspace/notes.txt")
print(source.exec("cat", "/workspace/notes.txt").stdout.decode()) # hello
print(fork.exec("cat", "/workspace/notes.txt").stdout.decode()) # changedWhy fork a sandbox
Setting up an environment is slow; copying one should not be. Snapshots turn a prepared sandbox into a starting point you can reuse.
Branch an agent's work
Snapshot an agent's sandbox at a decision point and try several next steps in parallel, each from exactly the same state.
Skip the setup
Install dependencies and load data once, snapshot, then hand every eval or test run a fork that is already warm.
Rewind
Keep a snapshot from before a risky step. If the step goes wrong, restore and carry on from the moment before it.
Same isolation
A fork inherits its source's gVisor kernel, network policy, CPU, memory, and lifetime. Forking never widens what a sandbox can reach.
About two seconds
Snapshot plus restore lands a working fork in roughly two seconds on CPU sandboxes, while the original keeps running.
Open source
The split-terminal server, its page, and the deploy script are Apache-2.0 on GitHub, built on the same sandbox API you use.
Let your agents explore in parallel
Talk to an engineer about snapshotting and forking sandboxes in your cloud, next to your data.