Example Estimates
Agents are autonomous - tasks are triggered from many sources, not only a user chatting. In xpander cloud production over the last 30 days, ~47% of executions were scheduled tasks, 23% webhooks, 19% SDK, 6% API, and only ~5% interactive chat. Size for the number of tasks running concurrently at peak, whatever triggers them.
Capacity figures include ~50% headroom over pod resource requests for burst load, Kubernetes system pods, and node upgrades. Use the calculator below to size for your exact numbers.
Sizing Calculator
Estimate cluster resources from your expected usage. The formula behind it is described in How the estimate works.How the estimate works
The calculator applies the same model we use to size xpander cloud:- Concurrent tasks is the primary driver. A task is any agent execution, from any source: chat, API/SDK calls, schedules, webhooks, MCP clients, Slack, or another agent. If you don’t know your peak concurrency yet, assume one concurrent task per agent - that covers most production organizations we measured. In practice most teams peak at just a few concurrent tasks (typically under 5), and even the busiest organization peaks around 30.
- Agent Workers = concurrent tasks ÷ 4 (each worker replica processes 4 tasks by default, configurable with
MAX_CONCURRENT_EXECUTIONS). Each replica requests 2 vCPU / 2.5 GiB. - Agent Controllers: 1 replica up to ~8 concurrent tasks, 2 up to ~20, 3 beyond. Each requests 1 vCPU / 2 GiB.
- Active workspaces = concurrent tasks × workspace share, capped at the agent count. Budget ~0.5 vCPU / 1 GiB per active workspace (measured typical load; each can burst to its 2 vCPU / 3 GiB limit).
- Fixed base (~2 vCPU / 6 GiB): AI Gateway, MCP, Chat, Code Runner, AWS Operator, API, Redis, PostgreSQL, container registry, metrics-server at one replica each.
- Cluster capacity = requests × 1.5 for burst, DaemonSets, and safe node drains. Storage = 48 GiB of chart volumes + 5 GiB per agent (each agent that uses a workspace keeps a persistent volume) + image cache per node.
Platform Services
Per-replica values. Defaults are what the Helm chart applies out of the box; recommended raises the values we found low against measured production usage.
Override any of these in your Helm values (keys are camelCase):
Agent Workspaces
Each agent that uses workspace tools gets a dedicated pod, created on demand and reclaimed when idle. Size the cluster for the number of concurrently active workspaces, not total agents.
Idle workspaces consume almost nothing (~50 Mi observed); an active workspace typically uses ~0.5-1 vCPU and up to 1 GiB, bursting to its limits for heavy work. The workspace volume persists after the pod is reclaimed, so a returning agent keeps its files - plan 5 GiB of storage per workspace-using agent, not per pod.
The workspace image is ~1 GiB. The first workspace start on each node pulls it; subsequent starts on that node are fast. Budget ~2 GiB of node disk for image cache.
Data Services & Storage
The chart deploys single-replica Redis and PostgreSQL StatefulSets and a container registry alongside the platform:
Baseline storage: 48 GiB of persistent volumes, plus 5 GiB per workspace-using agent (see above). All volumes use your cluster’s default StorageClass unless overridden.
Production Checklist
- Node types: x86_64 only. General-purpose instances with a 1:4 vCPU:GiB ratio (
m5,m6i) fit the workload profile;t3burstable instances are fine for evaluation, not for production. - Raise the low defaults: Agent Controller and API memory (table above) before real load.
- Enable autoscaling for Agent Worker once concurrency grows beyond a couple of replicas.
- Keep headroom: pod requests should stay under ~65% of cluster capacity so node upgrades and bursts don’t evict workloads.
- Storage class: SSD-backed volumes for Redis and PostgreSQL.