Skip to content
UHPUHPDeveloper Guide
Independent resource · Not affiliated with HarnessRouter · Site data checked 24 Sep 2026

Ecosystem

Unified Harness Protocol ecosystem

A current map of the UHP protocol ecosystem and the broader HarnessRouter implementation ecosystem, with adoption claims kept separate.

Verified: Protocol: 2026-09-12Static SSG

Two layers that should not be mixed

Section titled “Two layers that should not be mixed”

The UHP protocol ecosystem is still smaller than the HarnessRouter product/runtime ecosystem. Backend adapters, provider routes and runtime measurements are useful implementation evidence, but they are not native UHP adoption by upstream harness projects.

UHP protocol ecosystem

Section titled “UHP protocol ecosystem”
ComponentCurrent role
UHP specificationNormative HTTP contract; current published date-version 2026-09-12, status Draft.
HarnessRouter Community EditionSelf-hosted reference implementation; stable/current main is v0.23.12 / 5c2d3bb3 with 15 released backends.
HarnessRouter CloudHosted implementation named by the UHP project.
Conformance suitePackage 2026.9.12.post2; 75 checks. PR #217 packages the canonical schema into installed distributions; PR #260 corrects the suite client’s standards-valid SSE framing parser. Neither changes protocol semantics, verdict classes or check count.
Checked HarnessRouter historical Full evidencePR #175, PR #178 and PR #190 retain 74/74 Full evidence for pre-X-09 source revisions.
Later HarnessRouter candidate evidencePR #211 reports 75/75 for the source released as v0.19.0; this is release-candidate evidence, not a replacement checked versioned report.
SuperQodeOfficially listed as UHP Server + Client; historical Full-requested measurement 42/74, with 40/40 Core and Core highest fully passed class.
uhp-goIndependent Go server/client with revision-bounded 63/63 Full evidence on its pinned earlier suite.

The current coordinates are therefore: UHP 2026-09-12; HarnessRouter stable/current v0.23.12 / 5c2d3bb3; conformance package 2026.9.12.post2; 75-check source. Those coordinates must not be inferred from one another.

HarnessRouter implementation ecosystem

Section titled “HarnessRouter implementation ecosystem”

Current stable/current main exposes 15 backends:

  1. Claude Code
  2. Codex
  3. Hermes
  4. Pi
  5. DeepSeek Harness
  6. OpenCode
  7. Qwen Code
  8. Cline
  9. Gemini CLI
  10. Oh My Pi
  11. Goose
  12. Kimi Code CLI
  13. Aider
  14. OpenHands
  15. System One

The material post-v0.19.0 expansion is:

  • v0.19.1: OpenCode reasoning-aware output accounting, 800-second console-proxy timeout alignment, and PR #217’s installed conformance-schema packaging.
  • v0.20.0: OpenHands backend through the maintained agent-server; current pin remains 1.49.2 with LiteLLM 1.94.3.
  • v0.20.1: uploaded-file ownership is organization-scoped in the reference runtime.
  • v0.21.0: System One becomes backend fifteen as a finite typed decision loop.
  • v0.22.0: direct TypeSafe AI provider support for System One.
  • v0.23.0: scoped dual-loop calibration: one calibrator may drive exactly one declared target through a short-lived target-scoped credential and package-backed configuration seam.
  • v0.23.1–v0.23.9: calibrator package access, background-run reconciliation, per-harness env/secrets and API docs, kit workspace/launch fixes, Claude Opus 5.5 catalog coverage, Claude Code 2.1.280, and current Sheets-kit fixes.
  • v0.23.10 / PR #252: explicit target identity fails closed. Unknown or deleted explicit harness ids return 404 harness_not_found instead of falling through to the generic/default backend; built-in base ids and an omitted id retain their intended paths. This is dispatch and billing-boundary hardening, not a backend or protocol addition.
  • v0.23.11 / PRs #253, #254 and #257: benchmark findings retain traces across cleanup, the public OpenAPI schema excludes fifteen console/kits routes that happen to sit under public-looking prefixes while keeping protocol routes, and live terminal paths retain incomplete_details so handoff/step-cap reasons render immediately. These are evidence/API/console fidelity corrections, not a backend or protocol addition.
  • v0.23.12 / PRs #260 and #258: the conformance client parses standards-valid SSE framed with LF, CRLF or CR and joins multi-line data: fields, advancing package metadata to 2026.9.12.post2 without adding checks; the gateway also treats non-429 runner 4xx responses as terminal verdicts and prevalidates/maps chain provider/backend compatibility rather than retrying deterministic refusals. These are measurement/runtime fidelity corrections, not a backend, adoption or UHP protocol addition.

This is reference-implementation growth. Reviewed primary sources still do not establish native UHP implementation by the 15 upstream harness projects represented as HarnessRouter backends.

Distinct adjacent layers

Section titled “Distinct adjacent layers”
  • MCP standardizes tools/resources/context and extensions, not complete-harness execution.
  • A2A standardizes agent-to-agent communication.
  • ACP standardizes client/editor-to-agent integration.
  • Agent Plugins / Agent Skills address portable extension/configuration packaging.
  • System One dual-loop calibration is a HarnessRouter/System One control-plane architecture, not a new protocol standard.
  • OpenHands agent-server integration is an adapter/runtime boundary, not native UHP adoption.

See the dedicated comparison and research pages for MCP, A2A, ACP, identity/trust protocols, loop engineering and harness composition.

What counts as real UHP ecosystem growth?

Section titled “What counts as real UHP ecosystem growth?”

High-value milestones remain:

  1. the same independent UHP client publishing interoperability runs across multiple independently maintained servers;
  2. an upstream harness project publishing native UHP support;
  3. current-revision independent SDK/server evidence beyond the reference implementation.

Primary sources

Section titled “Primary sources”