Branching a real task setup state: a LibreOffice Writer launch restores 3.6x faster than cold plus setup, and the snapshot-API bridge preserves and branches task state on real sessions

In one paragraph

EXP-005 showed that restoring an empty warm session saves about a second and misses its target once hygiene is added. The recurring cost in training is per rollout of the same task: reset the guest and replay the task's setup. So we tested branching a state after a real setup. Measured: the setup of public task e1fc0df3 is exactly launch libreoffice --writer; run by OSWorld's real SetupController in a Drums L0 session, cold session plus setup reaches agent-ready in p50 3.12 s; restoring a CRIU checkpoint taken after that setup reaches it in p50 0.87 s, ratio 3.6x. The checkpoint dumped in 0.35 s to a 236 MiB image; two siblings restored in 0.73 and 0.80 s; both showed Untitled 1 — LibreOffice Writer; a token typed into one sibling appeared in its clipboard and not the other's; the sharing audit under revision 2a passed with only /dev/null shared (cold pair the same); memory per added session was 238.5 MiB in both arms. All six registered thresholds pass. The first measured run failed threshold 3 for both siblings because LibreOffice's first-run "Tip of the Day" modal, part of the preserved state, swallowed the keystrokes; a cold control did the same, so it was a harness defect, not a restore failure, and the failed run is kept. The second half of this record is the snapshot-API bridge: OSWorld's public _save_state / revert_to_snapshot implemented as CRIU checkpoint and restore, validated on real sessions for task e0df059f (6 valid rollouts in each reuse mode, scores 0.0 then 1.0 on all twelve) and a mid-task branch into three siblings that scored 1.0 / 0.0 / 1.0 with the agent's own process state identical and the infrastructure reseeded. Both arms are Drums; this is not a comparison. "Drums" means the L0 prototype: namespaces, overlayfs on the sandbox's own Ubuntu 24.04 root, Xvfb, openbox; no shared-runtime (L1) result exists.

Setup

Host. One development sandbox: 4 vCPU, 16 GiB, kernel 6.18, cgroup v1, no KVM; hostname and provider not recorded. LibreOffice 24.2.7.2 from the Ubuntu 24.04 archive with only the gen VCL plugin (no GTK plugin, so no AT-SPI exposure).

Part 1, task-state branching. Registered in section 18.4 (commit 1e2f3eb, 08:42 UTC) with six thresholds: feasibility (LibreOffice dumps and restores, no workaround that drops it from the checkpoint); state preserved (Writer window with the same title in each sibling); in-app state works and is private (a unique token typed into A through the real pyautogui path is readable from A and not B, and the reverse); the C3 audit under revision 2a with a cold-pair control; latency BRANCH p50 at most 0.50 x SETUP p50; memory at most 1.05x. Amendment before the measured run (c4488e2, 08:55 UTC): the registered accessibility-tree readiness could not be evaluated because this LibreOffice build exposes nothing to AT-SPI (the a11y tree stayed at 541 bytes while 99.6% of pixels changed), so readiness became "wmctrl -l lists a window whose title contains LibreOffice Writer AND the screenshot differs from blank by more than 10%", and threshold 3 reads the clipboard through xclip after select-all and copy. Arms: SETUP = cold friendly session plus the real setup; BRANCH = restore of the post-setup checkpoint, declared not clean (browser and application state preserved), with hostname and server-RNG reseed. 10 starts per arm interleaved; memory over 3 trials to 12 sessions (not 20, to stay within host memory).

Part 2, the snapshot-API bridge. Registered in section 20 (3526b6a, 09:19 UTC). Both arms get the same reuse through the same code path: OSWorld's public snapshot API on DesktopEnv. The Drums provider implements save_state as "CRIU-checkpoint this session" and revert_to_snapshot as "destroy and restore from that checkpoint". V1: 6 rollouts of task e0df059f at concurrency 1 with reuse="none" and with reuse="post_setup", a scripted correct action, the interference canary on. V2: after the setup an agent prefix writes a unique token to a file and starts a long-lived Python process that seeds random; the state is saved as agent_prefix; three siblings are restored: A renames correctly (expected 1.0), B renames wrongly (expected 0.0), C repeats A (expected 1.0).

