Hermes Agent Wake Word: How to Set Up Hands-Free Voice Activation in 2026 (Engines, Config, Troubleshooting)

Hermes Agent now ships a built-in wake word feature: say "Hey Hermes" (the default phrase) and the agent pauses its always-on listener, opens a fresh session, records one spoken command, transcribes it, and replies through text-to-speech — entirely on your machine, off by default, with no audio leaving the device until you actually speak a command. It works across the CLI, the terminal UI (hermes --tui), and the desktop app, and it is the closest thing to "Hey Siri for your AI coding agent" available in any open-source agent framework as of July 2026. The whole feature is free, MIT-licensed, and takes under a minute to switch on with a single /wake on command — but picking the right of three detection engines and tuning for false triggers is where most people get stuck, and this guide walks through all of it.

Last verified: 2026-07-31 · Default phrase: "hey hermes" · Three free engines: openWakeWord, sherpa, Porcupine · Detection is 100% on-device · Run hermes update first — the wake engines shipped in the July 2026 update.

• One-command enable: type /wake on inside any interactive Hermes session (or click the ear icon in the desktop composer); /wake status shows the active phrase and engine; /wake off stops listening.
• Off by default, privacy-first: nothing listens until you turn it on, and the local hotword detector only watches for the wake phrase — no audio is sent anywhere until you speak a command to the agent.
• Three swappable engines: openWakeWord (default, bundled "hey hermes" model, free, no key), sherpa (open-vocabulary, any typed phrase, zero training, free), and Porcupine (Picovoice, highest accuracy, free tier with access key).
• Custom phrases work out of the box: "computer", "wake up neo", or "hey [profile-name]" — the sherpa engine tokenizes any phrase at runtime with no model training.
• Multi-profile routing (desktop): one listener can wake any enrolled profile by name — say "hey coder" and the desktop live-switches to that profile and opens a session there.
• Two known gotchas: macOS grants microphone access per process (the listener runs in the Python backend, not the renderer), and Windows uses a different mic path for push-to-talk vs. wake capture — both are fixable (see the troubleshooting matrix).

What is the Hermes Agent wake word and how does the loop work?

The Hermes wake word is an on-device hotword detector that watches your microphone for a trigger phrase and, on hearing it, starts a hands-free voice session — the "Hey Siri" or "Alexa" pattern, but applied to a full autonomous AI agent with tool access, persistent memory, and skills. The loop is deliberate and single-mic-safe:

1. With wake_word.enabled: true (or after /wake on), a lightweight detector listens on your configured input device, or the process default microphone when wake_word.input_device is unset.
2. When it hears the wake phrase it pauses itself — freeing the microphone so the recording does not fight the listener for the input stream.
3. Hermes starts a new session and records one utterance using the same silence detection that powers voice mode.
4. Your speech is transcribed (via your configured speech-to-text provider — faster-whisper works locally, Groq is the fast cloud option) and sent to the agent.
5. After the agent replies (via your text-to-speech provider — edge-tts works with no API key), the listener resumes automatically and waits for the next wake word.

The feature is off by default — nothing listens until you flip it on, and the toggle persists: /wake on writes wake_word.enabled: true to ~/.hermes/config.yaml, so your choice survives across sessions. On the desktop app, a hands-free conversation can be ended by speaking one of the stop phrases — "stop", "never mind", "goodbye", "cancel", "that's all" — which close the session instead of being sent to the agent. Only a whole-utterance stop command matches, so a real request like "stop the docker container" still goes through normally.

How do you enable the Hermes wake word? (step-by-step)

Enabling the wake word takes seconds, but you must update first — the wake engines shipped in the July 2026 Hermes Agent update, so an older install will not have them.

Step 1 — Update Hermes

hermes update

This pulls the latest release and the wake-word dependencies. If you want to pre-install the engines ahead of time (so the first /wake on does not trigger a one-time download), run:

cd ~/.hermes/hermes-agent && uv pip install -e ".[wake]"

