Skip to main content

Module health

Module health 

Source
Expand description

GET /health as a capability handshake rather than a boolean.

Three states, not two. detecting exists because a UI that renders its guess while backends are still being probed paints a greyed-out GPU control that is pixel-identical to a measured “unsupported” – and the user reads the guess as a verdict. With a third state the client can hold: show a spinner, not a conclusion.

Every capability carries both a stable machine reason and a human detail sentence. The client greys the control and puts detail in the tooltip; it never re-derives the explanation from the flag, because the server is the only side that knows whether Metal is missing (no device) or merely not compiled in (--features metal), and those two produce completely different advice.

Modules§

capability
Well-known capability ids, so a client can look one up rather than pattern-matching on position in the list.
reason
Stable machine-readable reason codes. Clients may switch on these; the human detail string beside them is free-form and may be reworded at any time.

Structs§

Capability
HealthResponse
ModelSummary
Summary of what is loaded, so the client does not need a second round-trip to /v1/models just to label the connection.

Enums§

HealthState