Kimi and kvcache-ai Teams Open-Source AgentENV — a Distributed Platform for Training Agent RL at Kimi K3 Scale

The Moonshot AI team (creator of the Kimi K3 model), together with kvcache-ai, has open-sourced (MIT) the AgentENV platform — a distributed system for large-scale execution of agent environments, used for reinforcement learning (RL) training of their 2.8-trillion parameter mixture-of-experts (MoE) model Kimi K3. Each sandbox is a Firecracker micro-VM with its own Linux kernel, filesystem, and network namespace, providing kernel-level isolation. Sandbox lifecycle management is handled via an Axum HTTP API that routes requests to an orchestrator. The rootfs filesystem runs through ublk in userspace, using overlaybd for layered images: base layers are read-only and shared among sandboxes, while each sandbox has its own writable upper layer. Inside the guest VM, the envd daemon (port 49983) handles commands, file operations, and status reports; a reverse proxy routes HTTP and WebSocket traffic from clients to VM services. Special attention is given to reducing overhead: the host page cache is shared between storage data and memory snapshots, and a memory ballooning mechanism allows reclaiming excess guest memory to the host, supporting overcommit as environments diverge. Key features include snapshotting, pausing, resuming, and forking. Snapshots are incremental, not full. According to reported data, loading or resuming from a snapshot takes less than 50 ms, pausing less than 100 ms, and incremental snapshots, even under heavy write load, complete in under 100 ms. The fork feature, specific to RL, allows cloning a running sandbox into up to 16 independent child sandboxes on the same node. The parent sandbox is briefly paused during capture and then resumed. All child instances inherit the filesystem, memory, and resource configuration of the parent. This enables expensive setup (installing dependencies, cloning repositories) to be performed once, then the state is forked into parallel runs. Snapshots are saved to S3-compatible object storage or a distributed filesystem. By default, each sandbox has a TTL; upon expiration, it is not deleted but paused; to delete it, you must pass autoPause: false at creation. Images are loaded on demand via overlaybd with a local disk cache that stores hot data and evicts cold data. This avoids preheating every image on all nodes and can exceed local disk capacity. State is organized into three layers: a collector workspace for artifacts, a snapshot repository (persistent storage), and a local runtime cache for derived configurations. Two repository backends are supported: posix_fs (default) and oss (via a common S3-compatible client, region must be explicitly specified). An optional P2P transport based on iroh can advertise artifacts to neighboring nodes but is disabled by default. For shared storage, a minimum bandwidth of 1 Gbit/s is recommended, and 10 Gbit/s or higher is strongly recommended. For an easy transition, AgentENV provides an E2B-compatible HTTP API: just set the E2B_API_URL to your own server, and the official E2B Python/TypeScript SDKs will work without code changes to agents. A native CLI, aenv, is also available. Deployment requires Linux 6.8+ and /dev/kvm; the installation script targets Ubuntu 24.04. The CLI supports Linux and macOS on x86_64 and arm64, while the server requires Linux (needs KVM). Five deployment methods are documented: an installation script with systemd, a Docker image, Docker Compose for cluster simulation, Kubernetes manifests with gateway, scheduler, and DaemonSet, and building from Rust source. In multi-node deployments, a gateway on port 8080 and a scheduler on port 9090 are added.