Kimi AI and kvcache-ai Open Sources ‘AgentENV’: A Distributed System that Powers Agentic Reinforcement Learning (RL) Training for Kimi K3

Moonshot AI’s Kimi team and kvcache-ai have open-sourced AgentENV (AENV), a distributed platform for running agent environments at scale. AgentENV powers agentic reinforcement learning (RL) training for Kimi K3, Moonshot’s 2.8-trillion-parameter Mixture-of-Experts model. The code ships under an MIT license. Why Environment Infra Holds Back Agentic RL Agentic RL does not just sample text. It requires the model to act inside a real computer. Every rollout needs an isolated Linux environment with a filesystem, a network stack, and live processes. That requirement creates a hard trade-off. Containers start fast but share the host kernel, which weakens isolation for model-generated code. Full virtual machines isolate properly but boot slowly and hold memory while idle. AgentENV targets exactly that gap. It runs Firecracker microVMs, then makes idle, restart, and branching cheap enough to run at training scale. Inside AgentENV’s Firecracker Architecture Each sandbox is a Firecracker microVM with its own Linux kernel, filesystem, and network namespace. Requests hit an Axum HTTP API, which forwards to an orchestrator that manages the sandbox lifecycle. Storage is where the design gets interesting. The rootfs is served through a ublk userspace block device backed by overlaybd layered images. Read-only base layers are shared across sandboxes, and each sandbox writes into its own upper layer. Inside every guest, a daemon called envd handles command execution, file operations, and health reporting on port 49983. A reverse proxy routes HTTP and WebSocket traffic from clients to services running inside the VM. The project also lists two density mechanisms. The host page cache is shared across storage and memory-snapshot data. Memory ballooning returns reclaimable guest memory to the host, which sustains overcommit as environments diverge over time. (function(){ var f=document.getElementById("mtp-aenv-explainer"); window.addEventListener("message",function(e){ if(!e.data||typeof e.data!=="object")return; var h=e.data.aenvHeight; if(typeof h==="number"&&h>120&&h Snapshot, pause, resume, fork These four features are the reason the project exists. AgentENV snapshots memory and filesystem changes incrementally rather than writing a full image each time. The reported figures are as follows. Snapshot-backed environments boot or resume in under 50 ms and pause in under 100 ms. Incremental snapshot capture completes in under 100 ms, even under heavy disk modification. Fork is the feature most specific to RL. A running sandbox can clone into up to 16 independent child sandboxes on the same node. The source pauses briefly during capture, then resumes. Every child inherits the source filesystem, memory, and resource configuration. The practical effect is that expensive setup runs once. A team can install dependencies, clone a repository, and reach a task state. That exact state then branches into parallel rollouts. Snapshots persist to S3-compatible object storage or a shared distributed filesystem. One default is worth noting. Every sandbox carries a TTL, and expiry triggers a pause, not a delete. Deletion requires passing autoPause: false on the create API. On-demand loading and the snapshot repository Images load on demand through overlaybd. Local disk acts as a bounded cache that retains hot data and evicts cold data. This is what makes the fleet-level story work. Nodes do not need to pre-warm every image or hold a complete copy of every snapshot. The addressable image set can therefore exceed local disk capacity while startup stays fast cluster-wide. Snapshot state is organized in three layers. A builder staging workspace holds artifacts during a build. A committed snapshot repository is the durable source of truth. A node-local runtime cache holds launch-time derived configs. Two repository backends are supported: posix_fs (default) and oss. The oss