1. Fork fidelity: fork vs. re-run
Five unrelated agent scenarios are each run twice: once forking at an intermediate step (inheriting the prefix), once from scratch. A judge model scores how close each final output is to the canonical run. Higher is better. The claim is that skipping the prefix does not cost output fidelity — and that re-running a stochastic prefix is itself a source of drift.
s1-market-entry7.675.00s2-code-review8.678.00s3-localization9.6710.00s4-incident-analysis8.008.00s5-product-brief8.334.33Judge: deepseek-chat at temperature 0, 1 rep per comparison, pass threshold 7. Raw report: fork-fidelity.json (includes every judge rationale).
2. Crash consistency: do effects fire twice?
A worker is killed with os._exit(137) mid-run against a real local HTTP service that has an idempotency key and a status query. The table is the worst case — the non_idempotent downstream — for a 6-step run with the crash at step 3. Duplicates is how many times an effect was applied more than once; 0 is the goal.
naive4443checkpoint1010durable1010durable_query0000naive re-applies the effect every time it retries. durable (the execution ledger) replays a recorded result and cuts duplicates to the single genuinely ambiguous window — the effect completed but the response was lost. durable_query closes even that window by querying the downstream for the outcome before deciding, reaching zero duplicates at every crash point.
Across the every-step sweep (24 runs per strategy, all crash points, both services): durable produced 18 duplicate applications; durable_query produced 0. Raw reports: durability-results.json and durability-sweep.json.
3. How to read this honestly
What these numbers do and do not say
Fork fidelity is a small, LLM-judged sample (five scenarios, one judge at temperature 0): it is directional evidence that the fork path is not worse than re-running, not a statistically powerful result. Crash consistency is measured against a downstream that either honours the idempotency key or exposes a status query — the real world also contains downstreams that do neither, and the benchmark does not claim otherwise. Exactly-once external effects always require a cooperative downstream; Actae shrinks the window, it does not erase the requirement.
The reports above are the raw committed output, and the harnesses that produce them are public and re-runnable: github.com/BViganotti/actae-benchmarks (MIT; install actae-client, point it at a free instance, and run harness/durability_benchmark.py or harness/fork_fidelity_suite.py). The fork mechanics they exercise are in the open-source Python SDK. A deterministic, no-API-key demo of the same fork path is in the hands-on walkthrough. The pass/fail failure matrix is documented at reliability evidence.