[Bug] Windows Settings → Compute: "mesh-llm feature not enabled" (mesh omitted from Windows builds)

[stevepresley]

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:

1. Go to the official Buzz Desktop Windows release and install it (e.g. 0.4.24 x64 NSIS / updater build).
2. Click on Settings.
3. Click on Compute.
4. 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-llm enabled 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.exe contains 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_llm vs mesh_llm_stubs behind feature = "mesh-llm"
  • desktop/src-tauri/src/mesh_llm_stubs.rs — all commands return "mesh-llm feature not enabled"
  • desktop/src-tauri/Cargo.toml — mesh-llm optional, not in default
• 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):

1. Enable --features mesh-llm on release-windows and windows-canary.
2. 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.
3. Implement non-macOS mesh shutdown/relaunch paths currently gated all(feature = "mesh-llm", target_os = "macos") in desktop/src-tauri/src/lib.rs.
4. Keep feature-off UX consistent: hide or clearly disable Compute rather than only showing the stub error.

Please also link from #2388.

[stevepresley]

Not sure why it was auto-closed when PR hasn't merged yet.

[uevuleocha]

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.

[stevepresley]

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.