Repository navigation
Add CPU/memory resource limit flags to openshell sandbox create #1003
Description
Problem Statement
openshell sandbox create has no way to set CPU or memory limits on the sandbox pod. The proto layer already defines DriverResourceRequirements with cpu_request, cpu_limit, memory_request, memory_limit fields, and the K8s driver reads them — but the CLI has no flags to populate them.
Behavior
All four flags are optional. When omitted, the pod gets default K8s resource allocations (current behavior).
--cpu-request / --memory-request map to K8s resources.requests (scheduling hints).
--cpu-limit / --memory-limit map to K8s resources.limits (enforced by kubelet via cgroups).
Proposed Design
Add four new optional CLI flags to openshell sandbox create:
RESOURCE FLAGS:
--cpu-request Minimum CPU cores (e.g. "500m", "2")
--cpu-limit Maximum CPU cores (e.g. "500m", "4")
--memory-request Minimum memory (e.g. "256Mi", "4Gi")
--memory-limit Maximum memory (e.g. "512Mi", "8Gi")
Alternatives Considered
- Add a single --resources JSON flag. However, individual flags are self-documenting and follow the pattern established by flag --gpu 0|1.
Agent Investigation
No response
Checklist
- I've reviewed existing issues and the architecture docs
- This is a design proposal, not a "please build this" request
Activity
feat(cli): add CPU/memory resource limit flags to sandbox create
elezar commentedon Jun 4, 2026
Closing this as superseded by #1376.
The original proposal asked for separate request and limit flags:
We have since added the driver-agnostic sandbox resource flags:
Those map to portable CPU and memory limits across the supported drivers. We intentionally kept this public CLI shape smaller and driver-agnostic rather than exposing Kubernetes-specific request/limit semantics directly in the common sandbox-create surface.
For driver-specific resource configuration, including Kubernetes-specific request/limit shapes, we are tracking the broader driver-owned config mechanism in #1492 / #1589. That path may be the better place to express backend-specific resource details that do not belong in the portable CLI surface.