Tracker rule: “supported by the reference implementation” and “natively adopted by a vendor” are different statuses.
Current evidence
| Entity / project | Status | Evidence |
|---|---|---|
| HarnessRouter Community Edition | Verified implementation | Reference server; repository records Full conformance for v2026-08-11. |
| HarnessRouter Cloud | Project-claimed implementation | HarnessRouter states hosted and Community editions expose the UHP contract. |
| Codex backend | Supported by reference implementation | Listed in HarnessRouter CE. |
| Claude Code backend | Supported by reference implementation | Listed in HarnessRouter CE. |
| Hermes backend | Supported by reference implementation | Listed in HarnessRouter CE. |
| Independent non-HarnessRouter UHP server | Not established | No primary evidence confirmed in this review. |
| Native OpenAI UHP support | Not established | No primary vendor announcement confirmed. |
| Native Anthropic UHP support | Not established | No primary vendor announcement confirmed. |
What would upgrade the status?
A vendor-native row becomes “Verified” only when a primary vendor source names UHP directly. An independent implementation row requires a separate server implementation plus reproducible conformance evidence.
Why adoption matters more than launch coverage
UHP's technical design is already concrete enough to implement. The strategic uncertainty is network adoption. A protocol becomes more valuable when clients and servers can switch among independently maintained implementations rather than relying on one project to define both the standard and most deployed behavior.
Last verified
. This is a fast-moving tracker; verify high-stakes implementation decisions against the linked primary sources.