Agent Sizing and Architecture

Size agents in self-hosted regions with explicit CPU and memory or organization agent profiles, and target amd64 or arm64 nodes per deployment.

size agents with a fixed set of agent profiles. In you own the hardware, so you can size each deployment explicitly, define your own profiles, and choose the CPU architecture agents run on.

Explicit resources

State the CPU and memory an agent gets directly on the deploy:

pipecat cloud deploy --region acme-us-east --resources cpu=1,memory=2Gi

or in pcc-deploy.toml:

region = "acme-us-east"

[resources]
cpu = "1"
memory = "2Gi"

Quantities use Kubernetes notation: CPU as whole cores or millicores (2, 500m), memory with a binary suffix (1Gi, 512Mi). Explicit resources and an agent profile are mutually exclusive — a deploy specifies one or the other, and passing one on the command line clears the other from pcc-deploy.toml. Explicit resources are accepted only for agents in .

Explicit resources are not yet available for agents deployed from a linked Git repository; use a profile for those.

Sizing is captured when a deployment is created and stays with it: running agents keep the resources they started with, and a change applies on the next deploy. pipecat cloud agent status shows the resolved CPU and memory of the current deployment.

Organization agent profiles

If you deploy many agents with the same shape, define a named profile once and select it by name, exactly like the platform profiles:

pipecat cloud agent profiles create voice-large --cpu 2 --memory 4Gi --display-name "Voice (large)"
pipecat cloud deploy --region acme-us-east --profile voice-large

Command	What it does
agent profiles list	The platform catalog plus your organization’s profiles, with CPU, memory, source, and state
agent profiles create <name> --cpu … --memory …	Define a profile; --display-name sets the label shown in pickers
agent profiles update <name> [--cpu … --memory …]	Change sizing (both together) or the display name
agent profiles disable <name> / enable <name>	Retire a profile from new deploys, reversibly

In the dashboard, profiles are managed under Settings → Agent profiles, and the agent form offers your profiles next to the platform ones for agents in a .

A profile is a template applied at deploy time, not a live setting: editing a profile changes nothing that is running, and any later deploy of a service using it — even an image-only change — picks up the new sizing. Disabling a profile stops new deploys from selecting it; existing deployments are unaffected. Profiles cannot be deleted while deployments reference them, which is why disabling is the retirement path.

Organization profiles can be used only in . The platform profiles (agent-1x and so on) still work there and resolve to their CPU and memory, but carry no billing meaning in a region you host.

Architecture

Agents run on amd64 or arm64 nodes according to the architecture their deployment declares. Two things determine what is valid:

1. What the region supports. You declare it at registration (pipecat cloud regions register … --architectures amd64,arm64 --default-architecture amd64) and can change it any time with the same command. Only declare architectures your cluster can actually schedule. pipecat cloud regions list shows every region’s supported and default architectures.

2. What the deployment declares. Set it when your image is built for one architecture, so the agent schedules on matching nodes instead of failing at startup:

   pipecat cloud deploy --region acme-us-east --architecture arm64
   

   or architecture = "arm64" in pcc-deploy.toml. Omitted, the region’s default applies.

The CLI validates the choice against the region before anything is uploaded; the API rejects a deploy whose architecture the region does not support. pipecat cloud agent status shows the deployment’s architecture, and the dashboard agent form offers a selector when the region supports more than one.

If your cluster has both architectures, prefer building multi-architecture images and leaving the deployment on the region default — you can then move workloads between node pools by changing the region’s default rather than every service.

Scaling limits

The per-organization replica limit that applies to does not apply to a : max_agents is bounded only by your cluster’s capacity. Plan agent-pool capacity from expected concurrency times the resources you assign per agent, and keep the autoscaler’s spare capacity in mind — by default a service keeps roughly two pods per active or pending session so that the next session finds a warm agent. See Configuration for the spare-capacity policy.