Repository navigation
[Bug] Windows Settings → Compute: "mesh-llm feature not enabled" (mesh omitted from Windows builds) #2836
Description
Describe the bug
On Windows, Settings → Compute fails with:
mesh-llm feature not enabled
Share compute / Buzz Mesh cannot be used on stock Windows desktop builds. The same surface works on macOS arm builds where release CI compiles with --features mesh-llm.
This is a build/CI gap: Windows release and canary omit the mesh-llm Cargo feature, so the app ships mesh_llm_stubs that always return that error.
To Reproduce:
Steps to reproduce the behavior:
- Go to the official Buzz Desktop Windows release and install it (e.g. 0.4.24 x64 NSIS / updater build).
- Click on Settings.
- Click on Compute.
- See error:
mesh-llm feature not enabled.
Expected behavior:
A clear and concise description of what you expected to happen.
Windows builds:
- ship with
mesh-llmenabled and a working host backend (Vulkan/CUDA/etc.),
A Windows GPU host should be able to share compute with agents on other members (e.g. macOS) in the same relay community.
Supporting Material
- Error string from Settings → Compute:
mesh-llm feature not enabled - Installed Windows
buzz-desktop.execontains stub indicators:mesh-llm feature not enabled,src\mesh_llm_stubs.rs,Buzz shared compute is not available in this build - Code gate:
desktop/src-tauri/src/lib.rs—mesh_llmvsmesh_llm_stubsbehindfeature = "mesh-llm"desktop/src-tauri/src/mesh_llm_stubs.rs— all commands return"mesh-llm feature not enabled"desktop/src-tauri/Cargo.toml—mesh-llmoptional, not indefault
- CI:
.github/workflows/release.yml— macOS arm:--features mesh-llm+ Metal llama steps;release-windows: no--features mesh-llm, no mesh native backend steps.github/workflows/windows-canary.yml— explicit note that Windows does not build mesh-llm
- Related (not duplicates):
- Windows Support #2388 Windows Support umbrella (does not mention mesh/Share compute)
- fix(desktop): hide relay mesh option when mesh-llm feature is absent #1719 hide relay-mesh UI when feature absent
- ci: add Windows and Linux canary workflows with caching #2642 Windows canary
- refactor(desktop): feature-gate mesh-llm-sdk behind optional Cargo feature #823 / build: make mesh-llm opt-in for dev/staging to speed up iteration #1183 feature-gate mesh-llm
- Relay-mesh agents silently stop replying if mesh runtime drops after launch (no self-heal) #2062 / [Bug] Shared-compute agents can run green but never answer on small-context models because relay-mesh max_tokens override is clobbered #2558 are post-mesh runtime bugs (different failure mode)
- Screenshot: (attach Settings → Compute if you have one)
Environment (please complete the following information):
- OS: Windows 11
- Version: Buzz Desktop 0.4.24 (Windows x64 release/updater build)
- GPU (context): AMD Radeon RX 7600 XT 16GB
- Comparison: macOS Apple Silicon Buzz — Share compute works
Additional context
Add any other context that you feel is relevant about the problem here.
Proposed direction for a fix (not required to accept the bug):
- Enable
--features mesh-llmonrelease-windowsandwindows-canary. - Add Windows mesh native backend build/cache (Vulkan and/or CUDA; ROCm when available for the pinned mesh-llm/Skippy ABI) analogous to macOS Metal steps.
- Implement non-macOS mesh shutdown/relaunch paths currently gated
all(feature = "mesh-llm", target_os = "macos")indesktop/src-tauri/src/lib.rs. - Keep feature-off UX consistent: hide or clearly disable Compute rather than only showing the stub error.
Please also link from #2388.
Activity
stevepresley commentedon Jul 28, 2026
Not sure why it was auto-closed when PR hasn't merged yet.
ci(linux): enable mesh-llm feature in Linux release and canary builds (…
uevuleocha commentedon Aug 15, 2026
Still reproduces on Windows 11 with Buzz Desktop 0.5.14 — Settings → Compute shows
"Couldn't check shared compute: mesh-llm feature not enabled", the Share this machine
toggle stays on "Checking status...", and the model selector is empty.
Confirming the build-side cause from the shipped binary: buzz-desktop.exe contains the
"mesh-llm feature not enabled" string and no mesh implementation strings at all, which
matches the stub-only Windows build described here.
Noting for #3223: this machine is an Intel Arc 140V (integrated, shared memory), which is
neither CUDA nor ROCm. If the Windows native backend work lands on Vulkan, I'm happy to
test that path — GPU vendor coverage in this thread is currently AMD-only, and Arc would
exercise the Level Zero / Vulkan branch rather than the discrete-GPU one.
ci(linux): enable mesh-llm feature in Linux release and canary builds (…
stevepresley commentedon Sep 10, 2026
This completely breaks after last rebase. No point in running the nightly automation when I can't get it to work locally.
Will resubmit if no one else addresses it.
ArneBroedel commentedon Sep 25, 2026
Still reproduces on Buzz Desktop 0.5.25 (stock Windows x64 installer, 2026-09-24). Settings → Compute still returns
mesh-llm feature not enabled. Closing this as completed was incorrect for official Windows builds.This machine
C:\Users\arneb\AppData\Local\Buzz\buzz-desktop.exeProductVersion 0.5.25 (96 529 920 bytes)sm_89), driver 610.47, CUDA UMD 13.3ASCII scan of the installed
buzz-desktop.exe:mesh-llm feature not enabledmesh_llm_stubsBuzz shared compute is not available in this buildmesh-llm-sdkmesh_llm_hostNo
%LOCALAPPDATA%\mesh-llmruntime cache — the stub never downloads one.Why this is still a build/CI gap
main.github/workflows/windows-canary.ymlstill documents:No mesh-llm: release-windows doesn't build it.release.ymlrelease-windowsjob is stillpnpm tauri build ... --bundles nsiswithout--features mesh-llm.Please reopen. A signed Windows release with
--features mesh-llmis the fix; updating to 0.5.25 does not change the stub binary.ArneBroedel commentedon Sep 25, 2026
Reopening: still ships mesh_llm_stubs on official Windows 0.5.25. Evidence in the previous comment. #3223 never merged; release-windows still omits --features mesh-llm.
ArneBroedel commentedon Sep 25, 2026
Could not reopen this issue (no ReopenIssue permission). Opened a continuation with the 0.5.25 stock-Windows evidence: #7893