The Agent-OS Semantic Gap
If you have ever watched an autonomous agent crash in production and lose hours of work because the "save state" button only backed up the chat history, you know the pain. Current checkpoint/restore (C/R) systems for agent sandboxes fall into two traps. They are either too cheap and miss critical OS state. Or they are correct but too expensive to run at scale. A new paper from HKUST, Crab, argues that the root cause is an "agent–OS semantic gap." The paper reports that Crab raises recovery correctness from 8% (standard chat-only backup) to 100%. It cuts checkpoint traffic by up to 87%. It keeps overhead within 1.9% of fault-free execution. It achieves this by treating the agent as a black box. It uses eBPF to infer which turns actually changed the system state.
The Problem
Existing C/R approaches for agent sandboxes are binary. Application-level methods like LangGraph or Claude Code persist conversational history or file changes. They ignore live runtime state. This includes background processes, installed packages, and memory modifications. When these systems recover from a crash, the environment is inconsistent. This leads to silent failures or infinite loops. The paper finds that chat-only recovery succeeds on only 8–13% of tasks on Terminal-Bench [Figure 1].
The alternative is full-state checkpointing. This means snapshotting the entire VM or container after every turn. This guarantees correctness. But it imposes prohibitive overhead. On dense hosts with 100+ sandboxes, full checkpointing creates I/O contention. It slows execution by up to 3.78× compared to no-checkpoint baselines. The paper quantifies this in [Figure 2]. Naive per-turn checkpointing generates bursty arrival rates. These overwhelm shared storage backends. The core issue is that over 75% of agent turns are stateless. They read files or wait for LLM responses without mutating the OS. Existing systems lack the context to distinguish these idle turns from active ones. They force the cost of full snapshots for trivial work.
How It Works
Crab bridges the gap with a host-side runtime. It observes OS effects at turn boundaries. It does not modify the agent or the C/R backend. The architecture, shown in [Figure 5], consists of three components:
-
The Coordinator: An HTTP reverse proxy on the agent–LLM control path. It intercepts outbound requests to identify turn boundaries. Crucially, it uses these boundaries to trigger checkpoint decisions asynchronously. When the agent sends a request, the Coordinator queries the Inspector. It decides if a checkpoint is needed. It submits the job to the C/R Engine. It then gates the LLM response. If the checkpoint is incomplete, the response is delayed until the checkpoint is durable. This overlaps checkpoint latency with LLM wait time. It hides most of the cost from the agent [Figure 6].
-
The Inspector: An eBPF-based monitor that tracks net changes to filesystem and process state. It does not look at tool calls. It looks at syscalls. For filesystems, it records create/delete/write events. It computes the net change since the last checkpoint. For processes, it uses cgroups and kernel soft-dirty page tracking. This detects new processes or memory modifications. The Inspector reports three states: no change, filesystem-only change, or process-only change. This allows the system to skip 87% of turns that produce no recovery-relevant state.
-
The C/R Engine: A host-scoped scheduler that manages checkpoint traffic. It uses two queues. A normal queue holds checkpoints still hidden behind LLM wait windows. A high-priority queue holds checkpoints exposed on the critical path. This happens when the LLM response returns before the checkpoint finishes. Workers execute the actual dump. They use ZFS for filesystems. They use CRIU for process state. The Manager assembles versioned manifests $(P_j, F_k)$. This pairs the latest process and filesystem artifacts to ensure consistent recovery points [Figure 8].
Numbers
The paper evaluates Crab on Terminal-Bench (shell-intensive) and SWE-Bench (code-repair). It uses 100 sampled tasks each. The results are stark.
- Recovery Correctness: Crab achieves 100% correctness on both benchmarks. Chat-only recovery succeeds on 8–13% of Terminal-Bench tasks. It succeeds on 9% of SWE-Bench tasks. Chat+FS (filesystem only) reaches 28–42% on Terminal-Bench. It reaches 100% on SWE-Bench. This is because SWE-Bench tasks rarely rely on long-lived processes [Figure 12].
- Overhead: Despite injecting one crash per task, Crab adds only 0–1.9% to end-to-end task time compared to fault-free execution [Figure 15]. Full per-turn checkpointing slows execution by up to 3.78× on Terminal-Bench at 96-sandbox density. This is due to I/O contention.
- Traffic Reduction: The Inspector classifies up to 87% of turns as requiring no checkpoint. On SWE-Bench, only 25% of turns require a filesystem checkpoint. Almost none require a full checkpoint.
- Inspector Accuracy: The Inspector has zero false negatives for process changes. It has 98.3% accuracy for filesystem changes. There is a 2.3% false positive rate due to conservative tracking of deleted files [Table 4].
The Coordinator adds tens of microseconds per turn. The median is 18 µs. This is negligible. The Inspector’s median latency is 54–72 ms. This is mostly hidden behind LLM wait times. Checkpoint latency is bimodal. It is 20–100 ms for filesystem-only dumps. It is 700–1000 ms for process dumps [Figure 17].
What's Missing
The paper is strong on mechanics but light on generalization.
- Workload Specificity: The results depend heavily on the sparsity of state-changing turns. The paper notes that SWE-Bench tasks rarely create long-lived processes. Filesystem-only recovery is sufficient. Shell-intensive tasks are harder. If your agent workload is dominated by heavy process manipulation, the 87% skip rate may drop. Process checkpoint costs (dominated by CRIU) will dominate. The paper does not show ablations for varying process churn rates.
- Deterministic Trace Replay: Many evaluations use deterministic trace replay. This isolates system overhead from LLM stochasticity. This removes the noise of real-world agent behavior. Retries, hallucinations, and variable tool execution times might alter the checkpoint pattern. The impact of LLM variability on the "exposed delay" metric is not fully explored.
- Restoration Cost: The paper focuses on checkpoint cost and correctness. Restore latency is mentioned briefly. The paper states that checkpoint and restore together complete in under 1 second (median/p95: 0.71/1.00 s) in the Spot Execution section. However, detailed restore benchmarks under contention are not provided. If restore happens during a critical path, the cost profile changes.
Try It
Prototype This. The architecture is straightforward. It uses an HTTP proxy, eBPF hooks, and a scheduler. The paper describes the implementation in detail. But no public repository or code link is provided in the text or digest. The biggest risk is integrating the eBPF inspectors into your existing sandbox orchestration. If you are running agents in containers or microVMs, this is a viable addition to your host infrastructure. Start with the Inspector to measure your own checkpoint sparsity. If you find that >50% of turns are stateless, the optimization is worth implementing. If not, the overhead of the proxy and eBPF may outweigh the benefits. The paper’s findings on recovery correctness are compelling enough to justify a prototype. This is especially true for long-horizon agent workloads where failure cost is high.