Definitions, storage and results

Results

Storage (300-byte events; bytes written in total, events replayed on resume after a crash at a uniformly random step):

At 200 steps, the interval k: k=5 gave 1,311 kB and 2.0 replayed; k=20 gave 399 kB and 9.5; k=50 gave 216 kB and 24.5.

Stale resume (hazard 2 percent per hour, 20,000 trials): pause of 1 hour 2.2 percent, 6 hours 11.5, 24 hours 38.4, 72 hours 76.6; the closed form 1 minus 0.98 to the power of hours agrees (0.39 at 24 hours).

1. A snapshot per step is the quadratic option. It suits short runs; at hundreds of steps the write volume dominates.
2. The log is cheap to write and expensive to resume, and only works if apply is pure.
3. Interval is a latency-versus-storage decision: choose it from the longest resume time you can accept.
4. Live replay is not replay. Re-running a model gives a different run; to reproduce, store the model's output.
5. The longer the pause, the more a resume needs a guard: compare the saved premise with the current world before any irreversible step.

Design rules

• Put state in a store keyed by a run or thread id, and load it at the start of every request, so any worker can continue.
• Save before you wait and after each side effect, and give each side effect an idempotency key (module 6).
• Log model outputs and tool results, so replay and debugging use the recorded values.
• Version the schema and write migrations; refuse state newer than your code.
• Re-validate on resume: re-read the facts the next step depends on.
• Set retention: prune old checkpoints; LangGraph's documentation notes that they accumulate.
• Expire waits: a pause has a time limit after which the run is cancelled or re-planned.