Why another patch today
Within hours of 2.8.1, two independent reports described the same thing: load a model, and with no requests at all the machine heats up while API requests never arrive. The cause was not the engine at idle, it was the start wizard silently re-running the multi-minute tuning benchmark on every launch, with the API port still closed while it ran. The tune record's save key and lookup key had drifted apart in 2.8.0's per-model profile work, so the wizard could never find the result it had just saved.
What changed
mtplx start saves and looks up tune records through one shared key
constructor, so a saved result is found on the next launch and tuning is
offered once, not every time. A regression test fails the build if the
two sides ever drift again.
Two more wizard identity bugs fixed while root-causing: picking a non-default model tuned the machine's default instead of the picked one, and a local model folder whose name matches the verified default was silently swapped for the Hugging Face repo id, producing "Model is missing. Download?" for a model already on disk (#279).
Idle daemons also no longer hammer session-bank/manifest.sqlite:
every health/dashboard poll used to open the SSD-cache manifest and run
a full-table aggregate (#280's Activity Monitor signature). Steady-state
polling now costs at most one manifest read per five seconds.
And mtplx --version reports the right version again, the published
2.8.1 wheel identified itself as 2.8.0 (2.8.1).
Nothing on the generation path changed: decode, prefill, sampling, tool calling, and the session cache behave exactly as in 2.8.1, verified flat-or-better in interleaved A/B before ship.
Upgrading
- PyPI:
pip install -U mtplx(2.8.2) - Homebrew:
brew upgrade mtplx - Desktop app: 2.8.2 via Sparkle or the website DMG
2.8.1's release notes still describe the vision-cache fix this build carries forward.