How are you all handling state for long-running agents? Stateless sandboxes are eating my evenings

ok I want to know if I am the only one. been running a local coding agent against qwen3 coder on a 4090 box, with a remote sandbox for the actual code execution. every time the sandbox dies (idle timeout, host restart, whatever) I lose the entire working directory, installed deps, any process state the agent built up. it is not just annoying, it costs real time. timed one resume cycle last night for a project the agent had been iterating on for two weeks. pip install of the repo deps 33s. model warmup and context reload 38s. restoring the working dir from s3 because I had to write my own checkpoint layer 17s. plus a few seconds of orchestration glue. total 91s before the agent can take its next turn. on a fresh session this is fine. on the 14th resume of a long-running project it makes me want to throw the machine out a window. the obvious mental model is treat the sandbox as a persistent unix box and never let it die. but every provider I looked at has some flavor of timeout. e2b paused sandboxes get deleted after 30 days and pause takes about 4s per gb of ram. modal memory snapshots expire after 7 days and are still alpha. daytona archives at 30. fly machines stop is closer to what I actually want but the cold start tax shows up again on resume. blaxel.ai claims infinite standby with sub 25ms resume but I have not stress tested it past a week yet. is anyone actually solving this without building your own checkpoint layer on top of s3 and a state machine. what is your setup. running everything in one persistent vm and eating the idle cost. snapshotting filesystem only and accepting that processes get nuked. something with temporal as the durable execution layer wrapping a sandbox provider underneath. curious especially what the loca LLM folks are doing because cold-loading a 32b quant on every sandbox resume is brutal.