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.Documentation Index
Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
Use this file to discover all available pages before exploring further.
CoreWeave sandboxes are currently in limited availability. Contact CoreWeave Support or email [email protected] for access.
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, and 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 is not using. CoreWeave sandboxes provide the isolation layer as a managed service. Administrators define guardrails once in a profile (namespace strategy, network policy, resource limits), and a CoreWeave-managed control plane schedules sandbox pods onto CKS capacity that fits the profile. 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 that satisfies the profile’s policies, so a single profile can target 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, so the idle CPU your training jobs leave behind fills with sandbox work.Isolation without the build
Each sandbox runs as a container in its own pod. Egress and ingress policies restrict network access. Namespace strategies enforce tenant boundaries. Resource policies bound what a researcher can request and where workloads can run. Administrators define these guardrails once in a profile, and every sandbox the profile produces inherits 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 profiles, 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.
Next steps
Get started
End-to-end walkthrough from creating a profile and enabling a runner to running your first sandbox.
Python client
Install the SDK and explore the lifecycle, file, and execution APIs.
SUNK integration
Schedule sandboxes alongside Slurm jobs on CoreWeave SUNK.
Discover infrastructure
List runners and profiles from the SDK before you create sandboxes.