Verified relationship
HarnessRouter Community Edition lists Hermes as a supported harness backend and the UHP specification uses hermes as an example stable base string.
In the UHP model, the product does not need to speak a Hermes-specific product integration. It targets a configured harness through the UHP server. The server is responsible for driving the actual backend and translating its execution into UHP tasks, sessions, events, artifacts and errors.
What UHP tries to normalize
- Task submission and terminal status.
- Progress streaming.
- Session continuation.
- Files and artifacts where supported by the conformance class.
- Cancellation behavior.
- Structured errors and capability discovery.
HarnessRouter integration note (post-v0.8.0 main)
The following is a HarnessRouter implementation fact, re-checked 23 August 2026. It is not a change made by Nous Research, and it does not involve upstream Hermes speaking UHP.
- What broke: hermes can emit OpenAI-legal messages that aggregator translation rejects — an assistant tool-call message carrying an empty-string
contentwas forwarded by TokenRouter to Anthropic as an empty text content block and refused with HTTP 400 ("text content blocks must be non-empty"). The failure was captured intermittently by conformance check X-05 and killed the turn, because a 400 is never retried. - The fix (shipped with
v0.8.1): HarnessRouter's openai-api path for Hermes now routes through a loopback relay that normalizes those shapes before the provider sees them — empty tool-call-message content becomes null and empty text parts are dropped; compliant requests pass through unchanged. Prevention at request time rather than retry after failure. - Credential isolation benefit: the real provider key stays inside the HarnessRouter runner process; the Hermes CLI receives only a per-turn placeholder token that the relay resolves. The key never enters the CLI's environment or its local state database.
- Documented result: patched full-class UHP runs of 52/52 — three through TokenRouter and one through LLMTR on the patched instance, with X-05 passing on every run.
- Vision routing (
v0.8.2, released 23 Aug 2026): Hermes image questions are answered by whichever integration on the HarnessRouter instance serves a vision-capable model, independently of the writing model — a routing capability of the HarnessRouter instance, not an upstream Hermes feature.
This is adapter-layer behavior inside HarnessRouter. The upstream Hermes repository's own documentation contains no UHP or HarnessRouter mention (re-checked 23 August 2026), so native-adoption status remains Not established.
What is not proven
Why the distinction matters
A reference implementation can adapt an existing harness without that harness vendor changing its own API. Native adoption would be a stronger ecosystem signal: it would mean a vendor, tool or independent runtime exposes or consumes UHP directly, reducing dependence on one adapter implementation.
Current developer implication
If you are evaluating UHP today, test the behavior you need through the official conformance suite and your target backend. Do not assume that every backend feature maps perfectly just because the common API exists. The protocol deliberately defines common semantics, while backend-specific capabilities may continue to differ.
Related pages
Read UHP architecture, conformance, and the adoption tracker.