--- title: "Prebaked environment snapshots, measured" description: "Why prebaking the environment turns a two to four minute cold start into an instant one, how the layers work, and the telemetry that proves the speedup." url: "https://ara.so/blog/prebaked-environment-snapshots" section: "Blog" --- # Prebaked environment snapshots, measured _Why prebaking the environment turns a two to four minute cold start into an instant one, how the layers work, and the telemetry that proves the speedup._ Jul 2026 ยท engineering Before an agent changes a line of your code, it has to stand up a computer: a fresh machine, tools installed, your repo cloned, dependencies built. Cold, that is two to four minutes of the agent doing nothing useful. It is getting dressed. Run it thousands of times a day and setup becomes the biggest tax on the product. Prebaked snapshots remove it. Setup produces the same result every time, so you compute it once, freeze it, and reuse it. Toggle below. ## Why it pays off Setup sits on the critical path of every run, so cutting it speeds up everything at once, and it turns a per-run cost into a once-ever one. Better still, it happens in the background, off the clock the user watches, so the machine is simply already there. ## There is no single snapshot A cold start is not one cost, it is a stack. Spinning up the machine is under a second, cloning is a few seconds, dependencies run minutes, and installing the toolchain is the monster at near ninety-five seconds. The toolchain is the same for every project while your code differs per project, so no single snapshot covers all of it. ## How we do it Two ways to prebake, and two ways to never cool down. Each skips more than the last, and each toggles on its own, which is how we measure them. One: bake the tools into the image, so the ninety-five second install becomes a boot-time constant and the live steps drop to already-installed checks. Two: bake a mirror of the repo into the image, so the clone reads off local disk instead of the network, roughly halving it. Three: keep a small pool of pre-cloned machines per busy repo, so a run takes one off the shelf. Four: do not tear the machine down. Between conversation turns we keep it alive and resume, skipping setup entirely. ## It has to fail open A fast path must never become a wrong path. Images rebuild on every tool bump, canary on a real machine before traffic, and roll back with one setting. And every layer fails open: a missing or stale snapshot quietly falls back to the slow path, so you get speed when it is there and correctness always. ## Measured, not asserted None of this is asserted. Every machine start is one wide event, each stage broken out and summing to the whole, with a field for whether the clone hit the mirror or a warm machine, and a companion event for which layers were live. And we measure to the first text the user sees, not just machine-ready: a snapshot that speeds setup but not the first token improved a dashboard, not a product. What it shows: baking the tools is by far the biggest lever, since it is the only step in minutes; baking the repo is real but small, halving a clone already measured in seconds. The real ceiling is warmth. Keeping a machine alive between turns beats any bake, because it skips setup entirely, and in a chat product that follow-up speed is the number people live in. ## The takeaway Setup is expensive, identical, and in front of everything: the textbook case for compute once, reuse forever. The catch is that the environment is several different snapshots, not one. Anyone can prebake; far fewer can say, across thousands of runs, how many seconds it saved and where. The measurement is the moat.