Skip to main content
CoreWeave sandboxes run agent workloads at scale in isolated, policy-controlled environments. Reinforcement learning rollouts, agent harnesses, and evaluation benchmarks all need somewhere to run model-generated commands, edit files, and execute tool calls. Sandboxes are a managed execution layer for that work, hosted on CoreWeave Kubernetes Service (CKS) capacity and reachable through a Python client. These pages cover sandboxes on CKS capacity you own, where your administrators author the policy. CoreWeave also runs sandboxes on its own capacity, where CoreWeave owns the policy and there is no infrastructure administrator. That offering is documented separately.
CoreWeave sandboxes are in public preview. For access, contact your CoreWeave account team, CoreWeave Support, or email support@coreweave.com.

​
The problem sandboxes solve

Modern model development generates a constant stream of model-authored actions that need to run somewhere isolated. Reinforcement learning runs produce hundreds of thousands of code samples per training run for reward verification. Agent harnesses execute tool calls, edit files, and run shell commands on the model’s behalf. Evaluation benchmarks spin up hundreds of container executions per task to score model quality. Each of those executions needs isolation. Without it, a malformed action or malicious prompt can compromise the host environment. Building and operating that isolation layer is significant work. Most teams pay for it twice: once in the dedicated sandbox cluster they stand up, and again in the idle capacity on their training cluster that the sandbox cluster doesn’t use. CoreWeave sandboxes provide the isolation layer as a managed service. Administrators define guardrails once in a policy (network access, resource limits, security posture), and a CoreWeave-managed control plane schedules sandbox pods onto CKS capacity whose policy accepts the request. Researchers reach the platform through a Python client. You don’t stand up a separate sandbox cluster, and you don’t build or run the isolation tooling.

​
Sandbox capabilities

The following sections describe what CoreWeave sandboxes provide.

​
Scheduling on CKS capacity

Sandboxes run as pods on CKS clusters. The control plane places each sandbox on a cluster whose policy permits what the sandbox asked for, so a single request can reach capacity across multiple clusters in your organization. If a cluster also runs training with the SUNK Pod Scheduler, sandbox pods schedule alongside Slurm jobs on shared GPU nodes. The idle CPU your training jobs leave behind fills with sandbox work.

​
Isolation without the build

Each sandbox runs inside its own hardware-virtualized guest using Kata Containers, so the isolation boundary is a virtual machine rather than a shared kernel. That boundary is what makes it safe to run model-authored code, and it is why in-guest privilege can be exposed to users at all. Administrators can permit other runtime classes on their own clusters, and the policy’s runtime-class allow-list fails closed, so a sandbox can only select a class an administrator named. Egress rules restrict network access, and resource and security constraints bound what a researcher can request. Administrators define these guardrails once in a policy, and every sandbox on that cluster is governed by them.

​
From pip install to running sandboxes

CoreWeave operates the control plane outside your environment. Inside your cluster, a CoreWeave-managed runner schedules the pods. You don’t deploy or operate either component. Researchers install the Python client (uv pip install cwsandbox) and run sandboxes against the platform without infrastructure setup.

​
Architecture

The sandbox architecture has three components, all managed by CoreWeave:
  • Control plane: where administrators create and manage runners and the policy each one carries, accessed through the CoreWeave Intelligent CLI or directly through a REST API.
  • Data plane: a global endpoint for sandbox operations. The Python client connects to the data plane to start sandboxes, run commands, and stream output.
  • Runner: a Kubernetes workload deployed inside one of your CKS clusters. The runner receives placement decisions from the data plane and creates sandbox pods on the cluster.
You enable a runner on a CKS cluster with the CoreWeave Intelligent CLI. After that, the runner stays in sync automatically. You don’t deploy or upgrade it. A policy describes what sandboxes on a cluster may request: network access, resource limits, security posture, and lifetime. Each runner carries exactly one policy, and a cluster hosts at most one runner, so one policy governs one cluster. Researchers don’t choose a policy. They describe the sandbox they want, and the policy either permits it or rejects it with the reason.

​
Integrations

The following third-party frameworks support CoreWeave Sandbox as a sandbox provider:

​
Next steps

Get started

End-to-end walkthrough from enabling a runner and setting its policy to running your first sandbox.

Python client

Install the software development kit (SDK) and explore the lifecycle, file, and execution APIs.

SUNK integration

Schedule sandboxes alongside Slurm jobs on CoreWeave SUNK.

Discover infrastructure

List available runners and capacity from the SDK before you create sandboxes.
Last modified on August 14, 2026