Skip to main content
The runtime capacity endpoint reports the in-memory admission snapshot for this Crewship instance: its limits, host signal, container starts currently in flight, and starts held until capacity is available. A held start is queued before a container is created; this endpoint does not pause, evict, or change an already-running container.
This is a host-wide diagnostic, not a workspace resource. The response can include holds from other workspaces because the host admission controller is shared by the daemon.

Get capacity

Authentication: An authenticated session or CLI token is required. The route is read-only and has no workspace-role or admin gate. It does not use a request body or query parameters. Response: 200 OK, application/json
limits.MinStartInterval is a Go duration encoded as nanoseconds. held is always an array, including when it is empty. held_total is the cumulative number of holds since the daemon started, while in_flight_starts and held describe the current snapshot. The stable hold reasons are host_memory, host_pressure, concurrency, and pacing. On macOS, or where the Linux /proc signals are unavailable, host_signal_available is false; the memory and pressure checks are inactive, but concurrency and staggering can still apply. Errors: When admission control is not configured, the endpoint still returns 200: enabled is false, held is an empty array, and host_signal_error explains the state. The handler is read-only and does not return a documented application-level 4xx or 5xx for a capacity snapshot.