Independent developer guide. Not affiliated with HarnessRouter or the official UHP project.

UHP clients & independent implementations

UHP has independently implemented clients and servers outside HarnessRouter. This page records exactly what their code and measured evidence establish.

Page reviewed 4 Oct 2026 Source and review policy

Source snapshot protocol: 2026-09-12

Client, server, backend — three different roles

UHP defines three roles that are easy to conflate:

UHP client — a product, CLI or framework that consumes UHP servers: it reads discovery, submits tasks, streams events and collects results over the published wire contract.
UHP server — an implementation that exposes the contract and drives a harness behind it. HarnessRouter Community Edition is the reference implementation; aenawi/uhp-go and SuperQode are separately maintained public server implementations.
Harness backend integration — support inside a UHP server for running a specific upstream harness. That is neither a client nor evidence that the upstream harness vendor adopted UHP natively.

Select a client/server pair by revision and required operations

Current source retrieval on 4 October separates project currency from wire support: AIWG v2026.10.0 still calls its UHP client experimental and pins 2026-08-11; mini-ork v0.9.0 retains a direct-HTTP 2026-08-11 transport; SuperQode v2.5.5 documents both connect uhp and serve uhp, with server protocol 2026-09-12. A latest project tag does not automatically upgrade its UHP contract.

Before pairing	Check
Discovery/negotiation	Client’s supported version against server’s advertised version
Required lifecycle	Streaming, continuation, cancellation and stored-response reconciliation
Required data path	Upload, artifacts, bounded download and owner authorization
Credentials/network policy	Named secret reference, endpoint scope and redirect/private-network rules
Qualification	Exact client build, server build, model/harness and tested operations

Use an isolated endpoint and inert fixture first. After an ambiguous submission, reconcile on the same endpoint using the original response/request identity before trying a different transport: otherwise two servers may both execute the task. This follows AIWG’s current client guidance.

System One is another native server candidate, separately from its HarnessRouter adapter: v0.4.0 documentation names s1 serve; its project-authored report measures implementation 0.1.0, 40/40 Core under 2026.9.12.post1, on loopback. These sources do not establish a current 85-check Full result or a cross-server client matrix. See adoption for the exact evidence classification.

Evidence taxonomy used on this page

Level	Meaning
Implementation verified	Code speaks a published UHP wire contract.
Operational interoperability verified	Demonstrated against an identified UHP server, not just unit tests.
Cross-server interoperability verified	Demonstrated by the same client against multiple independently maintained UHP servers.
Server conformance	Only where the official UHP conformance suite/report supports the named class and revision.
Vendor-native adoption	Direct upstream/vendor evidence — never an adapter or third-party bridge.

The client projects below have primary implementation evidence. No reviewed client has yet published a cross-server matrix showing the same client against HarnessRouter and another independently maintained server. That remaining gap is about measured cross-server client behavior, not whether independent servers exist.

Official implementations list vs this tracker

The official UHP implementations source, re-opened 4 October, lists:

HarnessRouter Community Edition — Server; current listing still says UHP 2026-09-12, while the released specification has advanced to 2026-09-28. The listing is not the current protocol registry.
SuperQode — Server, UHP 2026-09-12.
SuperQode — Client, UHP 2026-09-12.

The project explicitly says these are community-maintained factual listings, not endorsement or certification. Conformance levels are derived only from checked measurement reports. This site uses a broader evidence tracker, so AIWG, mini-ork and uhp-go remain visible even when their exact role/revision is not represented by a current official card.

AIWG — released experimental UHP client transport

Classification: verified independent UHP client implementation; feature explicitly experimental. Repository: jmagly/aiwg. AIWG release v2026.8.20 ships a UHP 2026-08-11 client transport, and its own release/documentation explicitly says the UHP feature remains experimental, client-only, and is not a server-conformance claim.

Surface	Verified in current implementation/documentation
Version boundary	Pinned to UHP `2026-08-11`; sends and validates `UHP-Version`; no silent downgrade or cross-protocol fallback
Discovery / catalog	`GET /v1/uhp`, harness discovery and model listing through the `aiwg uhp` CLI and `UhpClient`
Tasks	`POST /v1/responses` with deterministic idempotency keys and explicit endpoint profiles
Streaming	SSE event-stream execution with sequence/terminal validation and unknown-state reconciliation
Continuation / stored reads	Package API preserves response/session identity and supports continuation plus authoritative stored-response reads
Cancellation	Cancellation request followed by authoritative response-state verification; request alone is not treated as proof of cancellation
Files / artifacts	Input upload, artifact listing and bounded retrieval into approved destinations
Security boundary	Named endpoint profiles, secret-reference credentials, host/private-network/redirect controls, response-size limits, filename containment and a dedicated UHP client threat model
Qualification	Offline UHP qualification fixtures are shipped; documentation also defines an opt-in live qualification path against an explicitly identified UHP implementation

AIWG’s architecture decision keeps UHP separate from its provider, A2A and MCP boundaries. HarnessRouter may be a qualification target, but the client is written against the versioned UHP contract rather than HarnessRouter-private behavior.

