Hanzo
OpenapiVisor

Records a BYO worker's live GPU utilization into the SAME series the fleet…

Records a BYO worker's live GPU utilization into the SAME series the fleet board overlays.

POST /v1/visor/fleet/samples

Addresshttps://api.hanzo.ai/v1/visor/fleet/samples
MethodPOST
OperationrecordFleetSample
AuthAuthorization: Bearer $HANZO_API_KEY

Records a BYO worker's live GPU utilization into the SAME series the fleet board overlays. The org is the validated principal and source/kind are fixed server-side, so a worker names only its own metrics — never another tenant or another source. Answers 202: the warehouse write is DETACHED (its own bounded context, never in the response path), so a slow or absent warehouse cannot stall a heartbeat.

Request

7 fields, body application/json (required).

FieldInTypeRequiredDescription
gpuModelbodystringGPUModel names the representative accelerator ("GB10"); GPUs carries how many.
gpuUtilbodynumberGPUUtil is accelerator utilization as a fraction 0..1; the warehouse clamps anything outside that.
gpusbodyintegerGPUs is how many accelerators this reading covers.
hostbodystringHost is the node's hostname, for display.
memFreebodyintegerMemFree is host memory still available, in BYTES.
memUsedbodyintegerMemUsed is host memory in use, in BYTES.
unitbodystringUnit is the reporting node's own id — the same id it registered under, and the key the board joins this series onto.

Response

StatusBodyMeaning
200sampleAcceptedok

200 body — 1 field.

FieldInTypeAlwaysDescription
recordedbodybooleanRecorded is always true: the response is an acknowledgement, and the warehouse write is detached, so it reports acceptance, not durability.

Failure carries the platform error shape — see Errors.

Examples

hanzo has no subcommand for this operation — the CLI serves only what cloud's live route table confirms. Use HTTP or an SDK.


Visor API · All Hanzo APIs · Interactive reference

How is this guide?

On this page