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

Independent developer reference

Unified Harness Protocol, explained for builders

A source-backed guide to UHP: the open execution contract for products that need to drive complete agent harnesses through one interface.

Checked: Protocol: 2026-09-12Latest CE release: v0.23.12
Protocol2026-09-12Draft standard
Reference implementationv0.23.12Latest release · 24 Sep 2026 UTC
Conformance source75 checksPackage 2026.9.12.post2
Start here

What is UHP?

Understand the problem UHP addresses, what an agent harness is, and what the protocol standardizes.

Protocol

Harness Plugins

UHP 2026-09-12 adds an optional binding for Agent Plugins 1.0.0 packages, including package transport, harness composition and export.

Updates

Release tracker

Track UHP specification versions separately from HarnessRouter software releases and current implementation development.

Comparison

UHP vs A2A

UHP drives an agent harness; A2A standardizes communication between independent agent systems. They can coexist.

Harness

OpenHands

HarnessRouter v0.20.0 adds OpenHands through its maintained agent server, with adapter-owned policy, persistence and credential boundaries.

Harness

System One

System One is the fifteenth released backend: a finite typed decision loop with a later scoped dual-loop calibration path.

Current state: 24 September 2026

Section titled “Current state: 24 September 2026”

UHP remains 2026-09-12 Draft; HarnessRouter stable and checked upstream main are both v0.23.12 / 5c2d3bb3. GitHub Release v0.23.12 was published on 24 September 2026 at 08:03:32 UTC from 5c2d3bb3e8b07297f2e82fd3a5075d430fb8f446. At this cutoff there is no stable/current-main divergence.

v0.23.12 corrects two interoperability/runtime fidelity boundaries without revising UHP. PR #260 makes the conformance client parse standards-valid Server-Sent Events framed with LF, CRLF or CR and join multi-line data: fields. A reproduced sse-starlette stream moves from 0 parsed events to 3; package metadata advances to 2026.9.12.post2, while the check count remains 75 and UHP stays 2026-09-12. PR #258 makes a non-429 runner 4xx a terminal request verdict rather than a startup retry, preserves the runner’s refusal body, and prevalidates/maps environment-defined chain provider/backend compatibility. In the reproduced mismatch the path changes from 28 calls and 321.9 seconds of retry behavior to one call with no sleep. HTTP 429, startup-empty/non-JSON responses and 5xx remain retryable.

v0.23.11 corrected three implementation-fidelity boundaries without revising UHP. PR #254 makes the public OpenAPI builder honor FastAPI include_in_schema=False; fifteen console/kits handlers that happen to live under public-looking prefixes are excluded while actual protocol routes under the same prefixes stay documented. PR #257 keeps terminal incomplete_details on the live POST-stream and event-bus paths, so handoff and step-limit reasons appear when a turn settles rather than only after history is reopened. PR #253 classifies a foreign-connection benchmark finding before cleanup so its trace is retained. These are API-documentation, console and benchmark-evidence corrections; they do not change the protocol version, conformance count or backend count.

v0.23.10 fails closed when a caller explicitly names a harness that does not exist. Before PR #252, an unknown explicit harness_id could fall through to the generic/default backend, execute work and bill the caller without honoring the requested target identity. Current stable/main retains the fix: unknown or deleted explicit harness ids return 404 harness_not_found, while built-in base ids remain valid and an omitted id keeps the intentional ad-hoc/default path. This is HarnessRouter dispatch and billing-boundary hardening, not a UHP protocol change.

The conformance source remains 75 checks; installed package metadata is now 2026.9.12.post2. PR #217, released in v0.19.1, bundles the exact canonical UHP schema inside installed uhp-conformance distributions and reads it through package resources. PR #260 later corrects the suite client’s SSE framing and advances the package from .post1 to .post2. Neither changes protocol schema semantics, check count or conformance verdict classes. Historical 74/74 checked artifacts and PR #211’s separate 75/75 candidate run remain revision-bounded. See Conformance.

HarnessRouter has fifteen released backends. PR #215 / v0.20.0 adds OpenHands through openhands-agent-server 1.49.2, while PR #225 / v0.21.0 adds System One as a finite typed action-space decision harness. Current stable still defaults OpenHands to 1.49.2 with LiteLLM 1.94.3, and has advanced System One to 0.4.0. These are HarnessRouter adapter/runtime coordinates, not native UHP adoption by the upstream projects.

The v0.23 line introduces a new harness-to-harness calibration boundary. System One v0.4.0 documents an outer System Two loop that calibrates an inner harness configuration. HarnessRouter PR #232, released in v0.23.0, implements the platform side: a calibrator receives a short-lived credential scoped to exactly one named target harness, can run/read that target and publish its package-backed configuration, and cannot promote itself to an organization/provider credential or control unrelated harnesses. This is reference-runtime architecture, not a new UHP protocol chapter. See System One.