Step 2 — Switch the listener on

Inside any interactive hermes session (CLI, TUI, or desktop), type:

/wake on

On first use this lazy-installs the default engine (openWakeWord) and its shared feature-extraction models — a small one-time fetch. In the desktop app, click the ear icon in the composer.

Step 3 — Verify it is listening

/wake status

This prints the active phrase, the provider/engine, the input device, and the listening state. It also reports exactly what is missing if the listener will not start (a missing STT provider, a silent mic, a missing permission).

Step 4 — Switch it off when you do not want it listening

/wake off

Because the feature is off by default and only watches for the wake phrase when on, this is a genuine privacy toggle — when it is off, no audio is captured at all. You can also flip wake_word.enabled by hand in ~/.hermes/config.yaml:

wake_word:
  enabled: true

Which wake-word engine should you pick? (the three compared)

All three engines are on-device, but they differ in flexibility, accuracy, and setup cost. Here is the comparison from the official Hermes documentation:

Engine	Cost	API key needed?	Custom phrase?	Best for
openWakeWord (default)	Free	None	Requires a trained model (bundled "hey hermes" ships; custom ones need ~75–90 min on a free Colab GPU)	Most users — "hey hermes" works out of the box, zero config
sherpa	Free	None	Any typed phrase, zero training — tokenized at runtime; ~13 MB English model downloads on first use	Custom phrases and multi-profile routing — "hey coder", "computer", "wake up neo"
Porcupine (Picovoice)	Free tier / paid	PORCUPINE_ACCESS_KEY	Built-in keywords + custom .ppn files via Picovoice Console	Highest accuracy and smallest footprint; users who want Picovoice-grade detection

Verdict — which to use:

• Start with openWakeWord (the default). The bundled "hey hermes" model works the moment you run /wake on and needs no key, no training, and no extra download beyond a small one-time feature-extractor fetch. This is the right choice for 90% of users.
• Switch to sherpa the moment you want a custom phrase ("hey coder", "computer") without training a model, or you want multi-profile routing on the desktop (one listener, any phrase per profile). Sherpa is the open-vocabulary trick that makes the wake word personal — it is, in practice, the most underrated part of this update.
• Use Porcupine if you need the highest detection accuracy and smallest footprint and do not mind registering a Picovoice access key (free tier available). You create a keyword in the Picovoice Console, download the .ppn, and point porcupine.keyword at it.

A subtle but important technical note from the docs: openWakeWord scores one short (~80 ms) audio frame at a time, so a stray phoneme in background conversation can spike a single frame over the threshold and fire a false wake. Sherpa and Porcupine decode the whole phrase internally, so they do not suffer the single-frame-spike problem and ignore the confirmation_frames knob (they still honor sensitivity). If you are in a noisy room and getting false triggers on openWakeWord, switching to sherpa is often a cleaner fix than tuning confirmation_frames.

How do you change the wake phrase to something other than "Hey Hermes"?

You do not have to say "Hey Hermes." The default phrase is just the bundled model's keyword. There are three ways to wake on something else, ranked easiest to hardest:

Option A — sherpa (any phrase, zero training)

Type the phrase you want and it is tokenized at runtime. No training, no model files, works immediately:

wake_word:
  enabled: true
  provider: sherpa
  phrase: "hey coder"      # detection key — just type your phrase

The small English KWS model (~13 MB) downloads once on first use. This is the easiest path to a custom wake word in any open-source agent framework — most systems require you to train a model.

Option B — openWakeWord (free, trained model)

Use a built-in model (hey_jarvis, alexa, hey_mycroft) or train a custom one (~75–90 minutes on a free Colab GPU), drop the .onnx file, and reference it:

wake_word:
  provider: openwakeword
  openwakeword:
    model: ~/.hermes/wakewords/computer.onnx

The docs include a 2026 training Colab reference for building custom models.

Option C — Porcupine (custom keyword in seconds)

Create a "Hey Hermes" keyword in the Picovoice Console, download the .ppn, and:

wake_word:
  enabled: true
  provider: porcupine
  phrase: "hey hermes"
  porcupine:
    keyword: ~/.hermes/wakewords/hey_hermes.ppn

Set your access key in ~/.hermes/.env:

PORCUPINE_ACCESS_KEY=your-key-here

Picking a good phrase: the official guidance is that phrases which do not collide with everyday speech generalize best. Two syllables with an uncommon word ("hermes" qualifies) beat common words like "hello" or "stop."

Full wake-word configuration reference

Here is the complete wake_word block from the official docs, with every knob explained:

wake_word:
  enabled: false
  surface: auto                # "auto" | "cli" | "tui" | "gui" — which surface owns the listener
  input_device: null           # PortAudio input index or device-name substring; null = process default
  provider: openwakeword      # "openwakeword" | "sherpa" | "porcupine"
  phrase: "hey hermes"        # cosmetic label only — detection is keyed by the model/keyword below
  sensitivity: 0.6            # 0.0–1.0 — higher = stricter (fewer false triggers), consistent across all engines
  confirmation_frames: 3      # openWakeWord only — consecutive over-threshold frames required to fire
  start_new_session: true     # start a fresh session on wake vs. continue the current one
  openwakeword:
    model: hey_hermes          # bundled default; OR a built-in name OR a path to a custom .onnx/.tflite
    inference_framework: ""   # "" (auto) | "onnx" | "tflite"
  porcupine:
    keyword: jarvis            # built-in keyword OR path to a custom .ppn

Reducing false triggers on ambient speech

Two knobs control this, both in the openWakeWord path:

• confirmation_frames (default 3, openWakeWord only) — how many consecutive over-threshold frames are required before the wake fires. A real "hey hermes" holds a high score across several frames; an ambient blip spikes just one. Raise it to 4–5 if you still get false triggers in a noisy room — the cost is a few tens of milliseconds of extra latency. 1 restores fire-on-first-frame behavior.
• sensitivity (default 0.6) — the detection threshold, 0.0–1.0. Higher is stricter (fewer false triggers). This direction is consistent across all three engines. Raise toward 0.8 in noisy environments; lower it if real "hey hermes" utterances are being missed.

The inference_framework setting is worth knowing on Apple Silicon: leave it empty (the default) and Hermes chooses per platform — tflite on Apple Silicon, onnx everywhere else. openWakeWord's onnx backend returns near-zero scores on macOS ARM64, so a listener pinned to onnx there will arm, show as listening, and never fire. The tflite backend needs ai-edge-litert on macOS, which Hermes installs on demand alongside the other wake-word deps.

Surfaces — who owns the microphone

surface	Behavior
auto (default)	All local surfaces are eligible; the first one to arm owns the listener. Ownership is sticky until that process exits.
cli	Only the classic hermes CLI.
tui	Only hermes --tui.
gui	Only the desktop app.

The detector is on-device and single-mic, so only one surface listens at a time, even when Hermes surfaces run in separate processes. Hermes does not silently fail over to another open surface — set surface when you want to pin ownership instead of using first-claim-wins. The TUI and desktop GUI share the same Python backend (tui_gateway), which runs the detector server-side and yields the mic to voice capture while a command records.

How does multi-profile voice routing work on the desktop?

With the sherpa engine, one listener can wake any enrolled profile. Every profile whose config has wake_word.enabled: true is enrolled automatically, and its phrase defaults to hey <profile name> when unset. Say a profile's phrase and the desktop app live-switches to that profile, opens a fresh session there, and starts hands-free voice:

• "hey hermes" → the default profile
• "hey coder" → the coder profile
• "hey trader" → the trader profile

This is the most powerful and least-advertised part of the update: instead of one wake word for one agent, you get a hands-free switchboard for a whole team of specialist agent profiles. If you already run a voice-activated agent operating system with shared memory and per-profile skills, the sherpa engine turns it into a spoken multi-agent dashboard — say the name, the desktop live-switches, and you are talking to that specialist.

