omlx is servable and daemon-supervisable, but the fleet cannot wake it. The Spinloop-to-deploy-config path accepts only llamacpp and vllm as runners, so a PROVIDER omlx Spinloop that names a FLEET fails at wake with "this Spinloop cannot be turned into something to start". The omlx case in parallelPresetKey is unreachable as a result.
Waking an omlx node would differ from waking llamacpp or vllm in one way that matters: there is no model at start. oMLX loads a directory of models and selects per request, so a woken node's deploy config carries no model, the Spinloop's MODEL and ALIAS keep their usual meaning (the id the harness requests), and PARALLEL renders as --max-concurrent-requests. Readiness has no oMLX health-check convention, so a woken node reports no readiness and routing waits on the engine endpoint answering, as it does today.
The mtplx work (#148) reworks the Spinloop-to-deploy-config path to be runner-aware, which should make this a small follow-up.
Spec: fleet-routing, "Waking a node".
omlxis servable and daemon-supervisable, but the fleet cannot wake it. The Spinloop-to-deploy-config path accepts onlyllamacppandvllmas runners, so aPROVIDER omlxSpinloop that names aFLEETfails at wake with "this Spinloop cannot be turned into something to start". Theomlxcase inparallelPresetKeyis unreachable as a result.Waking an omlx node would differ from waking llamacpp or vllm in one way that matters: there is no model at start. oMLX loads a directory of models and selects per request, so a woken node's deploy config carries no model, the Spinloop's
MODELandALIASkeep their usual meaning (the id the harness requests), andPARALLELrenders as--max-concurrent-requests. Readiness has no oMLX health-check convention, so a woken node reports no readiness and routing waits on the engine endpoint answering, as it does today.The mtplx work (#148) reworks the Spinloop-to-deploy-config path to be runner-aware, which should make this a small follow-up.
Spec: fleet-routing, "Waking a node".