DeltaCR: Process Checkpoint & Rollback

• DeltaCR is a process-state checkpoint/rollback mechanism that pairs memory and filesystem states in DeltaBox for consistent, low-latency recovery.
• It employs dual-path capture with CRIU incremental dumps and live templates via fork(), enabling sub-10 millisecond restore times in critical AI operations.
• The method guarantees correctness by maintaining consistent (filesystem, memory) pairs while scaling effectively for frequent checkpointing in stateful AI agents.

DeltaCR is not a single uniformly established term across the recent research literature. Its clearest explicit usage denotes the process-state checkpoint/rollback mechanism inside DeltaBox, a sandbox for stateful AI agents; elsewhere, closely related strings refer to distinct concepts, including $\delta$-CRDTs, IDCRN/DCRN, DCR, DDR, Gaia-based DCR calibration, and Delta-Crosscoder rather than a method literally named DeltaCR (Dong et al., 21 May 2026, Almeida et al., 2016, Liu et al., 2022, Cheng et al., 2018, Strobl et al., 2019, Lin et al., 2020, Kassem et al., 16 Feb 2026).

1. Terminological scope

The term is best understood as a disambiguation problem. In the cited sources, only one paper introduces a mechanism explicitly called DeltaCR; several others are terminologically adjacent but belong to different technical lineages.

Usage in source	Actual term	Relation to “DeltaCR”
DeltaBox	DeltaCR (Dong et al., 21 May 2026)	Explicit usage
CRDT literature	$\delta$-CRDTs (Almeida et al., 2016)	Related delta-state lineage
Deep graph clustering	IDCRN / DCRN (Liu et al., 2022)	Not named DeltaCR
Object detection	DCR (Cheng et al., 2018)	Frequent mistaken reference
Clinical density estimation	DDR (Strobl et al., 2019)	Delta-based, but not DeltaCR
Ground-based astrometry	DCR calibration (Lin et al., 2020)	Uses DCR acronym, not DeltaCR
Model diffing	Delta-Crosscoder (Kassem et al., 16 Feb 2026)	Separate “Delta-” method

The explicit DeltaCR usage is therefore system-level rather than graph-clustering, object-detection, or clinical-statistics terminology. This suggests that the label functions less as a stable field-wide name than as a collision point among several “delta” and “DCR” abbreviations.

2. DeltaCR as the process-state component of DeltaBox

Within DeltaBox, DeltaCR is the process-state half of a coupled sandbox checkpoint/rollback mechanism; DeltaFS handles filesystem state. The design target is stateful AI agents that checkpoint and restore extremely frequently during MCTS expansion, iterative debugging, and RL rollout fan-out. DeltaBox treats each search-tree node as a consistent pair of states, because filesystem-only rollback leaves stale memory, while memory-only restore may resume against the wrong files (Dong et al., 21 May 2026).

The motivation is latency. The paper states that CRIU on multi-GiB processes takes seconds, E2B reportedly takes $\sim 4$ seconds to pause a sandbox per 1 GiB RAM, Docker or container restart approaches lose process state and must replay commands, and full VM snapshots track the whole VM and still cost hundreds of milliseconds to seconds. DeltaCR addresses this by making checkpoint storage proportional to changes rather than full resident state, while preserving a fast restore path (Dong et al., 21 May 2026).

The central architectural move is dual-path process-state capture. Every checkpoint creates both a durable CRIU incremental dump chain in tmpfs and a frozen template process retained in memory. The dump path provides durability and fallback restore; the template path provides low-millisecond rollback by bypassing traditional restore pipelines and directly using fork() from a suspended process image. Incremental dumps rely on soft-dirty page tracking, and the fast restore path depends on the fact that fork() duplicates page tables rather than eagerly copying all physical memory (Dong et al., 21 May 2026).

3. Checkpoint and rollback mechanics

Checkpointing begins when the StateManager dispatches a request to the guest-side Guest State Daemon. DeltaCR submits an asynchronous CRIU incremental dump to a single-worker background thread pool. CRIU briefly SIGSTOPs the agent, writes the dump to tmpfs, and SIGCONTs the agent on completion. In parallel, DeltaFS hot-switches overlay layers so that the current writable upper becomes a frozen lower and a fresh writable upper is installed. The checkpoint is thereby defined as a consistent $(\text{filesystem}, \text{memory})$ pair (Dong et al., 21 May 2026).