What ran

envd_linux.l1proto.criu_task_probe ran twice: run 1 (kept as task_branch_probe_run1_T3_dialog_harness_fail.json) and run 2 (task_branch_probe.json, commit eb571a9, 09:10 UTC). The diagnosis scripts and screenshots were committed in 93d3842. tests/test_matched_reuse_real.py ran three times: run 1 (restore race and EXDEV rename failure), run 2 (scores fixed, a 24 s sudo stall), run 3 final (run3_final.json, commit b8d1aad, 09:40 UTC). envd_linux.l1proto.findings_evidence produced findings_before_after.json. A chained-checkpoint test found and fixed a whiteout defect (chained_checkpoint_whiteout_finding.txt, commit f37be36).

Results

Part 1: branching the LibreOffice launch state (measured, run 2)

Run 1 passed thresholds 1, 2, 4, 5 and 6 (ratio 3.599; memory 235.13 vs 235.46 MiB) and failed 3 for both siblings: own_a: false, own_b: false, PASS: false.

What the saving is worth, by the author's arithmetic, not a measurement: about 2.25 s per rollout after the first of a group of G, so 2.25 s x (G-1)/G (1.97 s for G = 8): about 3% of a 60 s rollout and 0.7% of a 300 s one. The author's conclusion: "On this evidence, branching the setup state of launch-only tasks is a small saving."

Part 2: the snapshot-API bridge on real sessions (measured, run3_final.json)

Mid-task save_branch_s 1.161, restore_branch_s 0.962. The first-rollout work (setup and save, 1.86 s) is inside the 20.9 s and inside the cost; with 6 rollouts it is a large share, so these per-rollout figures are not steady state.

Failures and surprises

