Agent Sandboxes — Sizing & Capacity Planning

3 min read

Target Audience

Infrastructure Admins and IT Operators planning capacity for the Unique AI Conduct execution environment.

Sizing at a Glance

What	Value
One sandbox pod	0.5 vCPU request → 2 vCPU limit, 4 GiB memory (fixed), +2 GiB ephemeral `/tmp`
Baseline services (always on)	~1.3 vCPU / ~2.4 GiB requested (4 vCPU / 3.75 GiB at limits)
Total sandbox pods needed	concurrent users + warm pool
Recommended warm pool	½ of expected concurrent users, ceiled
Packing reference	~6 sandbox pods per 8 vCPU / 32 GiB node
Shared storage	100 GiB ReadWriteMany PVC (checkpoint store)

What Consumes Capacity

Two independent groups, sized separately:

1. Baseline services — always running, even with zero users. Small pods on general-purpose nodes.

Component	Replicas	Requests (per pod)	Limits (per pod)
`sbx-gateway` (egress proxy)	2	250m / 512 Mi	1 vCPU / 1 Gi
`sbx-storage` (checkpoint store)	2	100m / 128 Mi	500m / 256 Mi
`agent-sandbox-controller`	1	100m / 128 Mi	500m / 256 Mi
Sandbox router	2	250m / 512 Mi	250m / 512 Mi
Total		~1.3 vCPU / ~2.4 GiB	~4 vCPU / ~3.75 GiB

2. Sandbox pods — one long-lived pod per active user, on the dedicated Kata node pool. Each pod: 0.5 vCPU request → 2 vCPU limit, 4 GiB memory. Memory is the binding resource — plan for 4 GiB per pod; CPU bursts to the limit only during active turns.

Suggested Sizing

sandbox pods = expected concurrent users + warm pool
warm pool    = ceil(concurrent users / 2)

Concurrent users = users actively running agent turns at the same time, not total licensed users. Sandboxes self-terminate after 10 minutes idle (SANDBOX_IDLE_TTL_SECONDS), so this number is far below active daily users.
Warm pool = pre-created idle pods so a new user gets a sandbox instantly instead of waiting for pod creation. The ½-of-users ratio is a starting recommendation — raise it if new-user bursts are common, lower it to save cost. Warm pods consume full resources (they are identical sandbox pods) and run 24/7.

Reference Scenarios

Scenario	Concurrent users	Warm pool	Sandbox pods total	CPU cores (req → limit)	Memory GiB (req → limit)	Kata nodes — with autoscaling	Kata nodes — static 24/7
Baseline only	0	0	0	1.3 → 4	2.4 → 3.75	0 †	0 †
Small	4	2	6	4.3 → 16	26.4 → 27.75	1 always-on	1 always-on
Medium	8	4	12	7.3 → 28	50.4 → 51.75	1 always-on + up to 1 (business hrs)	2 always-on
Large	40	20	60	31.3 → 124	242.4 → 243.75	4 always-on + up to 6 (business hrs)	10 always-on

CPU/memory totals include baseline services. With autoscaling, only the warm-pool nodes run continuously; additional nodes for active users spin up on demand (and can scale to zero off-hours). Static 24/7 (typical on-prem, no autoscaler) provisions the full peak permanently.

† Baseline services (sbx-gateway, sbx-storage, controller, router) are small and run on your existing general-purpose node pools — a fraction of one node — not on the dedicated Kata pool.

Estimating cost

Sandbox pods run on a dedicated Kata-enabled node pool. Multiply the node counts above by your node price. As a reference point, a general-purpose Standard_D8s_v5 (8 vCPU / 32 GiB) fits ~6 sandbox pods and lists at roughly $0.50/hour Azure PAYG (~$370/month if run continuously); business-hours-only nodes run ~170 hours/month. Your actual rate depends on region, VM family, and any committed-use or Enterprise Agreement discounts.

Node Pool Requirements

Requirement	Detail
Dedicated Kata pool	Sandbox pods require nodes with Kata Containers (`workload-runtime=kata` taint). Nothing else schedules there — count this pool's full capacity toward Conduct.
Nested virtualization	Kata nodes need nested-virtualization-capable VMs (cloud) or bare-metal/VT-x hosts (on-prem).
Per-node overhead	Each Kata pod is a microVM with its own guest kernel — budget ~10% node capacity for VM overhead and daemonsets. ~6 sandbox pods fit an 8 vCPU / 32 GiB node.
General-purpose nodes	Baseline services run on your standard node pools; no special runtime needed.

Storage

Item	Size	Notes
Checkpoint store PVC	100 GiB, ReadWriteMany	Workspace checkpoints, capped at 100 MB compressed per chat
Sandbox `/tmp`	2 GiB per pod	Ephemeral (emptyDir), released with the pod

What This Does Not Cover

LLM token consumption (billed separately via your model provider)
Log/metric ingestion and network egress
The assistants-core orchestrator — sized as part of the core platform, not the sandbox service