The v0.23.x release train also hardens the surrounding runtime. It adds calibrator package-file access, corrects newborn background-response reconciliation, introduces per-harness environment/secrets with redaction and API docs, tightens kit workspace/launch semantics, adds Claude Opus 5.5 provider catalog coverage, pins Claude Code 2.1.280, carries the current Sheets-kit run-validator/build corrections, closes explicit-target fallthrough in v0.23.10, repairs public-schema/live-terminal/benchmark-trace fidelity in v0.23.11, and in v0.23.12 corrects conformance-client SSE parsing plus deterministic runner-refusal handling. Those are product/runtime/measurement coordinates; UHP stays 2026-09-12.

OpenHands has its own independent upstream version line. HarnessRouter currently pins OpenHands agent-server/tools/SDK 1.49.2; the upstream OpenHands repository published application release v1.22.0 on 22 September 2026 and its release notes consume SDK 1.49.4. Do not substitute the upstream app release for the adapter pin. See OpenHands.

Historical evidence remains revision-bounded

Section titled “Historical evidence remains revision-bounded”

PR #175 records HarnessRouter v0.17.2 at 74/74 Full twice. PR #178 checks in CE 0.17.2 2026-09-15T0046Z-full.json at 74/74 Full. PR #190’s checked README block identifies live CE 0.17.3 at 74/74 Full. All predate X-09. PR #211 later reports 75/75 candidate conformance for the source released as v0.19.0, but it does not rewrite the older checked artifacts.

PR #210 fixed self-hosted local POST /v1/files and added X-09, the Extended check that exercises upload + task reference rather than X-05’s inline-file path. PR #216’s reasoning-aware OpenCode output accounting and PR #214’s console-proxy timeout correction entered stable in v0.19.1. PR #217 then made installed schema-backed conformance behavior match repository-checkout behavior; PR #260 later makes valid SSE framing independent of newline convention without changing the check denominator.

Aider remains backend thirteen from v0.19.0; OpenHands is backend fourteen from v0.20.0; System One is backend fifteen from v0.21.0. Kimi Code CLI 2.0.0 remains the Kimi adapter line introduced in v0.18.1. The older v0.17.3 plugin MCP/readiness/checkpoint/catalog corrections remain inherited by current stable.

Independent conformance measurement remains implementation-agnostic. PR #170 adds generic conformance-measure; PR #172’s historical SuperQode report records 42/74 passed, 9 failed, 23 skipped, 0 errored, with all 40 Core checks passing. That report stays 42/74 because it measured the then-74-check source. aenawi/uhp-go separately keeps its published 63/63 Full evidence for its pinned earlier revision.

Provider/runtime matrices remain separate from UHP conformance. Historical examples include PR #93’s 695 harness × model pairs, PR #119’s 705/705 Oh My Pi scenarios, PR #140’s dsh/OpenRouter 189/189 rerun, PR #148’s Codex app-server provider rerun, PR #155’s custom-provider controls, PR #211’s Aider console/plugin/custom measurements, and PR #215’s OpenHands provider/runtime evidence.

Explore the guide

Section titled “Explore the guide”
TopicBest pageQuestion answered
BasicsWhat is UHP?What does the protocol actually standardize?
System modelArchitectureHow do client, UHP server and harness relate?
Normative rulesSpecification guideWhat is in version 2026-09-12?
Harness PluginsHarness PluginsHow does UHP install, compose and export Agent Plugins packages?
ImplementationGetting startedMinimum path to implement or evaluate UHP.
API referenceHTTP API mapEndpoint surface, task fields, sessions, files and optional higher-class operations.
GovernanceGovernance and versioningHow UHP changes, date-based versions, and what must stay synchronized.
SecuritySecurity and trust boundariesNormative UHP requirements for credentials, scoping, artifacts, tools and plugin execution.
LifecycleLifecycleVersion negotiation, states, sessions, streaming, cancellation, retries.
Release stateRelease trackerWhat changed, and was it protocol, tagged release or implementation development?
VerificationConformanceWhat does “UHP conformant” mean and which implementations are measured?
Independent serveruhp-goWhat revision-bounded independent UHP server evidence exists outside HarnessRouter?
Tool interoperabilityUHP vs MCPHow do harness execution and tool/context access differ?
Agent interoperabilityUHP vs A2AHow does harness execution differ from agent-to-agent communication?
Client interoperabilityUHP vs ACPHow does harness execution differ from editor/agent integration?
ImplementationsUHP clientsWhich independent client/server implementations exist, verified how?
Reference implementationHarnessRouter CEWhich capabilities belong to HarnessRouter rather than UHP itself?
New backendOpenHandsHow does HarnessRouter drive the maintained OpenHands agent server?
Decision harnessSystem OneHow do typed action spaces, incomplete results and dual-loop calibration work?
Market signalAdoption trackerWho has actually implemented or endorsed UHP?

How this site stays current

Section titled “How this site stays current”

The update cycle checks protocol versions, HarnessRouter releases/current main, conformance evidence, backend support and independent adoption. A new date is not treated as content.

Primary sources

Section titled “Primary sources”