Introduction
Autonomous agents need an undo button when they corrupt the environments they are working in. Replaying only the conversation loses operating-system state, while taking a full container or VM snapshot after every turn creates unnecessary I/O and checkpoint traffic. A recent paper from researchers at the Hong Kong University of Science and Technology introduces CRAB, a runtime that observes which agent actions produce recovery-relevant state changes and checkpoints only when necessary. Across its evaluated workloads, CRAB reduced checkpoint traffic by up to 87% while maintaining 100% recovery correctness.
The main idea of this technical post is that agent snapshots should be triggered by recovery-relevant state changes, not simply by the end of every agent turn—and CRAB gives Daytona a concrete design for making that possible.
In this post, we do the following:
Examine why turn-based snapshotting creates unnecessary checkpoint traffic
Show how recovery-relevant state changes can reduce snapshot frequency without sacrificing recoverability
Explore whether CRAB’s approach can improve snapshot efficiency at production scale
Why Snapshotting Every Agent Step Falls Apart
Consider a coding agent debugging a repository. It first runs rg "deprecated_function" src/to locate the failing code without changing the environment. After tracing the bug to an outdated dependency, it runs uv pip install --upgrade pydantic, which modifies the sandbox. Snapshotting after both actions treats fundamentally different operations as equivalent: the search may require no checkpoint, while the package update creates state that must be preserved for recovery. A file edit may only change filesystem state, while a persistent process can introduce runtime state that must also be captured.
What Is CRAB?
CRAB—short for Checkpoint-and-Restore for Agent SandBoxes—is a semantics-aware checkpoint-and-restore runtime developed by researchers at HKUST. It addresses a simple problem in agent trajectories: snapshot systems capture state at every agent action, but many actions do not correspond to meaningful state changes.
A runtime can easily request a snapshot after every turn. However, many turns only read files, search a repository, or inspect logs. These actions advance the agent’s reasoning without changing the environment it may need to recover.
Imagine photographing an entire workshop after every instruction given to a worker—even when the worker only inspected a blueprint or searched for a tool. The photographs would preserve the workshop perfectly, but most would capture no meaningful change. CRAB instead checks whether the workshop itself changed before deciding what needs to be recorded.
At the end of each agent turn, CRAB observes the state left behind inside the sandbox. If nothing recovery-relevant changed, it skips the checkpoint. If the agent modified files, installed a dependency, or left a process running, CRAB selects the smallest checkpoint capable of preserving that state.
The result is not simply faster snapshotting. CRAB avoids unnecessary checkpoints, reduces the scope of the checkpoints that remain, and preserves the state required to resume execution correctly.
The full paper covers CRAB’s architecture, implementation, recovery model, and evaluation.
When Does CRAB Matter?
For a short agent task with only a few turns, taking a snapshot after every action may be acceptable. The problem appears at scale, with long trajectories, reinforcement-learning rollouts, and many sandboxes sharing the same host. These are exactly the kinds of workloads Daytona is designed to support, with thousands of sandboxes created and run in parallel with minimal operational overhead. At that scale, redundant checkpoints multiply into storage traffic and I/O contention. CRAB found that more than 70% of turns across its evaluated workloads produced no recovery-relevant state, suggesting that most per-turn checkpoints were unnecessary.
How CRAB Decides What to Capture
CRAB does not try to infer side effects from the command itself. A shell command could read files, modify dependencies, or launch a background service, and its syntax does not reliably reveal which occurred. Instead, CRAB combines agent-level turn boundaries with operating-system-level observation.
At the end of each turn, an eBPF-based Inspector tracks the net changes left behind: files that remain created or modified, processes that remain alive, and memory pages changed by persistent processes. Temporary files and short-lived subprocesses that disappear before the turn ends are ignored. The Coordinator then chooses the minimum safe checkpoint: none, filesystem-only, process-only, or full state.
CRAB also moves checkpointing away from the agent’s critical path. Imagine a worker handing their current progress to an assistant for safekeeping, then immediately stepping away to think about what to do next. While the agent waits for the next LLM response, the checkpoint engine saves the required state in parallel. If the checkpoint finishes first, the agent sees no additional delay. If the LLM responds first, CRAB briefly holds the response until the checkpoint is complete and a safe recovery point exists.
Results From CRAB
CRAB evaluates recovery by asking whether a sandbox can be restored to the state the agent expects and then continue executing correctly. This means recovering not just conversation history or files, but any filesystem and process state that later steps depend on. Missing state can leave the sandbox inconsistent with the agent’s history—for example, a dependency may no longer be installed or a background service the agent expects to be running may be gone.
CRAB was compared with two simpler recovery strategies: restoring only the agent’s conversation history and restoring the conversation plus filesystem state. Across the evaluated configurations, CRAB achieved 100% recovery correctness. On Terminal-Bench specifically, chat-only recovery achieved only 8–13%, while chat-plus-filesystem recovery achieved 28–42%. The gap shows why process and runtime state matter: many tasks depend on installed packages, background services, and other state that cannot be reconstructed from conversation history or files alone.
This is particularly relevant to Daytona because sandbox recovery does not have to stop at restoring files. Daytona’s snapshot infrastructure can preserve complete sandbox environments, including the dependencies and configuration an agent has built up during execution. CRAB provides a complementary idea: rather than taking a full snapshot after every turn, determine when that level of recovery is actually necessary and use Daytona’s snapshotting capabilities only when the agent has created state worth preserving.
CRAB’s selective policy skipped at least 70% of checkpoints across every evaluated configuration and reached 87% for Claude Code on Terminal-Bench. These numbers reflect the paper’s research implementation and test environment, not Daytona’s production snapshot infrastructure. In those experiments, running 96 co-located sandboxes while checkpointing full state after every turn slowed execution by as much as 3.78×, while the selective approach remained within 1.9% of fault-free, checkpoint-free execution. The results highlight the paper’s central contribution: preserving the state required for correct recovery while avoiding most snapshots, reducing the scope of those that remain, and hiding much of their latency behind work the system was already waiting on.
What This Could Mean For Daytona
Daytona already provides container and VM sandboxes that can be created from persistent snapshots containing files, packages, and configuration. CRAB suggests adding a semantics-aware policy layer above these mechanisms: observe what each agent turn changed, determine whether a new recovery point is necessary, and capture only the state required for safe restoration.
This methodology is already being adapted within Daytona research projects focused on large-scale agent trajectories and reinforcement-learning rollouts. The goal is not simply to reproduce CRAB, but to explore how semantics-aware checkpointing can reduce unnecessary snapshot work while preserving reliable recovery across Daytona’s container and VM infrastructure.
Conclusion
Agent snapshots should not be triggered merely because another turn has ended. They should be triggered because the agent created state that future execution depends on. CRAB shows how operating-system-visible effects can provide this signal, allowing autonomous agent systems to skip unnecessary checkpoints, capture only the state required for recovery, and move much of the remaining work outside the agent’s critical path.
For Daytona users, the opportunity is to combine CRAB’s semantics-aware checkpointing methodology with Daytona snapshots to make long-running agent tasks and large-scale rollouts more efficient. At scale, the fastest snapshot is often the one the agent workflow correctly determines it does not need to take.
