The expensive part of working with a coding agent is rarely the last step. It is all the steps before it: the exploring, the false starts, the files it wrote and rewrote until the thing finally worked. Once an agent has got somewhere good, the state it is in is worth more than any individual output, and the uncomfortable truth is that you usually cannot get back to it. Run the same prompt again and you get something else.
DigitalOcean's Managed Agents runs each session in its own microVM and lets you checkpoint that whole machine, fork it, and roll it back. I wanted to see what that looks like in practice, with something visual enough that the result is obvious from a screenshot. So I had an agent build a small web app, then branched it three ways and pointed a browser at every branch.
The agent was OpenCode running DeepSeek v4 Pro, and the brief was a status dashboard for a fictional coffee roastery: four metric cards and a table of recent batches, in a single HTML file with no external resources. It took 91.6 seconds and 29,084 tokens.
I started a plain python3 -m http.server inside the sandbox and reached it with the runtime's port forwarding:
That binds to localhost on my machine and nothing else. The help text is explicit that nothing inside the sandbox is exposed publicly, which is the right default for a box with an AI agent and a shell in it. Every screenshot in this post is a real browser, Chromium driven by Playwright, loading a page served from inside a microVM through one of those tunnels.
With the dashboard working, I checkpointed the session and forked it three times from that checkpoint:
The part I keep coming back to is what was already true when the three forks woke up. I had not started anything in them. I checked each one before giving it any instructions:
The web server was running in all three, at the same PID, serving the same file. A fork here is not a copy of a disk that you then boot. It is a copy of a running machine, including the processes that were alive inside it, and each copy carries on from the moment the checkpoint was taken.
One was asked for a light, minimal Scandinavian design, one for a retro green CRT terminal, and one to keep the design and add a seven-day chart in inline SVG. They took between 25.6 and 46.7 seconds each. Throughout all of it, the original server process kept serving every edit as it landed, because it was reading the file from disk on each request.
One honest note about fork three. Its chart looks right at a glance and is wrong on inspection: the bar labelled 27 only reaches about 18 on the axis, and the one labelled 45 stops near 40. The agent got the scaling arithmetic slightly off. I left it in the screenshot because the post is about the sandbox rather than the agent, and because it is a useful reminder that a branch you like the look of still needs reading.
This is the experiment that convinced me forking is about more than saving time. I started a completely fresh session and gave it the identical prompt, word for word, on the same model:
It built a different app. Light where the first was dark, a brown header bar the first did not have, different numbers throughout: 1,847 kg of beans in stock against 2,847, eight open orders against eighteen, batch #1047 where the first run had BR-1042.
The cost was different too, and in a way that undermined a claim I was about to make. The first build took 91.6 seconds and 26,656 input tokens. The second took 31.3 seconds and 2,558. I had been planning to write that a fork saves you a minute and a half of setup, and with only two samples the setup itself varied by a factor of three.
So the real argument for forking is not speed, although the fork was quick. It is that a fork gives you exactly the state you had, the app you were looking at and liked, while a rerun gives you a different app at a cost you cannot predict. If an agent spent an hour getting a repository into shape, that shape is what you want to branch from, and re-prompting is not a way to get it back.
The other half of the feature is rollback, so I played the part of an agent having a bad afternoon. On the parent session I killed the web server and deleted the app directory entirely. The tunnel stopped answering:
The file came back, which I expected. What I did not expect was PID 593. The process I had explicitly killed was running again, restored from the memory in the checkpoint rather than restarted, and it was serving the same page.
To check it was really the same page and not something close, I compared the new screenshot with the original pixel by pixel. They differed in 88 pixels out of 792,000, every one of them inside a small status dot in the top corner. That dot pulses with a CSS animation, so the two screenshots simply caught it at different points in its cycle, and every other pixel on the page matched the original exactly.
Creating a session took 15.4 seconds. Checkpointing a running one took 25.2, which is the slowest of the platform operations and the one to plan around if you want to checkpoint frequently. Forking three ways from an existing checkpoint took 15.3, and rolling back took 5.6.