hermes - 💡(How to fix) Fix [Feature]: Add VoxCPM2 as an optional local TTS provider via external helper [1 participants]

Problem or Use Case

Hermes already has a few built-in TTS providers, including local ones like NeuTTS, but there is no first-class path for a local voice-cloning provider that needs to run in a separate Python environment.

VoxCPM2 seems like a reasonable fit for that gap:

• local inference
• reference-audio voice cloning
• no cloud dependency
• good Chinese support

The wrinkle is that Hermes itself runs on Python 3.11 in many setups, while VoxCPM2 often wants a separate environment and dependency stack. So this is not just “add another import and another API key”.

Proposed Solution

Add optional first-class voxcpm support as a built-in TTS provider, but keep the runtime isolated behind an external helper process.

Rough shape:

• Hermes main process keeps its current runtime and does not import voxcpm directly.
• tools/tts_tool.py gets a new provider branch, voxcpm.
• That provider shells out to a small helper script using a configurable external Python path.
• The helper handles:
  • readiness probe
  • one synthesis request
  • reference-audio clone mode
  • optional design-prompt fallback when no reference is available
• Hermes keeps its existing output flow after synthesis:
  • return MP3 / WAV normally
  • convert to Opus / voice-bubble formats where the current TTS pipeline already does that

Important scope boundary for v1

I am not proposing the “hot worker” / persistent loaded model optimization in the first PR.

For a first upstreamable version, I think the right scope is:

• provider dispatch
• config keys
• readiness/probe
• synthesis helper boundary
• targeted tests
• basic docs

If the maintainers want the feature at all, performance work can come later.

Why this should be built-in instead of a skill

I did consider “just make it a skill”, but I think there is a real argument for provider-level support here:

• it needs to plug into the existing text_to_speech tool path
• it should participate in the normal platform delivery behavior
• it should show up in setup / doctor / readiness checks
• it needs provider-specific config and runtime validation

That feels closer to NeuTTS than to a niche one-off skill.

Alternatives Considered

1. Keep this as a local patch only

Works for one machine, but makes the integration effectively private and hard to reuse.

2. Publish it as a skill instead of a provider

Possible, but it would sit outside the normal TTS provider flow and lose a lot of the existing Hermes delivery behavior.

3. Require Hermes to import VoxCPM2 directly

I would avoid this. It couples Hermes too tightly to a heavy and version-sensitive dependency stack.

The helper boundary is the main reason this feels upstreamable at all.

Feature Type

Configuration option

Scope

Medium (few files, < 300 lines)

Contribution

• I'd like to implement this myself and submit a PR

Debug Report (optional)

N/A — this is a feature RFC, not a live bug report.