Median sandbox startup in ComputeSDK's independent benchmark: 648 ms (Source: Cloudflare, citing ComputeSDK's Burst TTI Benchmark (September 30, 2026))
Who decides what software runs inside an AI agent's workspace? Until now, a deploy step usually answered that. Cloudflare's Containers update of September 30 lets application code answer it instead. The speed gain gets the headlines. The shift in control matters more.
Cloudflare says agents do not set up sandboxes ahead of time. They create one for each task and expect it to be ready at once. They also need to pause and resume it. A sandbox here is an isolated Linux workspace. An agent can run commands, install packages and edit files inside it.
That figure is down from just over four seconds, according to the benchmark results Cloudflare cites.
What changed: the choice moves to runtime
Before, two choices were fixed when a team deployed. One was the image, the software a sandbox starts from. The other was the instance type, which sets how much compute the sandbox gets. Every pairing needed its own app, set up in advance.
Cloudflare gives an example. One agent needs a small Node.js workspace. Another needs a large Python one for builds. Under the old model, a team deployed both and wrote code to send each task to the right one.
The new policy is called durable_object. With it, your code passes the image and instance type at the moment a sandbox starts. Cloudflare says a new environment becomes a code change, not a new deployment.
Each container is paired with a Durable Object. This is a persistent controller that runs next to it and manages its lifecycle.
Why it starts faster
Before, a global control plane had to read the configuration, find capacity and coordinate placement. All of that came before the agent's first command. Now the search starts where the Durable Object already runs. It tries the same machine first. Then it widens within the same location. It also favors hosts that already store the image or snapshot.
Once on a host, the runtime restores a prepared virtual machine that has not been assigned yet. It no longer boots one from scratch.
Cloudflare also published a base image for agents, named cloudflare/debian-trixie. It bundles Debian Trixie Slim and Node.js 24.20.0 LTS. Cloudflare controls this image, so it can spread it to eligible hosts before requests arrive.
The burst figure comes from Cloudflare's own preliminary test. The 648 ms figure comes from an independent benchmark that launches 100 sandboxes at once. The source offers no independent check of the larger test.
Snapshots make a sandbox something you keep
Filesystem snapshots are in public beta. An agent can save its workspace when work pauses. It can restore those files when the session resumes.
Cloudflare says a restored workspace still has the repository, dependencies, build caches, settings and the agent's edits. Nobody has to rebuild the environment.
Snapshots are also immutable and reusable. Many sandboxes can start from one prepared baseline. Cloudflare's example is an agent evaluation. The repository and tools must stay fixed while the model or prompt changes.
The governance question
This is where the change touches risk. Under the old rollout model, teams set grace periods and percentage splits. The platform chose which running instances to replace and when. That could happen in the middle of a task.
The new policy has no rollout settings. Running containers are not swapped out underneath you. They run until your code stops them. The next start gets whichever image your code names.
That gives engineering teams more control. It is also where a review step can quietly vanish. Image choice, upgrade timing and retirement of old sandboxes are now application logic. Whether that logic gets the scrutiny a deploy pipeline gets is an internal decision. The platform does not enforce it.
Saved workspaces raise a second question. A snapshot holds whatever an agent left in the filesystem. The source does not say how snapshots are retained, encrypted or expired. Those answers must come from Cloudflare's documentation and your own policy.
What to ask your team
If your organisation runs or plans agent sandboxes, these questions apply to any vendor. Cloudflare's design simply makes them easy to see.
First, who owns the code that picks an image, and who reviews changes to it? Second, how does a patched image reach sandboxes that are already running? Third, what do snapshots hold, who can restore them, and when are they deleted? Fourth, where do credentials live? Cloudflare describes the Durable Object, outside the sandbox, as a place to hold them.
Cloudflare's customer quotes, from Base44 and Kilo Code, are chosen by the vendor. They describe isolated environments for each task. They do not report measured results.
The lesson: faster sandboxes remove a technical limit. They also move decisions out of the deploy pipeline and into code. Decide who reviews that code before the sandboxes multiply.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare.
