Introduction
Speech input and spoken output are separate switches. You can dictate to Hermes and read its replies, or dictate and hear its replies. Knowing when spoken output earns its overhead, and when it just slows you down, is a real skill.
Key Concepts
- STT toggle: Whether your spoken input is transcribed. Controlled by enabling voice mode.
- TTS toggle: Whether the agent's replies are spoken aloud. A separate switch, controlled by
/voice tts. - Read versus listen: The choice between consuming a reply with your eyes or your ears.
- auto_tts: A config setting that decides whether spoken output is on by default at startup.
Real World Context
A developer enables voice input because their hands are full, but leaves spoken output off: they can glance at the screen to read replies faster than they could listen to them. Later, away from the screen entirely on a walk, they toggle TTS on so the loop is fully hands-free and eyes-free. Same person, same session, two different output decisions driven by whether their eyes are available.
Deep Dive
The core insight: STT and TTS solve different problems and should be toggled independently.
STT solves "my hands are busy or typing is costly." TTS solves "my eyes are busy or I am away from the screen." These constraints do not always occur together.
There are four combinations, and each is valid:
textSTT off, TTS off -> plain text mode STT on, TTS off -> dictate input, read replies (fast, common) STT on, TTS on -> fully hands-free and eyes-free STT off, TTS on -> type input, hear replies (rare, e.g. multitasking)
The second row is the underrated one. Speaking is often faster than typing for loose, generative input, but listening is almost always slower than reading. Reading is random-access (you can skim, jump, re-scan); audio is strictly linear and plays at one speed. So if your eyes are free, reading the reply usually beats hearing it, even when your hands are not.
That gives a clean rule of thumb: turn TTS on only when your eyes are genuinely unavailable. Walking, cooking, driving as a passenger, resting your eyes. If you are looking at the screen anyway, spoken output adds latency for no benefit.
Hermes makes this practical. /voice tts toggles spoken output on and off mid-session without disturbing voice input, so you can flip it as your situation changes. And auto_tts in config decides the startup default. Most people set auto_tts: false, because read-the-reply is the more common case, and turn TTS on explicitly when they step away.
Common Pitfalls
- Treating TTS as part of voice input: Enabling voice mode does not force spoken replies. TTS is a separate toggle; decide it on its own merits.
- Leaving TTS on at the desk: If you are watching the screen, spoken replies are slower than reading. Keep TTS off until your eyes are actually busy.
Best Practices
- Default TTS off, turn it on when eyes are busy: Set
auto_tts: falseand use/voice ttsto enable spoken output only when you step away from the screen. - Decide STT and TTS separately: Ask two questions: are my hands free (STT) and are my eyes free (TTS). Answer them independently.
Summary
- STT and TTS are independent toggles for two different constraints: busy hands versus busy eyes.
- All four on/off combinations are valid; dictate-and-read is the most common.
- Listening is linear and slower than reading, so enable TTS only when your eyes are unavailable.
/voice ttstoggles spoken output mid-session;auto_ttssets the startup default.
Code Examples
# ~/.hermes/config.yaml
voice:
auto_tts: false # spoken output starts OFF; dictate-and-read is the default
# Toggle spoken output on mid-session with the /voice tts command
# when you step away from the screen and your eyes are no longer free.