Operate Hermes Voice Mode Across CLI and Gateways

Hermes voice mode spans several different paths: microphone input in the CLI, spoken replies in messaging platforms, and live Discord voice channels. Each path has distinct audio, dependency, authorization, and delivery requirements.

Official documentation: https://hermes-agent.nousresearch.com/docs/user-guide/features/voice-mode

Separate the voice paths

CLI voice requires a working microphone, playback device, and local audio dependencies. Gateway voice replies need speech providers plus normal Telegram or Discord delivery. Discord voice channels additionally require voice codecs, channel permissions, and user authorization. Prove one path at a time.

Choose providers by privacy and latency

Local speech recognition can avoid cloud transcription but consumes local resources. Cloud providers may reduce latency or improve quality but receive audio content. Text-to-speech choices similarly trade cost, voice quality, and key requirements. Document where audio leaves the device.

Operational checklist

  • Install the documented voice dependencies.
  • Verify microphone and playback devices.
  • Choose speech-to-text and text-to-speech providers.
  • Keep keys in the Hermes secret store, not chat.
  • Enable /voice in one target surface.
  • Set Discord authorization and mention behavior deliberately.
  • Test silence and background-noise handling.

Common pitfalls

  • Assuming text replies prove the audio path.
  • Testing Discord VC without Opus or PyNaCl support.
  • Allowing unauthorized users to drive a voice bot.
  • Using cloud speech without a privacy disclosure.
  • Enabling TTS for every message and creating noisy or costly channels.

Verification steps

  1. Run /voice status.
  2. Record and transcribe a short neutral phrase.
  3. Confirm spoken output is audible and complete.
  4. Test the intended Telegram or Discord mode.
  5. Restart the gateway and confirm the mode persists.
  6. Review logs after a failed audio test.
  7. Test an unauthorized user or channel and confirm denial.

A reliable Hermes workflow is defined by observable behavior, bounded authority, and repeatable verification—not by configuration alone.