Prime Sandboxes: Why the Agent’s Execution Environment Is Now a Training Variable

On September 23, 2026, Prime Intellect moved Prime Sandboxes into general availability. Each sandbox is a hardware-isolated Linux microVM with its own guest kernel, not a container around a shared host kernel. The timing matters because the infrastructure question it answers has quietly been blocking serious agentic reinforcement learning work: when you need tens of thousands of concurrent agent environments, the execution environment’s fidelity directly affects what the model learns. Prime Intellect’s core argument is that this is not an infrastructure concern but a training concern.

The Problem With Container Sandboxes for RL

The industry default for short-lived code execution has been gVisor containers. gVisor implements a Linux-compatible user-space kernel that narrows the host-kernel attack surface, which works well when workloads stay within what it implements. For agentic RL training, the gaps matter in ways that are harder to detect than outright failures.

Prime Intellect frames the issue precisely: “For agents in training, silent differences from production can be more dangerous than hard failures because they can reward behaviors that do not transfer into reality.” A hard failure terminates a rollout and gets flagged. A silent difference, such as a system call being intercepted differently or a network behavior being shimmed, teaches the agent to exploit the sandbox rather than solve the task.

Docker inside a gVisor container is the clearest example. Software engineering agents trained to work with Docker Compose workflows need Docker to behave the way it does on a production machine. gVisor “needs complex setup and even then, does not offer the full list of features.” An agent that learns to use Docker in a gVisor sandbox may learn behaviors specific to that shim. The learned policy is valid only in the training environment.

There is a second problem for researchers: the ability to shape the environment to prevent reward hacking. Prime gives a concrete example from their own work. In a browser navigation task, they used file system namespaces to hide the backing data of a mock website. This forced agents to find answers by actually navigating the browser rather than reading the source files directly. Full kernel control made that possible. A container environment constrained to a user-space kernel contract makes that kind of environment shaping difficult or impossible.

How Prime Sandboxes Work

Each Prime Sandbox boots a full Linux guest kernel inside a hardware-virtualized microVM. The isolation boundary is outside the workload, not around its system calls. The table Prime Intellect published during the launch makes the contrast explicit:

• Isolation boundary: gVisor uses a user-space kernel around container processes; Prime Sandbox uses a hardware-virtualized microVM with its own guest kernel.
• Linux compatibility: gVisor has “broad compatibility with documented syscall and subsystem gaps”; Prime Sandbox runs a real guest Linux kernel.
• Docker inside the sandbox: gVisor makes this “difficult to stand up”; Prime Sandbox offers native support.
• System-level workloads: gVisor is “constrained by the user-space kernel contract”; Prime Sandbox supports VM-native system services and low-level tools.

Despite the full VM underneath, the developer interface is container-shaped. Researchers interact with Docker images, Dockerfiles, exec commands, and file transfer, the same workflow they already use locally. Prime converts Docker images to bootable VMs beneath the surface. Creating a sandbox and running a command inside it uses:

prime sandbox create python:3.11-slim
prime sandbox run <sandbox-id> -- python3 -c "print('hello')"
prime sandbox upload <sandbox-id> ./agent.py /root/agent.py

Public images from Docker Hub work directly. Custom environments follow the standard Dockerfile workflow: build, push to the Prime registry, reference by name. Prime describes the result as “a container-shaped API in front of a fleet of microVMs.”

Scale and the Open Environment Registry

The system was designed around the workload Prime Intellect’s own researchers run: “tens of thousands of concurrent sandboxes across diverse environments every day.” Standard sandbox benchmarks test how fast a provider cold-starts many copies of the same image. Prime’s researchers run diverse curricula where different tasks require different repositories, tools, and environment configurations, while launching multiple concurrent attempts at each. The system addresses this by caching images near the compute and preferentially scheduling sandboxes where environments are already available, allowing “thousands of sandboxes within seconds.”

All accounts start with a limit of 1,024 concurrent sandboxes; teams that need more can request higher limits directly. Company-reported figures show roughly 30 million sandbox instances created during internal and early-customer use before the general availability launch.