After the dump completes, the Guest State Daemon writes a fork request into the agent’s control FIFO. The agent handles that request at its next quiescent point in its own main loop, performs fork() inline, and then splits into two roles. The parent immediately self-suspends with SIGSTOP and becomes the frozen template associated with the checkpoint ID; the child becomes the new active agent and continues execution. Templates are stored in a bounded template pool keyed by snapshot ID and capped at a configurable size $N_{\text{tpl}}$; if the pool is full, the least-recently-used template is evicted by SIGKILL without invalidating the durable checkpoint images (Dong et al., 21 May 2026).

Rollback begins by killing the current active agent with SIGKILL and restoring the filesystem via DeltaFS before any process resumes. DeltaCR then chooses between two restore paths. On the fast path, if the target template is still resident, DeltaCR bypasses CRIU restore and directly forks from the frozen template, producing a new child that resumes from exactly the instruction following the original checkpoint. On the slow path, if the template is absent, DeltaCR falls back to CRIU lazy-pages restore, reconstructing the process from the incremental image chain and serving pages on demand via userfaultfd. Once stabilized, the restored process can itself be frozen and reinserted into the template pool for later fast-path reuse (Dong et al., 21 May 2026).

A further latency-smoothing mechanism is async-warm. After a template-based fork, a background thread walks the child’s anonymous writable VMAs and, through /proc/[pid]/mem, reads and rewrites one byte per page. This forces private CoW copies early, off the critical path. The paper also isolates LLM network activity in a Network Proxy Daemon, so checkpoint-time SIGSTOP and template management do not break long-lived HTTPS connections or background HTTP/2 machinery inside the agent address space (Dong et al., 21 May 2026).

4. Correctness properties, performance, and limits

The main correctness invariant is that every saved state is a consistent $(\text{filesystem}, \text{memory})$ pair. On checkpoint, CRIU’s SIGSTOP barrier freezes file I/O and memory mutation at a single instant; on restore, DeltaFS switches the filesystem to the target checkpoint before DeltaCR resumes a process. If process-state dump fails, the StateManager aborts and rolls back the filesystem ioctl instead of leaving a half-state. Template eviction affects latency, not correctness, because the CRIU image chain remains available as a slow-path restore source. Garbage collection is dependency-aware: a node can be deleted only if it is unreachable and no retained node still depends on it through the CRIU incremental parent chain (Dong et al., 21 May 2026).

The reported latencies are explicitly millisecond-scale. Table 1 gives 14.57 ms checkpoint and 5.14 ms restore on the fast path, with an 8.04 ms slow-path restore. Table 4 decomposes these figures into 1.12 ms for the DeltaFS layer switch plus 13.45 ms for DeltaCR incremental dump plus fork on checkpoint, and 1.66 ms for DeltaFS restore plus either 3.75 ms for DeltaCR template fork or 7.25 ms for DeltaCR CRIU restore on rollback. Because checkpoint work is overlapped with LLM inference, agent-perceived blocking at checkpoint is reported as $0$, while restore remains on the critical path. Table 1 also characterizes DeltaBox write amplification as $O(\text{4KB})$ (Dong et al., 21 May 2026).

Scaling results emphasize the viability of template fork() for branching workloads. In an RL-like fan-out setting, median fork latency rises from 0.57 ms at $N=1$ to 0.78 ms at $N=4$, 1.67 ms at $\delta$0, and 5.47 ms at $\delta$1, with p99 reaching 14.74 ms at $\delta$2. End-to-end MCTS state-management overhead is reported as 3–6% of total time, versus 47–77% on coupled baselines. The paper attributes much of this improvement to low-latency process restore rather than to filesystem rollback alone (Dong et al., 21 May 2026).

