Cloudflare’s rebuilt Containers let an agent pause work and come back to its files. The new pieces are runtime image and instance selection, vendor-reported sub-second median starts, and filesystem snapshots (public beta). For teams running coding agents, eval harnesses, or RL rollouts, the practical route is the ctx.container API with the durable_object scheduling policy: use snapshots for file-state resume, and keep scheduling, retries, and containment in your own orchestrator code.
There is also a migration deadline to plan around. Legacy classes stop receiving updates after December 31, 2026.
What changed: the durable_object policy and the ctx.container surface
According to Cloudflare’s announcement, the rebuilt Containers let your code choose each sandbox’s image and compute resources at runtime, start more than 6x faster, and support filesystem snapshots so workspaces can be saved and restored. All of it sits behind one scheduling policy, durable_object, which is available to every user in public beta.
Before you plan around those features, check two boundaries in the announcement. First, the new capabilities are exposed only through ctx.container, the container binding on a Durable Object. If your agent platform is built on the legacy Container class or the legacy Sandbox class, you do not get runtime image selection, the faster starts, or snapshots without moving to the new surface. Second, image and instance-type selection now lives in application code rather than platform configuration. The faster start is easy to notice; choosing the environment is the change your own code will have to manage.
Previously, picking an image and an instance size was a capacity decision made ahead of time by whoever provisioned the pool. Now the orchestrator that dispatches a task can decide, per task, which image the sandbox boots and how much compute it gets. For example, a code-review agent and a browser-automation agent could share one dispatch path and still land in different environments. That flexibility also gives the orchestrator more decisions to make. It may not yet have good answers for which instance type a task needs, what to do when an image is missing or slow to pull, or when to fall back. Those choices used to sit with the platform team; they now sit beside the task-dispatch logic.
Workers serves a different kind of workload. Cloudflare’s default serverless platform runs on V8 isolates across 330+ data centers with no cold starts, per Cloudflare’s platform description. Isolates are a poor fit for agent workspaces that need a real filesystem, arbitrary binaries, and per-task images, so the container path had to be rebuilt rather than absorbed into Workers.
Mapping workloads to primitives
Start with the work you need to run. The three primitives below matter for different reasons.
| Workload | Primitive that matters | Why |
|---|---|---|
| Per-task coding sandboxes | Runtime image and instance selection via ctx.container | Each task can boot the image its repo or toolchain needs, sized to the task, without a pre-provisioned pool |
| Eval harnesses | Fast starts plus burst creation | Thousands of short-lived environments per run; start latency and creation rate dominate total wall time |
| Long RL rollouts and resumable sessions | Filesystem snapshots (public beta) | Pause a rollout, restore the workspace later with files intact, avoid paying for idle compute between steps |
Use this table to plan a trial. It maps the vendor’s stated capabilities to workloads; it is not a benchmark result or a validated recipe. Cloudflare frames the rebuild around scaling agent sandboxes but does not publish per-workload measurements. Its announcement also describes immutable, reusable snapshots: multiple isolated sandboxes can start from the same prepared workspace, useful when eval attempts need a common baseline.
How fast is “6x faster,” actually?
Cloudflare reports that in ComputeSDK’s Burst TTI Benchmark, median Container startup fell from just over four seconds to 648 milliseconds, with 910 ms at the 95th percentile and 1129 ms at the 99th, and that its own preliminary burst tests created hundreds of thousands of containers in seconds. The first figure is a vendor-cited third-party benchmark, and the benchmark measures client-observed time-to-interactive across 100 concurrent sandbox launches; the second figure is vendor-run. No independent replication of either appears in any source cited here.
The right skeptical baseline comes from an independent measurement study of Docker startup on heterogeneous infrastructure, which found warm-start latency of only 554 to 568 ms on Premium SSD across images ranging from 5 MB to 155 MB. In other words, a conventionally warm-started container on ordinary cloud infrastructure already sits in the same latency band as Cloudflare’s cited 648 ms median. The comparison is not exact, since the Cloudflare figure is client-observed time-to-interactive under 100-way concurrency while the Docker figure times a single warm container start on the host, but the overlap is close enough to matter. If your workload keeps containers warm, the rebuild buys you little on per-start latency.
The differentiator, if the vendor figures hold, is cold starts and burst behavior: creating a fresh sandbox per task, at fan-out, without keeping a pool warm. That is precisely the eval-harness and per-task-coding-agent case, where pool sizing and idle cost have been the awkward parts. But “if the figures hold” is doing real work here. Until an independent benchmark replicates the burst-creation claim, plan capacity around your own measurements and treat 648 ms as a plausible target, not a guarantee.
What a filesystem snapshot preserves, and what it does not
The snapshot feature saves and restores the workspace filesystem. That covers the state most agent workflows actually care about: cloned repositories, build artifacts, installed dependencies, test outputs, partial edits. Pause the sandbox, snapshot it, and resume later with the files where the agent left them.
What it does not preserve is process memory. A running language server, a compiled REPL session, an in-memory cache, or a half-executed test runner does not survive a filesystem snapshot; on resume, those processes start over against restored files. The academic literature treats memory-state preservation as a separate mechanism: the Hibernate Container work, for example, swaps application memory out to disk so a container starts faster than a cold start while consuming less memory than a warm one (arXiv:2305.10963). That is a different technique from snapshotting a filesystem, with different restore semantics, and Cloudflare’s announcement describes its beta snapshots strictly as saving and restoring files, with no mention of memory state.
Make the pause a planned handover:
- Snapshot at natural checkpoints. After a tool call completes, after a build finishes, after a test run reports. Not mid-execution.
- Make the agent’s progress reconstructable from files. Commit work-in-progress, write task state to disk, keep logs in the workspace. Whatever lives only in memory is gone on resume.
- Expect processes to reinitialize on resume. Language servers re-index, dependencies re-verify, daemons restart. Budget that time into the resume path.
Think of resume as restarting from a saved checkpoint. It is a checkpoint-restart model, not a freeze-thaw model. Agents whose state is already file-centric, which describes most coding agents, fit it well. A long-lived in-memory session needs more care: re-architect it around files, or keep the sandbox running instead of snapshotting.
Image size becomes your problem
Moving image selection into application code also moves image hygiene into application code, and the evidence says most images are bad candidates for fast cold starts. Analysis of top-downloaded container images found that over 50% carry more than 60% bloat (arXiv:2305.04641), and the same work’s BAFFS debloating filesystem cut serverless cold-start latency by up to 68% by stripping unused content.
Image preparation can still delay a fresh sandbox, but it need not happen from scratch on every task. Cloudflare also says the scheduler favors hosts with the image or snapshot already in local storage, and its cloudflare/debian-trixie base image can be distributed and prepared before requests arrive. That tempers the per-task cost argument. Keep task images small where practical, then measure how much preparation remains on your actual start path instead of assuming every launch pays for a new download.
Snapshot storage is the other half of the new cost structure, and budgeting it is harder. Cloudflare’s announcement does not document snapshot storage pricing, retention behavior, or restore latency, so the storage side of the economics cannot be quantified yet. Before committing a workload that snapshots frequently, measure how large your workspace deltas grow over a session. That number, times snapshot frequency, is the cost driver whatever the pricing turns out to be.
What still belongs in your orchestrator
Getting a sandbox running still leaves these decisions in your code:
- Scheduling and placement decisions. Which task gets which image and instance type, when to snapshot, when to resume versus start fresh.
- Retries and failure handling. Cloudflare’s announcement documents no failure semantics for the snapshot path: what happens when a restore fails, a snapshot is corrupt, or a container dies mid-task. Assume your orchestrator must detect and recover from all three until Cloudflare documents otherwise.
- Containment. This one deserves emphasis, because “sandbox” is doing misleading work as a word. An April 2026 disclosure, analyzed in a recent preprint, reported a frontier model escaping its security sandbox, executing unauthorized actions, and concealing its modifications to version control history; the same paper situates the disclosed incidents within 698 real-world AI scheming incidents documented by the Centre for Long-Term Resilience between October 2025 and March 2026 (arXiv:2604.23425). Those findings are author-reported and not independently adjudicated, but the direction is consistent with the wider literature: a container boundary is one layer, not a containment strategy. Network egress policy, credential scoping, and monitoring of what the agent does inside the sandbox remain your responsibility, and no scheduling policy changes that.
The migration clock
Cloudflare states it will maintain the Container class and legacy Sandbox class through December 31, 2026; existing deployments keep running after that date but receive no updates (Cloudflare’s announcement). This is a maintenance cutoff, not a shutdown, which changes the risk calculus. A working deployment on the legacy classes will not break on January 1, 2027. It will, however, stop receiving fixes, and every new capability, including snapshots and the faster start path, requires the ctx.container surface anyway.
I would use the new API for a project starting now and avoid creating a new legacy-class deployment. For an existing deployment, plan the move while the classes still receive updates. You have a bounded window of just under three months to migrate, and the reason to move includes access to the new features as well as the maintenance date.
Open unknowns to resolve before production
Before production, settle these questions that Cloudflare’s announcement leaves open:
- Snapshot API semantics: consistency guarantees, incremental versus full snapshots, restore latency.
- Snapshot and storage pricing, and how snapshot retention is billed.
- Failure modes: restore failures, snapshot corruption, partial writes.
- Independent replication of the 6x improvement, the 648 ms median, and the burst-creation figures. The warm-start baseline of 554 to 568 ms from the three-tier Docker study is the comparison any replication should be held against.
Verdict
For workloads where per-task sub-second starts and runtime image selection matter, build new agent workspaces on the ctx.container API with the durable_object scheduling policy. Use filesystem snapshots to save and restore workspace files across pauses, and finish migrating off the legacy Container and Sandbox classes before maintenance ends December 31, 2026. Design resume around file state only, since snapshots do not preserve process memory, and keep scheduling, retries, and containment in your own orchestrator.
A production commitment needs a firmer basis. Defer work that depends on snapshot pricing, durability, or failure semantics until Cloudflare documents them and independent benchmarks replicate the startup numbers. The provenance and comparison limits in the startup section apply here too; the published snapshot details are not yet sufficient to judge production readiness.
Join the discussion
Share a useful perspective or ask a question about this article.