Resource Pools

Your credit subscription funds the wallet and sets two resource pools shared across all your workspaces. A single workspace can have at most 12 vCPUs, including on Enterprise. Higher plans let you distribute more capacity across multiple workspaces; a larger pool does not raise that single-workspace ceiling.

These are account-level allocation policies. A PAYG or monthly capacity contract separately defines the purchased shared pool and payment terms for personal workspaces or an optional namespace. A monthly pool prepays its CPU, RAM and included disk for the paid period; the account tier, paid running pool and platform per-workspace ceiling all apply to new purchases. A namespace's declared policy can restrict its pool further. Account-tier rules still govern namespace count and reseller eligibility. Resource-limit edits alone do not purchase a pool.

A capacity subscription belongs to the pool, not to a VM ID. Split it across one or many workspaces and replace them within the same paid period. New contracts use allocationBasis: "running": confirmed stops release running CPU/RAM, while retained disks and owned workspace slots still count. Paused VMs and pending starts retain running reservations. Removal releases owned capacity only after confirmation. Older paid contracts return allocationBasis: "allocated" and preserve their original rules. Both PAYG and monthly use these allocation checks. A wallet deposit funds PAYG usage without increasing CPU, RAM, disk or workspace limits.

Two pools

Owned pool

The owned pool limits the total resources across all your workspaces (running or stopped). This is your overall capacity ceiling.

Running pool

The running pool limits resources consumed by currently running workspaces. This is your active capacity ceiling.

Confirmed stopped workspaces count toward the owned pool but release running CPU/RAM. Disk remains charged to retained storage; an unknown stop outcome does not release resources. This means you can have more total workspaces than can run simultaneously.

How it works

When you create a workspace:

Resources are checked against the owned pool
If pool is full → POOL_LIMIT_REACHED error

When you start a workspace:

Resources are checked against the running pool
If pool is full → RUNNING_POOL_REACHED error
Stop another workspace to free running pool capacity

When you stop a workspace:

Running pool resources are freed
Owned pool resources are still consumed (workspace still exists)

When you delete a workspace:

Confirmed removal frees its CPU/RAM and workspace slot
A retained disk still uses storage until separately deleted

Account pool limits

Read GET /credits/plans for current account-tier limits and workspaces.getQuota() for the authenticated owner's effective limits and usage. These values come from the backend. The account tier grants credit funding and capacity limits. A monthly pool spends those credits to cover shared resources for a month; presets are sizing examples, not replacement tiers. Read the authenticated capacity response and effective namespace limits before provisioning.

Disk allowances are the same in both pools because stopped workspaces retain their storage. There is no smaller disk budget when starting them. CPU and memory still have separate running limits.

Account policy values are allocation ceilings. A confirmed monthly capacity quote separately reserves a paid pool on a compatible host. The immutable image is shared; each workspace has a separate sparse writable disk. Hosts need sufficient physical space as those writable disks grow.

CPU quota

All tiers currently allow 100% CPU quota per assigned vCPU. Plan CPU counts, running-pool limits and host contention still determine available throughput.

Per-workspace limits

Each workspace must fit its effective per-workspace limit as well as the owned, running and namespace pools. Read the backend's quota/plan response and the namespace's effective_resource_limits for current CPU, RAM and disk ceilings. A workspace remains subject to the platform maximum of 12 vCPUs, including on Enterprise.

The API uses MiB for memory_mb and disk_size_mb: 1 GiB is 1024 MiB and 1 TiB is 1048576 MiB. An image can require a higher minimum; use the image catalog's requirements and effective account/namespace limits before provisioning. See Mac workspaces for that image's storage and memory requirements.

Hard maximum is the platform ceiling per workspace, including Enterprise. Aggregate quotas and host capacity still apply.

For example, a 64-vCPU running pool can accommodate five 12-vCPU workspaces and one 4-vCPU workspace if memory, disk, workspace count and host capacity also fit. Each workspace must remain within the 12-vCPU ceiling. Compute charges follow the saved billing mode: measured PAYG usage or paid monthly coverage.

The ceiling applies to creation, resize, restart, resume and snapshot restore. A running workspace created under an older, larger ceiling is not stopped automatically. Reduce its CPU allocation to 12 or less before its next launch or resource change.

Checking your quota

const quota = await ws.getQuota();

console.log(`Plan: ${quota.planLabel}`);
console.log(`Workspaces: ${quota.currentSandboxes}/${quota.maxSandboxes}`);
console.log(`Can create: ${quota.canCreate}`);
console.log(`Pool used: ${quota.pool_usage.cpus}/${quota.pool.cpus} CPUs`);
console.log(`Running used: ${quota.running_pool_usage.cpus}/${quota.running_pool.cpus} CPUs`);

Common scenarios

"Pool limit reached" on create

Your total workspace resources exceed the owned pool. Options:

Delete unused workspaces
Reduce resources on existing workspaces
Upgrade your plan - see the Pricing page

"Running pool reached" on start

Too many workspaces running simultaneously. Options:

Stop a running workspace
Reduce resources on running workspaces
Upgrade your plan - see the Pricing page

Maximize workspace count

Use smaller resource allocations:

// Minimal workspace - fits many in a pool
await ws.create({
  image: 'oblien/alpine:3.24',
  config: { cpus: 1, memory_mb: 128, disk_size_mb: 64 },
});

On this page