What happened
Vercel's changelog says Vercel Sandbox snapshot creation is now up to 10 times faster. The company gives a median snapshot-creation time of under 0.4 seconds, compared with 4.4 seconds before the update. It also reports a 50% improvement in snapshot restore speed at p50: median restore time fell from 500 milliseconds to 250 milliseconds.
A Sandbox snapshot is part of the product's persistent-session behavior. Vercel says persistent sandboxes are the default. When a session stops, the sandbox automatically takes a snapshot; when work resumes, it starts from the latest snapshot. This means the announced measurements concern an operation on the path used to preserve and recover a sandbox's state, rather than a claim about model inference, code execution, or the total duration of an agent task.
Vercel attributes the change to the Vercel Hive Snapshot, or VHS, format. According to the announcement, snapshots can now write and restore by reusing frames within VHS. Vercel says VHS indexes data more efficiently, enabling more read and write operations to occur in parallel. The system can also restore more of a Sandbox base image in parallel with user data. Those changes, Vercel says, lead to faster snapshot operations overall.
The rollout has an important boundary. The updated behavior applies to all new snapshots, and Vercel says there is nothing for users to configure. Existing snapshots retain the earlier format. A team should therefore not read the announcement as a retroactive conversion of currently stored snapshots. The practical effect will appear as workloads create new snapshots through their normal session lifecycle.
The two performance claims should also be kept separate. “Up to 10x faster” is the headline for snapshot creation, supported by the comparison between 4.4 seconds and under 0.4 seconds at the median. Restore is described with a different measurement: 250 milliseconds versus 500 milliseconds at p50, or a 50% reduction. Neither figure establishes that every snapshot reaches the maximum claim, nor that an entire agent run becomes ten times faster.
For a builder already using Vercel Sandbox, this is an automatic runtime improvement rather than a new API surface or workflow feature. Its value depends on whether a workload frequently stops, resumes, or otherwise depends on persisted environment state. Teams with long-lived sessions that rarely snapshot may see little visible effect, while iterative or resumable workflows may encounter the faster path repeatedly.
What the archive adds
New Runtime's earlier coverage on November 2 reported that Vercel Drive-enabled Sandboxes started up to 2.4× faster, with median creation time falling from 1.7 seconds to 0.7 seconds and p95 from 2.2 seconds to 1.6 seconds, without configuration changes or pricing impact. That Field Note covered initial sandbox creation. This is a new performance fact about snapshot creation and restoration within the same product.
Trend signal
This supports Harness architecture outlives model choice. The improvement sits in the execution environment around an agent: preserving and recovering runtime state becomes faster regardless of which model a workload uses. It does not prove that harness design matters more than model choice in every application, but it is a concrete example of operational performance being changed below the model layer.
Why it matters
Persistent execution environments are useful when work needs to survive a pause, but persistence is not free: state must be saved and later recovered. Vercel's reported reduction in median snapshot creation from 4.4 seconds to under 0.4 seconds removes most of that particular save-time delay. The reported restore reduction, from 500 milliseconds to 250 milliseconds, cuts a separate portion of the resume path.
For teams running agents that work across multiple sessions, the gain may make resumed work feel closer to continuous execution. It can matter for developer tools, background workflows, or approval-gated tasks where the same environment is returned to after a pause. Still, snapshot timing is only one component of end-to-end latency. Model calls, tool execution, network access, queueing, and human review can dominate a workflow's actual completion time.
The operational advantage is that new snapshots adopt the update without setup. That lowers the cost of testing the change in a real workflow. Teams should treat it as a measured infrastructure improvement, not as evidence that their own agent task duration will fall by the headline percentage.
What happens next
- Teams using persistent Vercel Sandboxes will adopt the updated snapshot format as they create new snapshots (3 months, 75%). Watch for: Vercel publishing usage, migration, or latency data for the newer format.
Limits and uncertainty
The measurements are Vercel's reported medians. The changelog does not describe the benchmark workloads, sample size, measurement period, hardware conditions, or latency distribution beyond the stated figures. “Up to 10x” is not a guarantee for every snapshot; the specific median comparison is under 0.4 seconds against 4.4 seconds. Restore is reported at p50, not across tail latency.
Vercel does not quantify changes in complete agent-task duration, reliability, compute consumption, storage use, or price. It also does not state how the result varies by snapshot size, base image, user data, region, or application behavior. The announced improvement has not been independently measured here.
Skill to build now
If your team runs resumable work in Vercel Sandbox, instrument one representative save-and-resume path this week. Record snapshot creation time, restore time, and total session elapsed time separately before comparing results. Include the size and type of state being preserved. This makes it possible to distinguish a genuine workflow improvement from a faster internal operation that is hidden by model latency or external tool calls.
Reader takeaway
Vercel has accelerated new Sandbox snapshots and restores without requiring configuration: median creation is reported at under 0.4 seconds, versus 4.4 seconds previously, and median restore at 250 milliseconds. It is a useful runtime improvement for persistent sessions, but not a demonstrated tenfold acceleration of complete agent workflows.