Bug: Hermes Desktop voice transcription hardcodes OpenAI API

[midulhasan-new]

Problem Description

The voice transcription / microphone feature in the Hermes native desktop app appears to be hardcoded to call OpenAI's Whisper API (api.openai.com/v1/audio/transcriptions) and expects an OPENAI_API_KEY.

Actual Behavior

Even when stt.provider is set to groq (or other providers) in config.yaml, clicking the microphone button throws a 401 Invalid API Key error from OpenAI if no OpenAI key is provided in .env.

Expected Behavior

The desktop app should respect the configured stt.provider (e.g., Groq, local, etc.) rather than forcing OpenAI API for transcription.

Environment

• OS: Windows 10
• Hermes Version: 0.20.0

[DavidMetcalfe]

Hi @midulhasan-new, thanks for the detailed report.

I traced the full transcription path for v0.20.0 and the desktop app does not hardcode the OpenAI Whisper endpoint — provider selection is config-driven end to end:

• The Desktop mic button posts the recording to the local backend endpoint /api/audio/transcribe (apps/desktop/src/hermes.ts, transcribeAudio). There is no direct api.openai.com call anywhere in the desktop app.
• That endpoint routes through tools.transcription_tools._get_provider(), which treats an explicitly configured stt.provider as authoritative — no silent cross-provider fallback. This behavior landed in PR fix(security): PKCE verifier leak, OAuth refresh Content-Type, tool_choice mcp_ prefix #1775 (merged 2026-03-17, closing STT Provider Selection Logic: Placeholder API keys treated as valid credentials #1774 — the same bug class: an explicit provider was bypassed because a placeholder OpenAI key in the environment was treated as valid, producing exactly this 401).
• With stt.provider: groq, v0.20.0 either transcribes via Groq (api.groq.com) or resolves "none" with a clear GROQ_API_KEY not set warning — it does not fall through to OpenAI.

So a 401 from api.openai.com means provider auto-detection ran and selected OpenAI, which happens when the backend did not see stt.provider in the config it loaded. The most common cause on Windows is a config-location mismatch: the native Windows Hermes home is %LOCALAPPDATA%\hermes (see hermes_constants.get_default_hermes_root), so the desktop backend reads %LOCALAPPDATA%\hermes\config.yaml — editing %USERPROFILE%\.hermes\config.yaml (the POSIX-style path) has no effect there. Related config-scoping bugs (#66012, #73653) were fixed in late July, and the current desktop audio helpers are profile-scoped.

To confirm, could you share:

1. The exact path of the config.yaml you edited — check whether %LOCALAPPDATA%\hermes\config.yaml actually contains your stt.provider: groq entry (this is the file the desktop backend loads on Windows).
2. What the Desktop Settings → Capabilities → STT panel shows for the provider (vs. what you set manually).
3. The agent.log lines from a mic click (the backend logs which provider it selected and why).
4. Whether OPENAI_API_KEY is set in the Windows user/system environment variables.

Based on the code, this looks like a config-discovery mismatch rather than a hardcoded OpenAI call — the underlying bug class was fixed in March 2026 (PR #1775). I'll keep this open until we have your config-path and log confirmation; if they show the backend is genuinely ignoring an stt.provider present in the config file it actually read, I'll dig back in.