Prime backs this with a registry of over 365,000 prebuilt environments spanning open-source software engineering, terminal use, and agentic tasks. According to Prime, this is the largest catalog offered by a sandbox provider. Task images are stored immutably, so a training run from months earlier can be reproduced against the exact environment it used, with no drift from upstream changes and no disappearing artifacts.

Prime Tunnels: Connecting Agent Rollouts to Inference

Prime Sandboxes ship alongside Prime Tunnels, which solve a practical problem in RL training setups: making an inference service running on a cluster node accessible to sandboxed agents without additional network configuration. In Prime’s verifiers library, an interception server on the researcher’s host logs each model call and forwards it to the underlying model. With one command, that server gets exposed through a public HTTPS URL and connected to many concurrent rollouts running inside sandboxes.

Both Prime Sandboxes and Prime Tunnels integrate with prime-rl and verifiers as part of Prime Intellect’s RL-native stack, rather than sitting beside them as generic execution services. The combination forms what Prime describes as “the training system we wanted for ourselves.”

Limitations and What Is Not Available Yet

Three capabilities are explicitly on the roadmap but not yet available: GPU microVMs, state snapshotting, and sandbox forking. GPU support would extend agent workloads into tasks that require accelerated computation inside the environment. Snapshotting would let researchers save and restore a sandbox mid-run, so a single mistake cannot erase hours of agent progress. Forking would allow branching from a checkpoint to explore multiple paths from the same state. Prime describes these as the next steps toward “autonomous research loops that can explore, recover, and compound progress over time.”

The 30 million sandbox figure is company-reported and covers Prime Intellect’s own internal use plus a small number of early customers before GA. The “3x cheaper than other large sandbox providers” pricing claim is valid through December 22, 2026, at the stated rates: $0.02 per vCPU per hour, $0.0125 per GiB of RAM per hour, and $0.0002 per GiB of disk per hour. Whether the performance claims about diverse-environment scheduling scale independently of Prime Intellect’s own infrastructure has not been validated externally. MicroVMs are not a new technology; what is new is their use as a massively parallel RL substrate where environment fidelity is treated as a training parameter.

What This Means for Engineering Teams

For teams building production AI agents with RL, this changes how to think about the sandbox layer. If an agent will be deployed on real Linux machines with Docker, it should train on real Linux machines with Docker. Picking a sandbox for cost or startup speed without considering system-level fidelity is now a decision about training data quality, not just infrastructure cost.

The 365,000-environment registry is practically useful beyond fidelity. Building diverse training curricula has historically required maintaining custom environments for each task category. If that catalog covers the software engineering and terminal tasks a team cares about, the curriculum-building cost drops substantially. The immutable storage also resolves a reproducibility problem that is common in long-running research: environments drift because upstream packages change, and it becomes impossible to reproduce an earlier training run.

The most direct engineering implication is for software engineering agents. If an agent is trained to handle Git, Docker Compose, build systems, and package managers, it needs to encounter those tools behaving the way they do on a production developer machine. Container-based sandboxes that paper over kernel-level differences are training the agent on a slightly wrong version of reality. Whether that matters enough to affect downstream task performance in a specific product is an empirical question, but now teams have a way to test it. For context on building production AI systems, the environment fidelity question belongs in the architecture conversation, not the deployment conversation.

Key Takeaways

• Prime Sandboxes entered general availability on September 23, 2026, giving each RL training agent a full Linux microVM with its own guest kernel rather than a shared-kernel container.
• Silent behavioral differences between containers and production environments can corrupt reward signals by teaching agents to exploit sandbox quirks, not solve real tasks.
• The developer interface is Docker-compatible: standard images, Dockerfiles, and CLI commands work without a new packaging format.
• The open environment registry contains over 365,000 prebuilt environments stored immutably, making curriculum diversity and long-term reproducibility easier.
• Default accounts support 1,024 concurrent sandboxes; pricing runs $0.02 per vCPU per hour through December 22 at roughly a third of competing providers’ rates.
• GPU microVMs, state snapshotting, and sandbox forking are roadmap items, not yet available at launch.

Work With Origins AI

Origins AI builds production AI systems for engineering teams. If your team is designing agentic RL training pipelines and needs help choosing the right execution infrastructure, talk to our team.