• The modal dialog (run 1, threshold 3). LibreOffice's first-run "Tip of the Day" dialog was part of the checkpointed state and swallowed the typed token in both siblings. The cold control (lo_debug_cold_typing.py) reproduced it with no CRIU involved: typing changed 0.0 of the pixels and the clipboard stayed empty. Run 2 clicks OK before typing. This is a harness defect; the restore preserved the state it was given, dialog included.
• The diagnosis PNGs. diagnosis/ holds four 1280x800 screenshots. Three of them, cold_before_typing.png, cold_after_typing_dialog_still_modal.png and restored_as_restored_dialog_present.png, are byte-identical (sha256 47fbd307a3f3ba957083954a6c13270115ee23c99932f4744b0d2480d1d6db98, 74938 bytes each). That is consistent with "0.0 pixels changed" and "the same dialog present", and the README says the restored shots come from a re-created sibling, not run 1's own. We flag it so nobody presents them as three distinct captures; only restored_after_dialog_dismissed_and_typed.png (54765 bytes) differs.
• Restored state broke renaming a directory (bridge run 1 and run 2 before the fix). After a checkpoint the setup directory lives in a read-only lower layer, and os.rename of a lower-layer directory fails with EXDEV ([Errno 18] Invalid cross-device link) unless the overlay is mounted with redirect_dir=on. Every restored rollout scored 0.0 after a correct action. Found only because a real evaluator scored a real action on restored state. findings_before_after.json: default rename failed, redirect_dir=on rename OK.
• A 24 s stall in every sudo (runs 1 and 2). The session's hostname did not resolve, so sudo waited 24.04 s (unable to resolve host ...) against 0.01 s with the hostname in /etc/hosts. The task's setup uses sudo, so run 1 and run 2 showed resets of about 24 to 26 s and a huge apparent reuse benefit. Those figures are invalid and are not quoted here; the author kept them because they show how an environment defect can fake a reuse benefit. This is an L0 defect for any task that uses sudo.
• A restore race (run 1): a restore into a slot whose previous session had just died failed with net: Can't restore link: -17 because the old veth is removed asynchronously; restore now waits for it.
• Chained checkpoints wrote whiteouts into the kept layer. Restoring a checkpoint of a restored session failed (mnt-v2: Can't stat mountpoint .../proc) because rmtree walked through a still-mounted overlay and wrote whiteouts for every top-level directory into the very upper layer being kept. Fixed by unmounting the restored root first; a regression test does 25 restore-and-destroy cycles.
• DesktopEnv's own bookkeeping skips the snapshot revert when it believes the environment is clean and only learns it is dirty through step; the canary's marker survived into the next rollout until the adapter marked the environment used. A property of the public API an incumbent has too.

Limitations

• Both arms are Drums L0 sessions. No incumbent exists in the sandbox, so no comparative or economic claim follows. The incumbent's equivalent (a VM snapshot after setup) is prior art and was not measured.
• One launch-only setup; the task e1fc0df3 itself was not evaluated (its evaluator needs the internet). One bridge task, e0df059f, whose evaluator is a shell getter and exact_match; librosa is stubbed and unreached; the stub list was not saved for these runs.
• Effects on valid rollouts per hour were not measured. Tasks with downloads (host unreachable, licence unresolved), logged-in or networked state, restore on another host, and heavy mid-task state (a live browser page, an application mid-edit) were not tested; only a file, a background process and a directory were branched in V2.
• Whether ordinary non-friendly L0 sessions share the rename limitation was not tested.
• V2's A, B and C share one prefix by construction and are labelled agent_prefix; they are not three independent rollouts.
• No L1 result exists.

Reproduce

PYTHONPATH=<OSWorld checkout>:envd-linux:compare DRUMS_CRIU_HOME=<private criu dir> \
  <osworld venv python> -m envd_linux.l1proto.criu_task_probe --out probe.json \
  --task <e1fc0df3.json> --starts 10 --trials 3 --max-n 12
DRUMS_OSW_PYTHON=<venv python> DRUMS_OSW_SRC=<OSWorld checkout> pytest envd-linux/tests/test_matched_reuse_real.py

Needs root, overlayfs, Xvfb, openbox, LibreOffice, the OSWorld kit and CRIU 4.2. Compare latency.ratio_setup_over_branch_p50 and stages.T3_* in the probe output, and v1_*.valid, v2.PASS_iii_divergent in the bridge output.

Sources

• docs/data/l1-criu/task_branch_probe.json, task_branch_probe.log (run 2, eb571a9, 2026-10-24 09:10:20 UTC)
• docs/data/l1-criu/task_branch_probe_run1_T3_dialog_harness_fail.json (run 1, kept)
• docs/data/l1-criu/diagnosis/README.md, lo_debug_a11y.py, lo_debug_cold_typing.py, lo_restored_shots.py, the four PNGs (93d3842)
• docs/data/l1-criu/matched_reuse/run3_final.json (b8d1aad, 09:40:04 UTC), run1_restore_race_and_EXDEV.json, run2_after_redirect_dir_with_24s_sudo_hostname_stall.json, findings_before_after.json, chained_checkpoint_whiteout_finding.txt, reset_decomp.py, reuse_dbg.py, sudo_dbg.py
• docs/l1-shared-runtime-design.md sections 18 (1e2f3eb), 18.5 (c4488e2), 19, 20 (3526b6a), 21, 21.4
• envd-linux/envd_linux/l1proto/criu_task_probe.py, findings_evidence.py; envd-linux/tests/test_matched_reuse_real.py, tests/test_criu_restore.py; compare/drums_compare/osworld_matched.py
• Branch claude/linux-comparison-prep; result file data/results/exp-021-task-branching.json on this site