You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] Windows Settings → Compute still "mesh-llm feature not enabled" on 0.5.25 (#2836 closed in error; #3223 never merged) #7893
Linux got --features mesh-llm (#3788 / #4524). Windows did not.
This is not#7731. That issue is the next wall for custom--features mesh-llm Windows builds (v0.75.1 LoadLibraryExW mixed-separator path). Stock release-windows never reaches that code: it still compiles mesh_llm_stubs.
To Reproduce
Install official Buzz Desktop Windows (tested: 0.5.25 x64 NSIS / updater).
Open Settings → Compute.
See mesh-llm feature not enabled.
Expected
Windows release and canary ship --features mesh-llm (and whatever Windows native-runtime bundling is required), matching macOS arm and Linux. A Windows GPU host can share compute with other members on the same relay.
Failing that, Compute should be hidden/disabled on stub builds rather than rendering the stub error. #2836 should not stay closed as completed.
Checked the desktop-v0.5.28 release source at f87c10895ea35a9a2cea629fef1d7532a3fecbc5: the official Windows release command still omits --features mesh-llm, and windows-canary.yml explicitly says it follows that non-Mesh build. Apple Silicon macOS and Linux enable the feature; Intel macOS does not, so the parity target should be those Mesh-capable distributions rather than all macOS builds.
This leaves the distribution gap unresolved. Our custom 0.5.27 Windows build reached Compute's device survey and model catalogue; the 0.5.28 custom update is not yet runtime-validated. Neither establishes inference or sharing. I have not tested the stock 0.5.28 installer or claimed a complete Windows Mesh canary here.
Would maintainers accept a narrowly scoped follow-up focused on official Windows packaging and its acceptance lane? #3223 by @stevepresley contained useful Windows work but also unrelated changes and was closed unmerged; it should be credited as prior investigation, not treated as a shipped fix.
Useful acceptance criteria: install the release artifact on a clean Windows host; confirm Compute uses the real backend; verify native-runtime loading on the supported GPU/backend matrix; run one local inference and one authorized relay-shared request; verify restart/disable cleanup. Enabling the Cargo flag is only the first step. Runtime prerequisites and unsupported hardware should be explicit, rather than requiring a private custom build to discover them.
Activity
TheAngryPit commentedon Oct 10, 2026
Checked the
desktop-v0.5.28release source atf87c10895ea35a9a2cea629fef1d7532a3fecbc5: the official Windows release command still omits--features mesh-llm, andwindows-canary.ymlexplicitly says it follows that non-Mesh build. Apple Silicon macOS and Linux enable the feature; Intel macOS does not, so the parity target should be those Mesh-capable distributions rather than all macOS builds.This leaves the distribution gap unresolved. Our custom 0.5.27 Windows build reached Compute's device survey and model catalogue; the 0.5.28 custom update is not yet runtime-validated. Neither establishes inference or sharing. I have not tested the stock 0.5.28 installer or claimed a complete Windows Mesh canary here.
Would maintainers accept a narrowly scoped follow-up focused on official Windows packaging and its acceptance lane? #3223 by @stevepresley contained useful Windows work but also unrelated changes and was closed unmerged; it should be credited as prior investigation, not treated as a shipped fix.
Useful acceptance criteria: install the release artifact on a clean Windows host; confirm Compute uses the real backend; verify native-runtime loading on the supported GPU/backend matrix; run one local inference and one authorized relay-shared request; verify restart/disable cleanup. Enabling the Cargo flag is only the first step. Runtime prerequisites and unsupported hardware should be explicit, rather than requiring a private custom build to discover them.