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
detailstring beside them is free-form and may be reworded at any time.
Structs§
- Capability
- Health
Response - Model
Summary - Summary of what is loaded, so the client does not need a second
round-trip to
/v1/modelsjust to label the connection.