Two practical tips from the docs: two-word phrases with distinct 2+ syllable names work best, and similar-sounding profile names degrade accuracy — so name profiles distinctly and tune per-profile sensitivity if you hear misfires. CLI and TUI are single-profile processes, so a phrase for another profile prints the switch command instead of routing.

What does it cost to run the Hermes wake word?

The detection itself is free on all three engines — openWakeWord and sherpa need no API key and run locally; Porcupine has a free tier (requires an access key). The only ongoing cost is the LLM tokens for the commands you actually speak, plus your STT and TTS providers:

• STT (transcription): faster-whisper runs locally with no key; Groq's cloud Whisper is the low-latency option (under one second for short messages).
• TTS (spoken replies): edge-tts works with no API key and no extra install.
• LLM: whatever you already pay — and because the wake word only fires a session when you speak a command, you are not paying for idle listening. The detector only watches for the phrase.

If you want to drive the LLM cost down further, Hermes supports free model routing via OmniRoute-style gateways that aggregate 90+ free providers, so you can run the whole voice loop on free tiers for casual use and switch to a frontier model only for heavy tasks.

"Listening" but never wakes, or receives silence — the troubleshooting matrix

These are the two most common failure modes, and both are microphone-path issues, not detection issues:

"Listening" but never wakes (macOS)

macOS grants microphone access per process. The wake listener runs in the Python backend, which needs its own grant — and the desktop renderer having mic access does not prove the backend does. Without it, CoreAudio hands the backend a "working" stream that only ever delivers silence, so the ear shows listening but the phrase never fires. Hermes detects this: /wake status shows "mic delivers only silence" and the desktop ear tooltip carries the same hint.

Fix: System Settings → Privacy & Security → Microphone → enable the Hermes backend (it may appear as your terminal, python, or Hermes), then toggle the wake word off and on.

"Listening" but receives silence (Windows)

Desktop push-to-talk and wake-word capture use different microphone paths. Push-to-talk uses the desktop application's browser capture; the wake-word listener opens a PortAudio stream in the Python backend. One can work while the other selects a silent or unusable Windows input.

/wake status reports the selected input device and Windows audio host API. When it reports silence, set wake_word.input_device to the numeric index or an unambiguous name of the working PortAudio input, then toggle the wake word:

hermes config set wake_word.input_device "Microphone Array"

Use null to return to the process default:

hermes config set wake_word.input_device null

Other limits to know

• Local surfaces only. The wake word runs in the CLI, TUI, and desktop GUI — wherever a local microphone is available. It does not run in the messaging gateway (Telegram, Discord, …), which has no mic.
• One mic at a time. The detector releases the microphone while a command is recording and reclaims it once the turn ends, so it will not fight voice capture.
• Privacy. Hotword detection is local. Set sensitivity higher if you get false triggers, lower if it misses you.

What this means for you

If you are already running Hermes Agent for coding, research, or automation, the wake word is a one-minute upgrade that turns it from "open a terminal and type" into "say the word from across the room and it answers." The practical wins:

• For solo builders: start with openWakeWord (the default) and the bundled "hey hermes" model — it works the moment you run /wake on. Add sherpa only if you want a custom phrase or multi-profile routing.
• For teams running a multi-profile agent setup: switch to sherpa and give every profile its own hey <name> phrase. One listener wakes any specialist by name on the desktop — this is the feature that makes a shared-memory agent dashboard genuinely hands-free.
• For anyone on macOS or Windows hitting the "listening but silent" bug: the fix is a mic-permission grant (macOS) or an explicit input_device setting (Windows), not a re-install. Check /wake status first — it tells you exactly what is wrong.
• For privacy-conscious users: detection is fully on-device, off by default, and only watches for the wake phrase. No audio leaves your machine until you speak a command to the agent. This is a meaningfully better privacy posture than cloud-dependent wake words.

