Capacity

Capacity shows the GPU and instance capacity your org has provisioned, with the leases and QoS that govern how it's allocated. It's the console counterpart to urun compute list, plus the operator controls.

What it shows

• Provisioned capacity — the live compute slices, per app / function / shape (e.g. b200:1, b200:4, h100:1).
• Capacity leases — reservations of capacity, so a workload can hold guaranteed GPUs.
• QoS — the quality-of-service signals that determine scheduling and admission.

How scaling works, and why leases still matter

Scaling has two levers. You set the replica floor yourself with urun app scale --replicas N; on top of that, the platform scales on queued demand — when sessions queue, it adds replicas up to the function's session-concurrency limit (urun app concurrency, default 2) and scales back down when idle. A session that arrives with every replica busy and the limit reached waits in queued. Capacity planning is still a deliberate step:

• For steady traffic, set the replica floor with scale and a concurrency limit that matches your expected parallelism.
• For a known spike (a launch, a demo), reserve a lease ahead of time so your workload holds guaranteed GPUs instead of competing for free capacity.

If a launch needs more headroom than your org currently has provisioned, work with an operator on the lease before the event.

Operator area

Capacity sits alongside the Operator surfaces (Approvals, Fleet, Metrics), which are allowlist-gated. If you don't see operator controls, your role doesn't include them — the read view of your org's provisioned capacity is still available.

When to use it

• Verify a session is queued because there's no free capacity (vs. a code failure).
• Plan a lease before a launch so you don't get scheduled behind other workloads.
• Cross-reference with Sessions when runs sit in queued / provisioning longer than expected.