cwsandbox Python SDK to launch and manage sandboxes.
Overview
You can set sandbox configuration in three places, listed from broadest to most specific scope:- SandboxDefaults: Shared defaults for all sandboxes in a session.
- Sandbox.run() kwargs: Per-sandbox overrides.
- @session.function() kwargs: Function-specific configuration.
Resources
Configure CPU, memory, and GPU resources using theResourceOptions dataclass or a plain dict:
ResourceOptions internally.
ResourceOptions separates resource requests from limits. Requests tell the scheduler what the sandbox needs. Limits set the maximum it can use. For background on how Kubernetes uses requests and limits to assign Quality of Service classes, see the Kubernetes documentation.
ResourceOptions fields
All fields are optional and default to
None, which uses backend defaults.
Guaranteed QoS
When requests equal limits, the sandbox receives a Guaranteed Quality of Service class. This reserves exact resources and prevents throttling. Use this for latency-sensitive workloads.Burstable QoS
When requests are lower than limits, the sandbox receives a Burstable Quality of Service class. Lower requests let the scheduler bin-pack more sandboxes, but each sandbox can burst up to its limit if capacity is available.CPU values
Specify CPU in millicores or whole cores. For details, see Resource units in Kubernetes.Memory values
Memory uses standard Kubernetes memory units:GPU
Request GPU resources alongside CPU and memory.Inspect confirmed resources
After a sandbox starts, inspect the confirmed resource allocation:Configuration library interop
All configuration types (NetworkOptions, Secret, ResourceOptions) accept either the dataclass or a plain dict. This means ML configuration libraries that resolve configs to dicts or dict-like objects can pass values directly to the SDK without manual conversion.
SandboxDefaults.from_dict() accepts a plain dict or an OmegaConf DictConfig and coerces nested fields automatically. Dicts become NetworkOptions, Secret, or ResourceOptions as needed, and lists become tuples.
Sandbox.run() or session.sandbox(). The nested dict form for resources maps to ResourceOptions fields. The flat dict form ({"cpu": "1", "memory": "1Gi"}) is also accepted and treated as Guaranteed QoS.
Mounted files
Mounted files let you provide configuration files, scripts, or other read-only assets to the sandbox at startup, without baking them into a container image.Mount options
Mounted files are read-only. Use
write_file() for files that require modification.
Ports
Expose ports so processes inside the sandbox can serve traffic to outside clients:Port configuration
Network
Configure network options using theNetworkOptions dataclass or a plain dict:
NetworkOptions internally.
NetworkOptions fields
All fields are optional and default to
None, which uses backend defaults.
Set network in SandboxDefaults
Set a default network configuration for all sandboxes:Annotations
Add Kubernetes pod annotations to sandboxes. Annotations are key-value string pairs attached to the underlying pod, useful for integrations that read pod metadata, such as schedulers, cost-allocation tools, or external automation.Session-level defaults
Set default annotations for all sandboxes in a session:Merge behavior
When you provide bothSandboxDefaults.annotations and per-sandbox annotations, the SDK merges them. Explicit per-sandbox values win on key collision, matching the same semantics as environment_variables.
SUNK integration
To pass Slurm context as pod annotations for SUNK integration, see the SUNK Pod Scheduler integration guide.Validation
The SDK does not validate annotation keys or values. The server handles validation of reserved key prefixes, value format, and maximum entry count.Secrets
Use secrets to provide credentials such as API tokens or database passwords to a sandbox without exposing the values in your client-side code. Inject secrets from secret stores as environment variables using theSecret type:
environment_variables, secrets are never passed in plaintext. The server resolves them from the named store and injects them securely.
Administrators configure secret stores at the organization level. Stores connect to external providers (for example, W&B Secret Manager) and resolve server-side at sandbox creation. Stores are independent of client-side authentication.
Secret fields
Common patterns
Set secrets in SandboxDefaults
Share secrets across all sandboxes in a session:secrets) target the same resolved env_var with different store, name, or field, the SDK raises a ValueError whose message starts with Conflicting secrets for env_var. This check runs locally while the SDK constructs the Sandbox object, before the SDK sends any request to start the sandbox. The SDK ignores exact duplicates when the resolved env_var, store, name, and field all match.
Timeouts
Two distinct timeout settings control sandbox behavior: a per-command client-side timeout and a server-side maximum sandbox lifetime.timeout_seconds
Per-command timeout:SandboxTimeoutError.