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 the discovery document, submits tasks, streams events and collects results over the published wire contract.
- UHP server — an implementation that exposes the contract and drives harnesses behind it (today: HarnessRouter Community Edition and HarnessRouter Cloud).
- HarnessRouter backend integration — HarnessRouter-internal support for running a specific harness (Codex, Claude Code, Hermes, Pi, DeepSeek Harness). That is neither a client nor an independent server.
Evidence taxonomy used on this page
| Level | Meaning |
|---|---|
| Implementation verified | Code speaks the published UHP wire contract (2026-08-11): discovery, tasks, streaming, continuation, cancellation. |
| Operational interoperability verified | Demonstrated against an identified UHP server, not just in unit tests. |
| Cross-server interoperability verified | Demonstrated against multiple independent UHP server implementations. |
| Server conformance | Only where the official UHP conformance suite/report supports the claim for a server. |
| Vendor-native adoption | Direct upstream/vendor evidence — never an adapter or third-party bridge. |
Both projects below reach the first level with primary code evidence. Neither has published cross-server interoperability evidence — there is not yet an independent second UHP server implementation to test against.
SuperQode — verified independent UHP client
Classification: Verified independent third-party UHP client adoption. Repository: SuperagenticAI/superqode. Its documentation states plainly that SuperQode speaks UHP as a client, targeting UHP 2026-08-11, and the implementation matches.
| Surface | Verified in code |
|---|---|
| Version pinning | UHP_PROTOCOL_VERSION = "2026-08-11"; UHP-Version header sent on requests |
| Discovery / catalog | discover() against GET /v1/uhp; list_harnesses(); remote-catalog connect flow (superqode connect uhp, TUI screen) |
| Tasks | create_response() to POST /v1/responses, optional token-budget cap |
| Streaming | SSE via stream_response() mapped to canonical harness events |
| Continuation | previous_response_id, persisted per session so new processes resume the thread |
| Cancellation | cancel_response() with session-cancel fallback; explicit cancel when giving up on dropped streams |
| Reliability | Idempotency-Key per submission; dropped-stream recovery by re-reading GET /v1/responses/{id} |
| Files | Artifact citations + download_file() |
| Errors | Typed exceptions mapped to the spec error enum; malformed streams raise rather than guess |
Current limits (stated by SuperQode itself): local files are not uploaded through UHP file input yet; harness configuration lives on the server (policy_owner: "server"); unsupported operations raise capability errors instead of pretending success.
SourceShift mini-ork — verified transport, integration in progress
Classification: verified independent UHP client/transport implementation; maturity in progress. 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
uhpandmini_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_idplus 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_harnessrouterexample lane andtests/unit/test_uhp_dispatch.py, which drives a real local HTTP test server rather than only mocking internals.
The commit self-describes as “B1 of UHP adoption” and names follow-up work (builder-side session/usage sidecar wiring; timeout/cancel exit-code integration). Re-checked at publication time: no follow-up commits had landed yet, so this guide describes mini-ork as connecting to UHP servers — not as a finished product integration, not as an independent UHP server, and not as conformant anything.
Why this page does not list more projects
A search for further independent UHP clients at verification time found no additional project with primary implementation evidence strong enough to classify. Ecosystem counts are not inflated here: two implementations with verifiable code is the honest state of independent client adoption today.
Related pages
For how UHP compares to adjacent protocols, read UHP vs MCP, UHP vs A2A, UHP vs ACP, UHP vs model APIs, and the adoption tracker, which keeps client adoption separate from server conformance and vendor-native rows.