Moonshot AI’s Kimi team and kvcache-ai have open-sourced AgentENV (AENV), a distributed platform designed to run agent environments at scale. AgentENV is used for agentic reinforcement learning (RL) training for Kimi K3, Moonshot’s 2.8-trillion-parameter Mixture-of-Experts model. The project is released under an MIT license.

Why environment infrastructure is a bottleneck for agentic RL

Agentic RL requires more than sampling text from a model. It requires the model to act inside a real computer environment. Each rollout needs an isolated Linux environment with a filesystem, a network stack, and live processes. In this kind of training loop, the environment is part of the data-generation path, so reset speed, isolation, and the ability to reproduce or branch task states directly affect how many useful rollouts can be collected.

That requirement creates a difficult infrastructure trade-off. Containers can start quickly, but they share the host kernel, which weakens isolation when model-generated code is executed. Full virtual machines provide stronger isolation, but they boot more slowly and continue to hold memory while idle.

AgentENV is designed to address that gap. It runs Firecracker microVMs and aims to make idle states, restarts, and branching inexpensive enough to support training-scale workloads.

Inside AgentENV’s Firecracker-based architecture

Each AgentENV sandbox runs as a Firecracker microVM with its own Linux kernel, filesystem, and network namespace. Requests are received through an Axum HTTP API, which forwards them to an orchestrator responsible for managing the sandbox lifecycle.

Storage is a central part of the design. The root filesystem is served through a ublk userspace block device backed by overlaybd layered images. Read-only base layers are shared across sandboxes, while each sandbox writes to its own upper layer.

Inside every guest environment, a daemon called envd manages 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 virtual machine.

The project also describes two mechanisms for improving density. The host page cache is shared across storage and memory-snapshot data. Memory ballooning returns reclaimable guest memory to the host, helping sustain overcommit as environments diverge over time.

Snapshot, pause, resume, and fork

Snapshotting, pausing, resuming, and forking are the core features behind AgentENV. The system snapshots memory and filesystem changes incrementally instead of writing a complete image each time.

The reported performance figures state that snapshot-backed environments boot or resume in under 50 ms and pause in under 100 ms. Incremental snapshot capture is reported to complete in under 100 ms, even under heavy disk modification.

Forking is the feature most specific to RL workloads. A running sandbox can clone itself into up to 16 independent child sandboxes on the same node. The source environment pauses briefly during capture and then resumes. Each child inherits the source filesystem, memory, and resource configuration.

The practical result is that expensive setup can be performed once. A team can install dependencies, clone a repository, and reach a given task state, then branch that exact state into parallel rollouts. That matters for agent tasks where repeated trials need to start from the same prepared state but explore different action trajectories. Snapshots can persist to S3-compatible object storage or to a shared distributed filesystem.

One default behavior is notable: every sandbox has a TTL, and expiration triggers a pause rather than deletion. Deletion requires passing autoPause: false on the create API.

On-demand loading and the snapshot repository

Images are loaded on demand through overlaybd. Local disk acts as a bounded cache, retaining hot data and evicting cold data.

This design supports fleet-level operation because nodes do not need to pre-warm every image or store a complete copy of every snapshot. The addressable image set can exceed local disk capacity while startup remains fast across the cluster.

Snapshot state is organized into three layers. A builder staging workspace holds artifacts during a build. A committed snapshot repository serves as the durable source of truth. A node-local runtime cache stores launch-time derived configurations.

Two repository backends are supported: posix_fs, which is the default, and oss. The oss path uses a shared S3-compatible client, so an explicit region is required.

AgentENV also includes an optional peer-to-peer transport based on iroh that can advertise committed artifacts to peer nodes. It is disabled by default. The documentation states explicitly that P2P does not change the committed snapshot model. For shared storage, the documentation calls for at least 1 Gbps and strongly recommends 10 Gbps or faster.

E2B compatibility as an adoption path

AgentENV exposes an E2B-compatible HTTP API. By pointing E2B_API_URL at an AgentENV server, users can run the official E2B Python or TypeScript SDK without code changes.

This compatibility is a deliberate distribution choice. Teams already running agents on E2B can self-host the runtime without rewriting their agent code. AgentENV also provides a native aenv CLI, which the documentation recommends for AgentENV-specific workflows.

Deployment options

AgentENV requires Linux kernel 6.8+ and access to /dev/kvm; the install script additionally requires Ubuntu 24.04. The aenv CLI supports Linux and macOS on x86_64 and arm64. The server is Linux-only because it requires KVM.

The documentation describes five deployment paths:

• An install script that runs the server as a systemd service
• A Docker image published at ghcr.io/kvcache-ai/aenv-server
• A Docker Compose stack that simulates a multi-node cluster
• Kubernetes manifests with a gateway, scheduler, and node DaemonSet
• A build-from-source route using the Rust toolchain

Multi-node deployments add a gateway on :8080 and a scheduler on :9090. The multi-node control plane is documented as a prototype, making the maturity of clustered scheduling and the operational requirements around shared storage key details for teams evaluating larger deployments.

AgentENV runs each agent environment as a Firecracker microVM rather than a container, providing kernel-level isolation. The project reports snapshot-based boot or resume times of under 50 ms and pause times under 100 ms. A running sandbox can fork into as many as 16 independent children on the same node, and the E2B-compatible HTTP API allows existing E2B Python and TypeScript SDK code to run unchanged.