Compares the design background, core capabilities, feature differences, and selection recommendations of the first-generation and second-generation (MicroVM) sandbox runtimes of Agent Sandbox Flash Edition. This comparison helps you choose a runtime for existing and new workloads.
Background
Early cloud sandboxes were mainly used for one-off code execution, tool calls, and short-lived tasks. These workloads run for a short time in a relatively fixed environment, with a focus on creation efficiency, elastic scheduling, resource isolation, and execution reliability. The first-generation sandbox runtime was designed for these requirements and provides basic capabilities such as container image compatibility, lifecycle management, and dynamic storage.
As Agent tasks move toward long-running, multi-step, state-continuous, and parallel exploration workloads, the runtime must provide a more complete system environment, higher reuse efficiency, and clearer security boundaries. Such workloads include dependency installation, resuming interrupted tasks, and trying multiple solutions.
To meet these requirements, Agent Sandbox Flash Edition introduced the second-generation sandbox runtime (MicroVM). Based on lightweight virtual machine isolation, the second-generation runtime provides a runtime architecture for complex Agent workloads.
Core capabilities of the second-generation runtime
-
Complete system environment: supports service startup, access control, and dependency management, and can run more complex tasks.
-
State continuity: reduces the overhead of repeated initialization and supports resuming interrupted tasks.
-
Parallelism and reuse: supports multi-branch execution and exploration of multiple solutions to improve Agent execution efficiency.
-
Multi-operating-system support: adds Windows through a multi-VMM (virtual machine monitor) architecture and supports desktop interaction tasks such as Computer Use and OSWorld.
Positioning and selection recommendations
|
Item |
First-generation sandbox runtime |
Second-generation sandbox runtime (MicroVM, Beta) |
|
Applicable scenarios |
Existing workloads and simple Agent workloads |
New workloads and highly complex Agent workloads |
|
Key advantages |
Stable and highly compatible |
Complete system environment, state continuity, parallel scaling, and multi-operating-system support |
|
Recommendation |
Existing workloads can continue to use this runtime. Complete a compatibility assessment before you switch runtimes. |
Prioritize validation for new workloads. |
The interface format of the two runtime generations is similar, but the underlying behavior differs in areas such as image compatibility, templates, configurations, lifecycle, network, and storage. Before you switch runtimes, use your actual business templates to verify compatibility item by item.
Feature differences
E2B compatibility
|
Category |
Feature |
First-generation sandbox runtime |
Second-generation sandbox runtime (MicroVM, Beta) |
|
OCI images |
Open Container Initiative (OCI) image compatibility |
100% compatible |
Supports only Ubuntu- or Debian-based images. The image must retain system components such as systemd, openssh-server, sudo, chrony, fuse3, and iptables, or keep |
|
E2B / Sandbox |
Sandbox instance lifecycle management, including creation, connection, query, timeout, environment variables, metadata, and Pause/Resume |
✓ |
✓ |
|
E2B / Template |
Sandbox template CRUD (create, read, update, and delete), built-in envd, and template pre-warming |
Supports custom compute specifications. envd version: 0.5.2. Supports image-level pre-warming. |
Compute specifications must be at least 1 Core. envd version: 0.6.1. Supports template pre-warming, which covers configurations such as the image, compute specification, start command, and ready command. |
|
E2B / Commands |
Command execution, streaming output, background processes, stdin, and PTY |
✓ |
✓ |
|
E2B / Code Interpreter |
Code execution, context, streaming results, and data analysis |
✓ |
✓ |
|
E2B / Filesystem |
File and directory operations, upload and download, watching, and metadata |
✓ |
✓ |
|
E2B / Snapshot |
Snapshot, 1:N fork, and time travel |
✗ |
✓ |
|
E2B / Volume |
CRUD for file-system-type storage volumes |
✓ |
✓ |
|
E2B / Network |
Public URL, inbound authentication, and Layer 7 (L7) outbound Network Policy |
✓ |
✓ |
|
E2B / CLI |
Routine E2B CLI operations |
✓ |
✓ |
Agent Sandbox Flash Edition supports E2B metrics and provides observability in the console. The Metrics API is not supported yet.
For more information, see E2B compatibility.
Extended E2B capabilities
|
Category |
Feature |
First-generation sandbox runtime |
Second-generation sandbox runtime (MicroVM, Beta) |
|
Business type extension |
Multi-operating-system support |
Consistent with E2B. Supports only Linux. |
Supports Linux and Windows. Support for more operating systems is being added. |
|
Compute scheduling enhancement |
Differentiated compute Quality of Service (QoS) |
✓ |
✓ |
|
Performance and efficiency |
Built-in pre-warming for official images or templates |
✓ |
✓ |
|
Performance and efficiency |
Custom template pre-warming |
✗. Supports only image-level pre-warming. |
✓ |
|
Performance and efficiency |
Cold start latency after instance pre-warming |
Tens of milliseconds |
Tens of milliseconds |
|
Performance and efficiency |
Deep hibernation wake-up latency |
100 milliseconds to 3 seconds |
100 milliseconds to 2 seconds |
|
Lifecycle capability enhancement |
1 ms wake-up from light hibernation |
✓ |
✓ |
|
Lifecycle capability enhancement |
Enhanced sandbox instance state enumeration: adds intermediate states such as Pausing and Resuming, and failed states such as Paused failed |
✓. Snapshot is not supported. |
✓ |
|
Access control enhancement |
Allowlist and blocklist for API key callers |
✓ |
✓ |
|
Storage enhancement |
Platform-managed dynamic 1:1 mounting of cloud storage services |
OSS, NAS, AgenticFS, PolarLakebase, and JuiceFS Enterprise Edition |
OSS and AgenticFS |
|
Network enhancement |
VPC access, public network access for sandbox instances, and L7 credential replacement |
✓ |
✓ |
|
Security enhancement |
Sandbox digital identity, Agent protection, and sandbox runtime environment protection |
Planned and not available yet |
Planned and not available yet |
|
Security enhancement |
Running Docker inside the sandbox |
✗ |
✓ |
|
Observability enhancement |
Resource, request, and lifecycle metrics, including network traffic, sandbox API requests, and lifecycle statistics |
✓. Network traffic metrics and request logs are not supported. |
✓ |
|
Observability enhancement |
Metrics aggregated by Sandbox, Template, or Team, and a global observability dashboard |
✓ |
✓ |
FAQ
Is the price the same for both runtime generations?
Yes. For pricing details, see the product billing documentation.
What should I consider when migrating existing workloads from the first-generation runtime to the second-generation runtime?
First, check whether your workloads require second-generation runtime capabilities such as a complete system environment, Snapshot, support for multiple operating systems, or the ability to run Docker inside the sandbox. If you have no such requirement, continue to use the first-generation runtime.
If you need to migrate, focus on verifying image compatibility, templates, configurations, lifecycle, network, and storage. The two runtime generations use similar interfaces, but their underlying behavior differs. Test each item using your actual business templates.
Will the second-generation runtime fully replace the first-generation runtime in the future?
Long-term development focuses on the second-generation runtime. Prioritize validation for new workloads. Existing workloads on the first-generation runtime can continue to run. To switch runtimes, complete compatibility validation first.