Repository navigation
[Bug] Windows Settings → Compute still "mesh-llm feature not enabled" on 0.5.25 (#2836 closed in error; #3223 never merged) #7893
Description
Activity
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.
Describe the bug
On stock Windows, Settings → Compute still fails with:
#2836 described this exactly and was closed as completed. That close is wrong for official Windows builds:
ArneBroedelcannot reopen [Bug] Windows Settings → Compute: "mesh-llm feature not enabled" (mesh omitted from Windows builds) #2836 (ReopenIssuepermission denied). Evidence is also on #2836 (comment).Linux got
--features mesh-llm(#3788 / #4524). Windows did not.This is not #7731. That issue is the next wall for custom
--features mesh-llmWindows builds (v0.75.1LoadLibraryExWmixed-separator path). Stockrelease-windowsnever reaches that code: it still compilesmesh_llm_stubs.To Reproduce
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.
Supporting Material
Installed
C:\Users\arneb\AppData\Local\Buzz\buzz-desktop.exe:mesh-llm feature not enabled,mesh_llm_stubs,Buzz shared compute is not available in this buildmesh-llm-sdk,mesh_llm_host%LOCALAPPDATA%\mesh-llmcache (stub never downloads a runtime)CI on current
main(checked 2026-09-25):.github/workflows/windows-canary.yml:No mesh-llm: release-windows doesn't build it..github/workflows/release.ymlrelease-windows:pnpm tauri build ... --bundles nsiswithout--features mesh-llm--features mesh-llmEnvironment
sm_89), driver 610.47, CUDA UMD 13.3Additional context
A follow-up Windows enablement PR should not treat “flag on” as “Share works”:
OS error 126);mainpin notes v0.76.x as the fix.cudart64_12/cublas64_12/cublasLt64_12even on Ada (sm_89) when the driver is CUDA 13.x.Please also link this from #2836 / #2388.