The limitations are equally specific. Template restore inherits only the calling thread, whereas CRIU dump and restore can capture all threads; DeltaCR therefore requires checkpoint-time template creation to happen in the agent’s main loop at a quiescent point. External network side effects are not rolled back. Fast restore also depends on keeping live templates resident, so memory pressure can push restores onto the slower CRIU path. The design therefore separates correctness from performance: the dual-path scheme guarantees recovery through durable image chains, while template residency determines whether rollback is merely correct or also extremely fast (Dong et al., 21 May 2026).

5. Relation to delta-state replication and signed CRDT systems

A separate but conceptually adjacent lineage comes from distributed data types. In $\delta$3-CRDTs, a delta-mutator $\delta$4 returns a delta-state in the same join-semilattice $\delta$5 as the full object state. Local update follows

$\delta$6

remote merge follows

$\delta$7

and ordinary mutators satisfy

$\delta$8

To recover the exact semantics of standard state-based CRDTs, the paper introduces delta-intervals

$\delta$9

and the causal delta-merging condition

$\sim 4$0

This framework achieves small messages with an incremental nature over unreliable communication channels, but it is a replication theory for semilattice state rather than a process checkpoint mechanism (Almeida et al., 2016).

The same delta-oriented intuition appears again in did:crdt, which models a DID document as a product CRDT and disseminates signed mutation objects in a Merkle DAG. Each mutation has the form

$\sim 4$1

with $\sim 4$2. The paper is explicit that there is no ledger, no sequencer, and no global total order; state-merge is confluent by CRDT algebra, while the signed-delta path requires only causal delivery. The result is not a textbook $\sim 4$3-CRDT, but a hybrid signed-delta CRDT system in which authorization is evaluated against causal past rather than current state (O'Connor et al., 15 Jun 2026).

This suggests a broader delta-state family in which full-state duplication is replaced by compact change objects, but the objects are different across subfields: semilattice fragments in $\sim 4$4-CRDTs, signed DID mutations in did:crdt, and incremental process images plus live templates in DeltaCR. The shared design preference is change-based state management; the underlying semantics are not interchangeable.

6. Cross-disciplinary naming collisions

In deep graph clustering, the closest terminological neighbor is not DeltaCR but IDCRN, the "Improved Dual Correlation Reduction Network." That paper states plainly that it contains no DeltaCR method. Its actual lineage is $\sim 4$5, and the central improvement is to replace the sample-level identity target used by DCRN with a clustering-refined affinity matrix $\sim 4$6, while retaining feature-level correlation reduction toward the identity within a two-view siamese graph encoder and an IDCRM loss augmented by propagation regularization (Liu et al., 2022).

In object detection, “DeltaCR” is most plausibly a mistaken reference to DCR, "Decoupled Classification Refinement." DCR places a separate classification network in parallel with the localization network, samples hard false positives from the base detector during training, uses early ROI Pooling to enforce an adaptive receptive field, and combines detector and DCR scores at test time to re-rank detections and suppress classification-driven false positives (Cheng et al., 2018).

In causal and clinical modeling, the relevant delta-named method is DDR, "Dirac Delta Regression," not DeltaCR. DDR estimates treatment-specific conditional densities $\sim 4$7 by transforming outcomes into asymptotically Dirac delta distributions, regressing the smoothed targets $\sim 4$8, and then normalizing and optionally sharpening the resulting density estimate. In model diffing, the nearby label is Delta-Crosscoder, a separate crosscoder variant for narrow fine-tuning that adds a delta-based loss $\sim 4$9 and a latent split into shared and non-shared components, but is not abbreviated DeltaCR (Strobl et al., 2019, Kassem et al., 16 Feb 2026).

In ground-based astrometry, the pertinent acronym is DCR, differential color refraction. The Gaia-based calibration method fits

$(\text{filesystem}, \text{memory})$0

using field stars matched to Gaia DR2, and reports that for well-exposed stars in null-filter observations the median mean residual decreases from 19 mas to 3 mas after correction. This is a DCR-calibration pipeline rather than a method named DeltaCR (Lin et al., 2020).

Taken together, these cases show that DeltaCR is best treated as a term with one explicit systems meaning and several persistent near-matches elsewhere. In current usage, the technically precise sense is the DeltaBox process-state checkpoint/rollback mechanism; outside that context, the label usually requires disambiguation rather than direct interpretation.