The one-sentence difference
ACP standardizes how an editor/UI-style client talks to an agent process. UHP standardizes how a product hands tasks to a server that runs complete harnesses. They overlap in spirit — one interface instead of many bespoke integrations — but they are not substitutes.
Version status first
- ACP v1 is the protocol's current published line: JSON-RPC 2.0 based, with Rust and TypeScript SDKs at 1.0.0 since 25 June 2026 and libraries listed for Kotlin, Java, Python, Rust and TypeScript.
- ACP v2 is a Draft, announced 20 July 2026 and explicitly published for review and testing — it changes lifecycle semantics (work can continue beyond a user turn), unifies ID-based update/streaming patterns, and extends permission/extension rules. Treat everything v2-specific as draft; do not present it as the production baseline.
- UHP is
2026-08-11, a Draft standard with a runnable 52-check conformance suite (2026.8.11.post1).
Architectural comparison
| Dimension | UHP | ACP |
|---|---|---|
| Primary boundary | Product/client ↔ UHP server ↔ harness | Client/editor/UI ↔ agent |
| Purpose | Drive interchangeable complete harnesses through a server contract | Standardize interactive client↔agent integration: UX, permissions, resources |
| Message model | HTTP resource/task contract + SSE streaming | Bidirectional JSON-RPC 2.0 requests, responses and notifications |
| Transport | HTTP; SSE for streaming | v1: stdio recommended (“SHOULD support whenever possible”); Streamable HTTP is a draft proposal in progress; custom transports allowed. Not stdio-only — remote scenarios are documented, with full remote support acknowledged as work in progress |
| Discovery | GET /v1/uhp discovery document + per-server harness catalog | Initialization/capability negotiation per connection; the public agent registry is ecosystem-level, not a per-server harness catalog |
| Sessions | Server-owned responses/sessions; continuation via previous_response_id | session/new/session/load; session-scoped methods and updates |
| Tool/resource boundary | Harness executes inside the server-controlled runtime/workspace; UHP exposes results, files, events | Client may expose filesystem, terminal, permissions and other capabilities to the agent |
| Cancellation | Response/session cancellation endpoints | session/cancel / request cancellation notifications |
| Substitution goal | Client need not know which harness runs or how the server executes it | Client works with any ACP-capable agent without agent-specific UI integration |
| Maturity snapshot (23 Aug 2026) | Draft standard; two verified independent clients; conformance-defined server claims | v1 stable line with a broad registry/client ecosystem; v2 Draft evolving separately |
What each side does not claim
Because those boundaries differ, the protocols can conceptually coexist — for example, an editor could speak ACP to an interactive agent while a product backend speaks UHP to a harness server. No specific UHP implementation is claimed here to use ACP internally; that would require direct primary evidence from the implementation itself.
Adapters are not vendor adoption
ACP's agent listings include Codex CLI via Zed's adapter and Claude Agent via an SDK adapter. Adapter availability demonstrates ecosystem demand; it does not mean OpenAI or Anthropic adopted ACP natively. The same rule this guide applies to UHP integrations applies to ACP adapters.
A concrete coexistence example
SuperQode is useful precisely because it operates on both sides of this line: it ships ACP-facing workflows for interactive use and a verified UHP client transport for driving UHP servers. That makes it an implementation example — not a substitute for the primary definitions from the two protocol projects, which govern what each protocol actually is.
Related pages
Compare further: UHP vs MCP, UHP vs A2A, UHP vs model APIs, and UHP architecture for the Client/Server/Harness roles referenced throughout this page.