The feature is free, MIT-licensed, and the official documentation lives at hermes-agent.nousresearch.com/docs/user-guide/features/wake-word. Run hermes update, type /wake on, and try it. If you want to pair it with an autonomous agent that can also run tasks while you step away, the same update cycle has made autonomous agent OS features and free model routing genuinely production-usable in 2026.

FAQ

Q: How does the Hermes Agent wake word work? A: A lightweight on-device hotword detector watches your microphone for a trigger phrase. When it hears the phrase, it pauses itself (freeing the mic), starts a fresh Hermes session, records one utterance with voice mode's silence detection, transcribes it, sends it to the agent, and replies via TTS — then the listener resumes and waits for the next wake. Detection is 100% local and off by default.

Q: How do I turn the Hermes wake word on and off? A: Inside any interactive Hermes session, type /wake on to start listening (it installs the default engine on first use), /wake status to show the phrase, provider, and state, and /wake off to stop. In the desktop app, click the ear icon in the composer. The toggle persists — /wake on writes wake_word.enabled: true to ~/.hermes/config.yaml.

Q: Can I change the wake phrase to something other than "Hey Hermes"? A: Yes. The easiest path is the sherpa engine, which tokenizes any typed phrase at runtime with zero training — set provider: sherpa and phrase: "hey coder" (or "computer", "wake up neo", anything). With openWakeWord you use a built-in model (hey_jarvis, alexa) or train a custom one. With Porcupine you create a keyword in the Picovoice Console and download a .ppn file.

Q: Is the Hermes wake word always listening? A: No. It is off by default — nothing listens until you explicitly turn it on. When it is on, the local detector only watches for the wake phrase; no audio leaves your machine until you actually speak a command to the agent. You can toggle it off anytime with /wake off.

Q: Which of the three engines should I use? A: Start with openWakeWord (the default) — the bundled "hey hermes" model works out of the box with no key and no training. Switch to sherpa if you want a custom phrase without training a model or you want multi-profile routing on the desktop. Use Porcupine if you need the highest accuracy and smallest footprint and do not mind registering a free Picovoice access key.

Q: Does the wake word work on Telegram or Discord? A: No. The wake word runs only on local surfaces — the CLI, TUI, and desktop GUI — wherever a local microphone is available. The messaging gateway (Telegram, Discord, etc.) has no microphone, so the wake listener does not run there. Voice replies on those platforms use a different path (voice memo transcription on Telegram, voice channels on Discord).

Sources

• Hermes Agent — Wake Word documentation (official) — configuration reference, engines table, troubleshooting, surfaces, multi-profile routing. Nous Research.
• Hermes Agent — Voice Mode documentation (official) — prerequisites (microphone, sounddevice + numpy, STT/TTS providers), CLI voice mode, silence detection. Nous Research.
• Hermes Agent — Features Overview (official) — wake word listed as a shipped feature across CLI, TUI, and desktop. Nous Research.
• Nous Research on X — "Hermes Agent now has voice activation" (Jul 29, 2026) — official announcement; confirms hands-free, local, off-by-default.
• AlphaSignal — "Nous Research Ships Hands-Free 'Hey Hermes' Wake Word to Its 175K-Star Agent" (Jul 29, 2026) — independent confirmation of the three engines, multi-profile routing, and _wake on enablement; datePublished 2026-07-29T16:52:32Z.
• openWakeWord — "Hey Hermes" wake word model library entry — confirms the "hey hermes" model is publicly available in ONNX format, open source, trained with multilingual TTS voices.
• GitHub — NousResearch/hermes-agent commands.py — confirms the /wake command definition: "Toggle the 'Hey Hermes' wake word listener", subcommands on/off/status.

Updates & Corrections

• 2026-07-31 — Article first published. All facts verified against the official Hermes Agent documentation (hermes-agent.nousresearch.com), the Nous Research announcement (Jul 29, 2026), and the AlphaSignal independent report (Jul 29, 2026). No claims from secondary sources were used without a primary confirmation; pricing/feature facts are volatile and should be re-checked on major Hermes releases.

---