CoreWeave Sandboxes enters public preview for RL and agent workloads

Why agents need contained execution

CoreWeave frames the product around a shift in how models are built. Models once learned by reading text and predicting the next token. Today's most capable models act: they generate code, call tools, navigate browsers and take actions for users. According to CoreWeave, training agentic AI now requires execution, with agents exploring action spaces and running the code they generate.

That code can do damage. CoreWeave's example is an agent that runs rm -rf / because it believes that is what it should do. The deletion should stay contained, the agent should learn what the action does, and the surrounding cluster should remain intact. The company calls this containment at the sandbox level: running thousands of sandboxes in parallel without one failure reaching the next.

CoreWeave says teams doing RL at scale, building agentic workflows and evaluating continuously currently have three imperfect options: build their own sandbox infrastructure, buy capacity from a separate vendor, or restrict what their agents may try. The company argues each compounds operational debt as research grows, through engineering time spent on plumbing, underused compute and governance gaps.

How the two deployment modes work

On CKS, each sandbox runs inside its own Kubernetes pod, governed by a profile that defines network policies, resource limits and namespace boundaries. Administrators set the boundaries once, and every sandbox produced by a profile inherits them. Profiles also define the compute footprint a sandbox can use, including instance type, CPU and memory, and storage. Memory spikes, infinite loops and out-of-memory errors stay confined to the pod that produced them, according to CoreWeave.

The serverless runtime is aimed at researchers without a CKS cluster or those wanting to extend existing compute. CoreWeave manages the cluster and runs every CPU sandbox inside a Kata Container by default. Each sandbox gets its own hardware-virtualized kernel, filesystem and network. The company calls it one of the strongest isolation models available for these workloads.

Both paths use the same Python client and the same CoreWeave-managed control plane. For platform teams on CoreWeave, sandboxes are enabled in an existing CKS cluster with one CLI command. CoreWeave runs the control plane for authentication and request routing and deploys a Runner inside the cluster that schedules and manages each sandbox. Researchers install the client with pip install cwsandbox. Serverless users install pip install wandb[sandbox] and authenticate with an existing Weights & Biases (W&B) API key.

Debugging and capacity

CoreWeave points to a common problem when agent rollouts fail at scale: lifecycle events, training metrics and LLM traces sit in separate systems. Its answer is to make each sandbox part of the training run. Sandbox lifecycle events appear in the same W&B run timeline as metrics, and W&B Weave traces link each model call, tool call and return value to the sandbox that produced it. The agent's code, inputs and outputs are captured per sandbox and can be queried later.

On capacity, CoreWeave says sandboxes on CKS schedule across the clusters a customer already operates, including idle CPUs on GPU nodes when run alongside SUNK. This avoids the inter-cluster latency, second billing model and extra capacity ceiling that come with a separate sandbox vendor, the company argues.

For serverless use, sandboxes are pre-authenticated to the user's W&B identity, and secrets are injected from the W&B Team secrets store. Usage is tracked per organization and included in the W&B plan, so no separate billing relationship is needed, according to CoreWeave.

Early user feedback and what it means

The announcement includes comments from two customers. Brian Belgodere of IBM Research said the product fills "a real gap in our AI research stack" and that their RL workflows spin up thousands of sandboxes in parallel per training step. Roman Soletskyi of Mistral said his team now runs hundreds of concurrent sandboxes on CPU nodes and alongside Slurm training jobs on GPU nodes through a single setup.

For AI teams, the pitch is a single execution layer that keeps risky agent code isolated while tying results back to experiment tracking. Existing CoreWeave customers can enable sandboxes in the Cloud Console, and teams wanting self-service access can start through Weights & Biases. The source gives no pricing beyond noting that serverless usage is included in the W&B plan.