Arch/CPUs/Memory are the connecting host's static CPU spec, mirrored from the registration: Arch is runtime.GOARCH (amd64 | arm64), Memory is total RAM in BYTES — the same fields a code-linked run-target carries, so the /v1/visor/fleet board renders a linked node's arch + cores + RAM like any other unit.
Capabilities is what this worker offers the org: "studio.render" when the node can render, "engine.serve" when it serves a model endpoint. A node advertises one only once it can honour it, so an absent list means a node that has dialed in but is not ready to serve any of them yet.
Engine is the hanzo-engine model server this node runs, when it runs one (hanzo link --serve-engine). Absent means the node takes jobs but serves no model endpoint.
ID is the node's id in the fleet — the sanitized hostname it registered under, which is also the unit its samples and its gpu-jobs lane key on. This is the id to use everywhere else on the compute surface.
JobQueue is the tasks NAMESPACE this worker claims render jobs out of — "gpu-jobs" unless hanzo link was pointed at another. Within it, a job aimed at this node alone rides the task-queue value "gpu:
Provider is always "byo": this machine is the operator's, not one Hanzo provisioned. It exists so a fold into the machines/GPUs pages says which rows are rented and which are the customer's own.
Status is "online" when the last heartbeat landed within 90s, else "offline" — so it is a fact about heartbeat freshness, not about the box being powered on. A worker that has never beaten reads offline.