get_runtime_capabilities was returning `accelerators = ["cpu", "vulkan"]` and `whisper.supports_gpu = true` regardless of build config or runtime state. On a macOS build it falsely advertised "vulkan" (the backend actually resolves via MoltenVK as Metal); on a whisper-disabled build it claimed GPU support for an engine that hadn't been linked. Added `compose_accelerators(whisper_enabled, loader_available, target)` — a pure helper that always emits "cpu" first and appends the platform-appropriate GPU name only when whisper is compiled in AND the Vulkan loader resolves. `supported_accelerators()` wraps it with the live `cfg!(feature = "whisper")`, loader probe, and target OS. `get_runtime_capabilities` now calls `supported_accelerators()` and sets `whisper.supports_gpu = cfg!(feature = "whisper")`. Parakeet stays CPU-only. Five tests in `commands::models::tests` cover the permutation matrix: whisper on/off, loader present/missing, macOS vs other. Both feature configurations (`--features whisper` and `--no-default-features`) build and pass tests. Macos Metal-loader resolution on real hardware stays on the ship-gate checklist — the detection logic is verifiable from Linux but runtime behaviour is not. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.8 KiB
RB-07 MAJOR: get_runtime_capabilities advertises wrong accelerators
Severity: MAJOR
Path: src-tauri/src/commands/models.rs:435-489
Source: 2026-04-22 code review
Labels: release-blocker, major, ui-integrity
Status: RESOLVED (2026-04-22)
Resolution
Added a pure compose_accelerators(whisper_enabled, loader_available, target) -> Vec<String> helper. It always emits "cpu" first and
appends "metal" (macOS) or "vulkan" (Linux/Windows) only when
whisper is compiled in and vulkan_loader_available() resolves the
platform's loader shim.
supported_accelerators() reads cfg!(feature = "whisper"), runs the
live loader probe, and delegates to the helper.
get_runtime_capabilities calls supported_accelerators() in place
of the hard-coded vec!["cpu", "vulkan"]. Whisper's supports_gpu
is now cfg!(feature = "whisper") — false on whisper-disabled
builds.
Five regression tests in commands::models::tests cover:
cpu_only_when_whisper_disabled(both targets)cpu_only_when_loader_missing(both targets)macos_with_loader_advertises_metalnon_macos_with_loader_advertises_vulkancpu_is_always_first_entry(contract the frontend relies on)
Both cargo test -p kon --lib and cargo test -p kon --lib --no-default-features pass the new suite; both cargo build -p kon
and cargo build -p kon --no-default-features compile clean.
Runtime GUI verification on a real macOS box is still on the ship-gate checklist — the detection logic is correct in code; Metal-loader resolution on hardware is not something we can unit-test from a Linux CI.
Problem
The IPC response hard-codes accelerators = ["cpu", "vulkan"] and supports_gpu = true for Whisper, even when:
detect_active_compute_devicewould reportmetalon macOS (via MoltenVK).- The binary was compiled without the
whisperfeature — in which case Whispersupports_gpuis meaningless because there is no Whisper backend at all.
The frontend uses this response to render Settings toggles (GPU selection, active-device badge, feature availability). Wrong values mean wrong UI states on exactly the builds this function is meant to describe.
Acceptance
acceleratorsis derived from actual build configuration and runtime probe, not hard-coded.- On macOS,
acceleratorsincludes"metal"when the Metal loader resolves. - On whisper-disabled builds, Whisper entries advertise
supports_gpu = false(or the engine is omitted from the response entirely). - Regression tests cover each platform variant via cfg-gated test cases.
Fix scope
Medium. The detection helpers already exist (detect_active_compute_device, vulkan_loader_available); this is about wiring their output into the RuntimeCapabilities struct honestly.
Dependencies
- None — standalone fix.