Inside Kimi K3's AgentENV: Can It Really Fork in 100 ms?

← Back to all posts

Last week when Moonshot AI announced Kimi K3, it also opened more of the infrastructure behind the model. One of those releases was AgentENV, developed with KVCache.ai to run the isolated computer environments used in agentic reinforcement learning.

That release is worth studying on its own. Agentic RL does not train only on text. A coding or computer-use agent acts inside a real operating system, runs tools, changes files, starts services, and sometimes breaks things. Training needs many such environments, strong isolation, fast pause and resume, and a cheap way to branch one prepared state into several parallel rollouts.

AgentENV arrived with an attention-grabbing claim: incremental snapshots in under 100 milliseconds, even after heavy disk modification. But what exactly completes in those 100 milliseconds? Does a forked microVM immediately own an independent copy of its memory? Where do pages changed by the source VM go before the child starts? We wanted to know whether AgentENV lives up to that headline, so we traced its dirty-page path and measured complete fork-to-first-use latency through 2 GiB of dirty memory.

Today we are going to follow AgentENV from the outside in: first its role as a distributed sandbox platform, then the virtualization concepts underneath it, and finally the detail that dominates its memory-dependent fork cost—how dirty guest pages move from the source VM into the child's immutable memory backing.

Short answer<br>AgentENV forks below the guest kernel, so the host does not reconstruct every guest process. That makes process-heavy environments fast to clone. But its current implementation still copies selected dirty guest-memory ranges into a new immutable OverlayBD layer before the fork endpoint returns. Restore is lazy; snapshot capture is not.

AgentENV is the microVM-based sandbox platform released alongside Kimi K3 for large-scale agentic workloads.

What AgentENV is at a high level

AgentENV is a self-hosted, distributed sandbox runtime for AI agents. Each sandbox is a Firecracker microVM with its own guest kernel. AgentENV can import OCI images, turn them into reusable templates, start isolated sandboxes, pause and resume them from snapshots, and fork a running sandbox into independent children. Its HTTP API is compatible with E2B clients.

At a high level, AgentENV combines Firecracker microVM isolation with OverlayBD- and ublk-backed layered storage and reusable snapshots so prepared environments can be paused, resumed, and forked efficiently.

The Kimi K3 technical report describes AgentENV as one of several sandbox runtimes used in post-training and evaluation, with the microVM boundary motivated in part by stronger isolation from aggressive agent behavior. The project documentation reports snapshot-backed boot or resume under 50 milliseconds and incremental snapshot operations under 100 milliseconds. Those are project claims for specific internal boundaries; a complete externally observed fork includes more work.

The virtualization ideas needed to understand the fork

Before we delve into AgentENV's design, we need to briefly recap the virtualization concepts that determine what a microVM fork must capture and what can be restored lazily.

1. What is a microVM, and what does Firecracker do?

A microVM is a deliberately small virtual machine. Like a conventional VM, it runs its own guest kernel and uses hardware virtualization for isolation. Unlike a general-purpose desktop VM, it exposes a minimal virtual-hardware model and is optimized to start quickly with low per-VM overhead.

Firecracker is the virtual machine monitor, or VMM, underneath AgentENV. It uses Linux KVM to run guest vCPUs, allocates the host memory that appears as physical RAM to the guest, implements a small set of virtual devices, and exposes an API for configuring, pausing, snapshotting, restoring, and resuming a microVM. AgentENV orchestrates Firecracker and adds the surrounding template, storage-layer, sandbox-networking, scheduling, and lifecycle machinery needed for an agent platform.

2. Guest RAM is host memory managed by a VMM

Inside the microVM, Linux believes it owns a range of physical memory. On the host, Firecracker represents that guest-physical memory with a virtual-memory mapping. A guest page is therefore also backed by some host page: anonymous memory for a fresh VM, or a page from a snapshot-backed file when a VM is restored.

3. A VM snapshot is several coordinated artifacts

A complete Firecracker snapshot is not one magic blob. It coordinates:

vCPU, KVM, and supported virtual-device state;

guest-memory contents;

the guest's block-device state, which the integrator manages separately.

The guest process tree does not need a separate host-side serializer. Process tables, virtual-memory areas, open files, signals, and scheduler state already live inside guest-kernel memory. This is why...