SuperQode — released UHP client and server

Classification: verified independent UHP client + server implementation; public server measured Core conformant. Repository: SuperagenticAI/superqode. Current stable is v2.5.5, published 4 October 2026 at 08:53:09 UTC; checked main is 9cc8c158b844b3be54df8f51536f3adde704783e. The measurement and security correction below remain tied to versions 2.3.1 and 2.3.2.

SuperQode retains the client flow (superqode connect uhp) and now exposes its own configured HarnessSpec as a UHP server through superqode serve uhp. The official UHP implementations list records SuperQode in both the Client and Server roles, targeting UHP 2026-09-12.

The server is intentionally not a HarnessRouter replacement: it binds one configured SuperQode HarnessSpec and exposes that harness through the UHP contract. The server advertises 2026-09-12 and 2026-08-11, defaulting to 2026-09-12.

Independent measurement

HarnessRouter PR #172 runs the official 2026.9.12 suite against https://uhp.superqode.dev. The Full-requested report identifies SuperQode 2.3.1 and records:

42/74 passed · 9 failed · 23 skipped · 0 errored
highest fully passed class: Core

All 40 Core checks pass. Extended and Full do not. This is Core conformance evidence, not Full conformance and not a 42/74 “score” that can be promoted to another class.

`v2.3.2` security correction

The v2.3.2 release closes a remote-catalog authentication exposure present since serve uhp shipped in 2.2.2. Architecture section 5 permits unauthenticated discovery, but SuperQode had also allowed the harness catalog without a bearer, exposing harness id, model list and harness configuration and causing the auth checks to fail. A remote bind now requires bearer authentication for the catalog by default. Operators can explicitly restore the previous behavior with --public-catalog.

The release notes cite the independent HarnessRouter measurement: Core passes 40/40, including both auth checks. At that measurement cutoff, the shared public host did not reach Extended because artifact retrieval is deferred and session listing is disabled when one bearer is shared.

Surface	Historical v2.3.2 verified state
Stable release	`v2.3.2`
Checked `main`	`06fa5358`
Client	`superqode connect uhp`
Server	`superqode serve uhp`
Server protocol versions	`2026-09-12`, `2026-08-11`; default `2026-09-12`
Official implementations list	Client + Server
Public conformance	Core 40/40; Full-requested report 42/74 with 9 failed, 23 skipped
Remote catalog auth	bearer required by default in `v2.3.2`; `--public-catalog` is explicit opt-in
Packaging	`pip install 'superqode[uhp]'`; `uhp` extra represented in `uv.lock` in `v2.3.2`

SuperQode’s client still does not establish cross-server interoperability simply because the same project also ships a server. A useful cross-server client claim would run the client against multiple independently maintained servers and publish that evidence.

SourceShift mini-ork — released direct-HTTP client transport

Classification: verified independent UHP client/transport implementation; operational qualification is separately scoped. Repository: SourceShift/mini-ork. Commit aaf22c3 (“feat(dispatch): add uhp provider kind”, 23 Aug 2026) adds a stdlib-only direct HTTP transport for UHP 2026-08-11.

Adds provider kind uhp and mini_ork/dispatch/uhp.py: POSTs to /v1/responses, parses Server-Sent Events, sends bearer authentication through configured secret-env plumbing.
Treats the UHP server as owner of harness/model routing; optional metadata.harness_id.
Continuation via previous_response_id plus a per-run session sidecar convention.
Typed/partitioned exit behavior for invalid request/config, server unavailable, harness error, timeout and cancellation/client abort; lane health and required-secret checks.
Ships a committed uhp_harnessrouter example lane and tests/unit/test_uhp_dispatch.py, which drives a real local HTTP test server rather than only mocking internals.

The introduction commit self-described as “B1 of UHP adoption” and named follow-up work. Current v0.9.0 and transport source retain client-only 2026-08-11 behavior; source availability does not establish a completed cross-server qualification matrix or server conformance.

Why this page does not list more projects

This tracker records three independent client implementations with primary code evidence: AIWG, SuperQode and SourceShift mini-ork. It also records separately maintained server evidence for uhp-go, SuperQode and native System One. The list remains conservative: copied schemas, UHP mentions, HarnessRouter backend adapters or unverified compatibility claims are not enough.

aenawi/uhp-go publicly implements the server contract and records 63/63 Full, zero skipped for the post-R-08 suite revision it pinned on 1 September. That is exact revision-bounded evidence and is not silently upgraded to the current 85-check suite.

For measured server evidence, read conformance and uhp-go. For how UHP compares to adjacent protocols, read UHP vs MCP, UHP vs A2A, UHP vs ACP, and the adoption tracker.

Client, server, backend — three different roles

Select a client/server pair by revision and required operations

Evidence taxonomy used on this page

Official implementations list vs this tracker

AIWG — released experimental UHP client transport

SuperQode — released UHP client and server

Independent measurement

v2.3.2 security correction

SourceShift mini-ork — released direct-HTTP client transport

Why this page does not list more projects

Related pages

Primary sources

`v2.3.2` security correction