Skip to content
UHPUHPDeveloper Guide
Independent developer guide. Not affiliated with HarnessRouter or the official UHP project.

UHP vs ACP: choose the client-to-agent boundary

Choose UHP when a product needs one execution API for complete harnesses. Choose Agent Client Protocol when a client such as an editor needs an interactive contract with an agent. A system can use both at different boundaries.

Page reviewed 4 Oct 2026 Source and review policy

Current guidance and dated source history

Make a bridge preserve the client service contract

Section titled “Make a bridge preserve the client service contract”

ACP’s current protocol overview separates agent methods from client services. Its repository versioning rules still identify stable wire version 1, independently of SDK/schema releases. These sources and UHP 2026-09-28 Draft were reopened 4 October 2026.

Bridge interactionRequired design decisionFailure to test
Agent asks for permissionWhich principal/policy answers, and how is the answer delivered?Disconnected client silently treated as approval
Agent asks to read or write a fileWhether the bridge or remote agent owns the workspaceLocal editor path accidentally applied to server storage
Prompt emits updates and tool progressHow updates map to outer events and terminal stateUI finishes while backend work continues
Prompt/session is cancelledHow cancellation reaches the actual executing agentOuter acknowledgement mistaken for stopped work

Start with a synthetic denied permission and a missing client filesystem capability. The bridge must preserve those failures rather than fabricating successful tool results. Then disconnect the client during a prompt and verify which component retains the session and can establish its outcome. These are suggested adapter tests, not results reproduced here.

Use UHP lifecycle to define outer execution ownership and Agent Host Protocol when several clients need synchronized host state. ACP’s existence does not automatically supply either hosted durability or a UHP translation.

For a web application’s agent event stream, compare AG-UI’s application-facing contract separately from ACP’s editor/agent services. Displaying a streamed update does not establish ownership of the remote harness, its workspace or its terminal result.

Make the architectural choice first

Section titled “Make the architectural choice first”

Here ACP means Agent Client Protocol, not another protocol sharing those initials. This comparison uses UHP 2026-09-28 Draft and ACP stable wire version 1. The ACP repository’s schema-v1.24.1 release is a schema-artifact version, not ACP wire version 1.24.1. Its current README explicitly separates these coordinates.

DecisionUHP execution boundaryACP editor/agent boundary
Client ownsProduct workflow and choice of a configured harnessInteractive client experience and supported client services
Server/agent ownsRunning the complete harness behind the serverAgent execution while communicating with the client
TransportHTTP API with streaming task outputJSON-RPC; standard local integration uses stdin/stdout
Session lifecycleResponse/task execution and continuation through UHP session semanticsAgent sessions and prompt/update lifecycle
CapabilitiesDiscover server class and optional featuresNegotiate protocol version and client/agent capabilities
Tools and permissionsHarness configuration and implementation enforcement; request-level reserved fields are not grantsExplicit client/agent permission and service interactions
Deployment questionWhich server controls execution and durable artifacts?Which client launches/connects to the agent and handles interaction?

The authoritative contracts are the UHP versioned specification and ACP protocol documentation. Optional features must be checked independently; a protocol version alone does not guarantee them.

When the layers compose

Section titled “When the layers compose”
Product / service
       │ UHP: submit and observe complete-harness work
       ▼
UHP server + harness adapter
       │ possible ACP connection (implementation required)
       ▼
ACP agent
       │ agent-owned tool/model interactions
       ▼
Workspace / tools / model provider

This is a conceptual composition, not a claim that an arbitrary UHP-to-ACP bridge is implemented. A bridge must map identities, session continuation, cancellation, terminal results, permission requests, file access and failures. Dropping permission interactions or treating an ACP session ID as a UHP response ID is not a valid translation.

Questions to settle before implementing

Section titled “Questions to settle before implementing”
  • Does your client need to render and answer agent permission requests, or does a hosted server own that policy?
  • Who retains workspace files and session history after the client disconnects?
  • Which concrete operations are required, and which capabilities advertise them?
  • Can cancellation be acknowledged before backend work actually stops? How will you establish terminal state?
  • Are you validating one adapter/version pair, or assuming portability across every registered agent?

Start with UHP lifecycle for an execution client and ACP’s official SDK examples for an ACP client. Qwen Live illustrates a concrete ACP-consuming composition system; UHP vs AHP explains the separate synchronized-host-state boundary.

The following source diary retains ACP v2 Draft and preview-feature evidence at its original dates. It is not a claim that those features are stable in every current ACP implementation.

Historical source notes — baseline reviewed 19 Sep 2026

The following evidence preserves the earlier review and its links. “Current”, “stable” and “main” inside this section refer to that historical cutoff; they are not new release or compatibility claims. Use the guidance above for the current scope.

The one-sentence difference

Section titled “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

Section titled “Version status first”
  • ACP v1 remains the protocol’s current stable published line: JSON-RPC 2.0 based, with libraries/SDKs across multiple languages. The original Rust and TypeScript SDK 1.0.0 releases on 25 June 2026 were milestone releases, not the current SDK versions.
  • Current official SDK evidence has moved beyond that milestone: the dedicated Rust SDK is now v2.2.0 (18 September 2026) and the TypeScript SDK is v1.4.0 (20 August 2026). Rust v2.2.0 pins agent-client-protocol-schema 1.9.1, carries the stabilized Tool Call Name surface, preserves already-captured subprocess stderr when a bounded shutdown drain times out, and adds opt-in JavaScript-hosted wasm32-unknown-unknown support. These are SDK/runtime compatibility and portability changes, not evidence that ACP v2 became stable. The Rust v2.0.0 release remains the provenance for the major-version boundary: its breaking changes were SDK/API changes while the stable ACP v1 wire schema remained unchanged.
  • ACP v2 is still a Draft. The protocol project now publishes prerelease schema-v2.0.0-alpha.5 (18 September 2026). PR #2175 makes the v2 session/prompt response an insertion receipt with a required non-null messageId: success means the user message has been inserted into the ACP conversation, not merely received/queued and not fully processed. V1 remains unchanged, and publication of another v2 alpha must not be mistaken for ACP v2 becoming stable.
  • ACP Tool Call Name is now stable in the current v1 schema baseline and present in the v2 schema baseline. PR #2166 merged on 17 September 2026, completed the RFD, promoted optional name into the v1/v2 schema sources and removed the unstable_tool_call_name feature gate. The field remains opaque programmatic metadata with no naming-registry, execution or authorization semantics. In v1, name may be supplied on creation or updated later to another non-null string; omission or null in a v1 update leaves the existing name unchanged, so v1 cannot explicitly clear a previously reported name. V2 uses explicit null to clear the field under v2 semantics, while v2 itself remains opt-in/Draft. Release PR #2122 merged on 17 September 2026 and published the corresponding versioned artifacts: agent-client-protocol-schema v1.8.0, stable v1 schema schema-v1.22.0, and Draft-v2 prerelease schema-v2.0.0-alpha.4. claude-agent-acp v0.78.0 and codex-acp v1.12.0 had already shipped compatible implementation evidence while the RFD was Preview.
  • ACP Session Compaction is now Preview but remains unstable. PR #2215 moved the RFD from Draft to Preview on 23 September 2026 after the protocol implementation had already landed in PR #2002. The feature remains behind unstable_session_compaction, is excluded from the stable schemas and therefore is still not stable ACP-v1 behavior. It adds ID-addressed compaction_update and compaction_summary_chunk session updates for v1 and v2 so clients can represent compaction lifecycle and an optional retained user-displayable summary. V1 requires clientCapabilities.session.compaction; v2 adds no capability. claude-agent-acp stable v0.78.0, published 15 September, includes the experimental implementation first shipped through the v0.77.1-preview.* line; later adapter distributions retain the feature. Preview means the proposal is implemented enough for broader interoperability validation, not that the wire contract has stabilized.
  • ACP Session Notices moved to Preview on 24 September 2026 but remain unstable rather than stable-v1 semantics. PR #2221 promoted the RFD from Draft to Preview after the protocol surface and v1 runtime implementations had landed; the feature remains behind unstable_session_notices and excluded from stable schemas. Published schema-v1.23.0 carries PR #2171’s v1 presentation capability in its unstable schema surface: a v1 Agent MUST send notices only when the Client advertises clientCapabilities.session.notices: {}; omitted or null means unsupported. V2 remains capability-free. A notice is a live fire-and-forget session/update advisory with required severity and title, optional description/_meta, no acknowledgement or lifecycle, and no replay guarantee. The stable schema-v1.23.0/schema.json bytes are unchanged from schema-v1.22.0 (the same SHA-256 digest), so the 18 September release does not promote notices into stable ACP-v1 semantics. The Session Notices release train first shipped this boundary in protocol-repository crate v1.9.0; current crate v1.9.1 leaves the generated schemas and main protocol docs unchanged while adding Rust-only compatibility for explicit JSON null on audited defaultable payloads.
  • ACP v2 prompt insertion now has an explicit message-identity receipt in alpha.5. PR #2175 requires v2 PromptResponse.messageId and requires corresponding live user-message updates to use that returned ID while allowing either response/update delivery order. The receipt establishes insertion identity, not completion, archival retention, retry safety, queueing/steering or cancellation semantics. This is unstable-v2 behavior only; stable ACP v1 and UHP are unchanged.
  • ACP protocol-repository crate v1.9.1 is an implementation-compatibility patch, not a wire-version change. PR #2178 allows explicit JSON null to deserialize to the Rust default for 32 audited request/response payloads (19 v1 and 13 v2) whose defaults contain only absent optional data. It preserves ordinary non-null decoding, metadata, optional/patch wrappers, raw extension/MCP result values, serialized output, generated JSON Schema and the main protocol docs; a JSON-RPC response still requires the result key even where result: null is accepted. The patch therefore improves interoperability with existing clients that followed older empty-response examples without changing stable ACP-v1 or Draft-v2 schema semantics.
  • Native ACP subagent sessions are also still draft/unstable work rather than stable-v1 semantics. Open ACP core PR #1992 adds negotiated child-session capabilities and lifecycle updates but remains open, marks them UNSTABLE and explicitly says they are not part of the specification yet. Adapter implementations are shipping ahead of standardization: codex-acp v1.7.0 introduced the draft model, v1.9.0 added an ACP authStatus extension, v1.10.0 added JetBrains AIR’s capability-negotiated asyncTasks surface, v1.11.0 added opt-in AIR recommendedValue metadata, finalized standalone MCP elicitation permission handling and paginated thread history during session fork/load, and current v1.12.0 retains those surfaces while adding Tool Call Name, improved request_user_input elicitation, turn-derived file-change/diff reporting and a Codex 0.154.0 update. claude-agent-acp v0.71.0 shipped its compatible native-subagent plus AIR asyncTasks implementation, v0.75.0 added authStatus, usage statistics and context-compaction lifecycle, v0.75.1 repaired persisted fork restoration/session loading, v0.76.0 added opt-in AIR recommendedValue model/effort recommendations, v0.77.0 added Tool Call Name, and stable v0.78.0 retained those surfaces while adding the experimental ACP Session Compaction updates, checkpoint-derived file-change reporting and AIR diff counts. The 19 September matrix directly probes later claude-acp 0.79.0 and codex-acp 1.12.0. None of these adapter-level surfaces makes recommended config values, async tasks, subagent sessions or Session Compaction part of stable ACP v1; Tool Call Name is separately stable in the current v1 protocol-source baseline after PR #2166.
  • OpenCode, Harn, Qwen Code, CodeBuddy Code, Factory Droid, Cline, Cursor, DeepSeek Harness, GitHub Copilot CLI, Gemini CLI, Grok Build, Goose, Google Antigravity and MiniMax Code are verified native ACP agent implementations. The official 19 September 2026 protocol matrix, generated at 09:33:55 UTC, directly probes all 34 registry agents in that run with zero reused unchanged-version results; 33 initialize successfully. OpenCode 1.18.31 initializes successfully with terminal authentication and advertises loadSession, session/list, session/fork and session/resume. Harn 0.10.138 initializes successfully with agent authentication and advertises loadSession, session/list and session/resume. Qwen Code 0.24.0 initializes successfully with agent authentication and advertises the same three session capabilities. CodeBuddy Code 2.155.0 initializes successfully with agent authentication and advertises loadSession. Factory Droid 0.223.0 initializes successfully with agent authentication and advertises loadSession, session/list and session/resume. Cline 3.0.62 initializes successfully with agent authentication and advertises loadSession. Cursor 2026.09.15 initializes successfully with agent authentication and advertises loadSession plus session/list. GitHub Copilot CLI 1.0.86 initializes successfully with terminal authentication and advertises loadSession plus session/list. Gemini CLI 0.60.0, Grok Build 1.0.38, Goose 1.51.0 and Google Antigravity 1.1.1 also initialize successfully at their exact matrix versions; Grok advertises loadSession, session/list and session/resume. MiniMax Code 0.2.7 directly initializes successfully with terminal authentication and advertises loadSession, session/list, session/fork and session/resume. The same run directly probes claude-acp 0.79.0 and codex-acp 1.12.0, both successfully advertising loadSession, session/list, session/fork and session/resume. DeepSeek Harness separately retains the first-party @deepseek-ai/dsh-acp / dsh --profile acp automation server introduced in v0.1.2-rc.1. These native implementations differ from adapter projects such as codex-acp and claude-agent-acp: the ACP endpoints are implemented or distributed by the upstream projects themselves. The matrix remains version-bounded rather than a promise about later releases.
  • UHP is 2026-09-12, a Draft standard whose current conformance source contains 75 checks while the suite package remains 2026.9.12. HarnessRouter v0.18.2 / PR #210 added Extended check X-09 for standalone file upload followed by task use, raising the source denominator from 74 to 75. Current HarnessRouter stable is v0.19.0 / ccf4af66, and checked current main is 387ad841. The latest checked-in Full reference measurements remain the earlier 74/74 artifacts from the pre-X-09 suite: PR #177 regenerated the recorded-run block from a live remeasurement, PR #178 checked in a timestamped CE 0.17.2 structured report, and PR #175 separately recorded 74/74 twice during release/adversarial verification. Those results remain valid historical measurements but are not 75/75 evidence. These are UHP/HarnessRouter facts, not ACP conformance and not proof of every backend-specific transport path.

Architectural comparison

Section titled “Architectural comparison”
DimensionUHPACP
Primary boundaryProduct/client ↔ UHP server ↔ harnessClient/editor/UI ↔ agent
PurposeDrive interchangeable complete harnesses through a server contractStandardize interactive client↔agent integration: UX, permissions, resources
Message modelHTTP resource/task contract + SSE streamingBidirectional JSON-RPC 2.0 requests, responses and notifications
TransportHTTP; SSE for streamingv1: 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
DiscoveryGET /v1/uhp discovery document + per-server harness catalogInitialization/capability negotiation per connection; the public agent registry is ecosystem-level, not a per-server harness catalog
SessionsServer-owned responses/sessions; continuation via previous_response_idsession/new/session/load; session-scoped methods and updates; Preview/unstable work includes ID-addressed compaction lifecycle/summary updates and non-durable advisory Session Notices, while draft work includes negotiated child sessions; none of those surfaces is stable ACP v1
Tool/resource boundaryHarness executes inside the server-controlled runtime/workspace; UHP exposes results, files, eventsClient may expose filesystem, terminal, permissions and other capabilities to the agent
CancellationResponse/session cancellation endpointssession/cancel / request cancellation notifications
Substitution goalClient need not know which harness runs or how the server executes itClient works with any ACP-capable agent without agent-specific UI integration
Maturity snapshot (19 Sep ecosystem matrix; Session Compaction status updated 23 Sep; Session Notices status updated 24 Sep 2026)Draft standard; independent client implementations tracked separately; current 2026.9.12 source defines 75 checks after HarnessRouter v0.18.2 / X-09; current HarnessRouter stable is v0.19.0 / ccf4af66 and checked current main is 387ad841, while the checked-in Full reference artifacts remain historical 74/74 measurements from the 74-check suitev1 stable protocol line; Rust SDK v2.2.0, TypeScript SDK v1.4.0; current published stable-v1 bundle is schema-v1.23.0, whose stable schema.json bytes are unchanged from schema-v1.22.0; current protocol-repository crate is v1.9.1, a Rust null-tolerance compatibility patch with unchanged generated schema/docs; current v2 prerelease is schema-v2.0.0-alpha.5; Tool Call Name is stable in published v1; Session Compaction moved to Preview on 23 Sep but remains unstable and excluded from stable schemas; Session Notices moved to Preview on 24 Sep but remain unstable and excluded from stable schemas; v2 alpha.5 adds the unstable prompt-insertion messageId receipt; subagent sessions remain an open unstable RFD despite shipped adapter implementations; OpenCode, Harn, Qwen Code, CodeBuddy Code, Factory Droid, Cline, Cursor, DeepSeek Harness, GitHub Copilot CLI, Gemini CLI, Grok Build, Goose, Google Antigravity and MiniMax Code are native ACP agent implementations; the 19 Sep matrix probes 34 registry agents with 33 successful initialization results and directly measures Harn 0.10.138, Qwen Code 0.24.0, CodeBuddy Code 2.155.0, claude-acp 0.79.0, codex-acp 1.12.0, Factory Droid 0.223.0, Cline 3.0.62, Cursor 2026.09.15, GitHub Copilot CLI 1.0.86, Gemini CLI 0.60.0, Grok Build 1.0.38 and MiniMax Code 0.2.7

Client-side portability evidence: acpx v0.15.0

Section titled “Client-side portability evidence: acpx v0.15.0”

OpenClaw’s acpx is independent implementation evidence for the ACP client side, not a new ACP protocol version and not a UHP client. Tagged v0.15.0, published 7 September 2026 at 10:59:45 UTC, it is a headless ACP client/runtime that puts persistent sessions, one-shot execution, permission handling, machine-readable output and embeddable flows behind one control surface.

The tagged built-in registry contains 22 friendly agent profiles. That registry deliberately mixes adapter commands such as @agentclientprotocol/codex-acp and @agentclientprotocol/claude-agent-acp with direct ACP entrypoints such as gemini --acp, qwen --acp, grok agent stdio and mcode acp. A built-in acpx profile therefore establishes that acpx knows how to launch that ACP path; it is not by itself proof of vendor-native ACP adoption. Native/adapter attribution still has to come from the upstream implementation evidence documented elsewhere on this page.

v0.15.0 also hardens the embedding boundary: hosts can apply awaited process-launch admission hooks, use child-only environment overlays for probes and reconnects, retain opaque ACP prompt-response metadata, and opt into size bounds for shell capture, raw ACP messages and queued requests. The release also adds MiniMax Code through its native mcode acp server. These are acpx runtime/client semantics, not stable ACP-v1 wire changes.

Architecturally, acpx is a concrete example of client-side ACP substitution: surrounding automation can keep one client/runtime surface while changing the ACP agent or adapter behind it. UHP solves a different substitution boundary: a client addresses a UHP server that owns execution/session/workspace semantics and selects a configured complete harness. No UHP integration is claimed by acpx at this cutoff.

ACP registry preview channels are distribution channels, not protocol releases

Section titled “ACP registry preview channels are distribution channels, not protocol releases”

On 10 September 2026, ACP registry PR #573 added an opt-in JetBrains preview channel and a third self-contained index, registry-for-jetbrains-preview.json. A registry manifest may now declare a preview block containing exactly version and distribution; the registry format restricts preview distributions to npx and uvx, while the stable root version remains a plain X.Y.Z release.

The preview index is a complete replacement for the ordinary JetBrains index rather than a delta that clients merge. Agents without a preview block appear at stable; for preview-enabled agents, the registry resolves the newer of stable and preview so stale preview metadata cannot downgrade a client. When the channel was introduced earlier on 10 September, codex-acp and claude-acp preview blocks trailed stable (1.10.1-preview.1 versus 1.11.0, and 0.75.2-preview.1 versus 0.76.0). Registry update 797d2030 at 16:47:37 UTC synchronized those preview coordinates to 1.11.0 and 0.76.0 at that moment. Registry update ccf428a3 at 22:07:40 UTC then advanced only the claude-acp preview to 0.76.1-preview.1. Those are now historical channel coordinates.

On 14 September 2026, stable claude-agent-acp v0.77.0 incorporated the earlier main-thread Agent-selector removal as a breaking stable change and added programmatic tool names to ACP tool calls. The registry subsequently advanced Claude’s preview line through 0.77.1-preview.*, where PR #1134 first exposed experimental Session Compaction.

On 15 September 2026, the adapter distributions advanced again. Stable claude-agent-acp v0.78.0 includes the experimental Session Compaction implementation plus checkpoint-derived file-change reporting and AIR diff counts. Stable codex-acp v1.12.0 adds Tool Call Name, improved request_user_input elicitation, turn-derived file-change/diff reporting and Codex 0.154.0. Official registry commit 91e35777 moved both Claude stable and preview to 0.78.0; current registry commit 09c2707f moved both Codex stable and preview to 1.12.0. The 19 September matrix directly probes claude-acp 0.79.0 and codex-acp 1.12.0; the matrix coordinate remains separate from channel-resolution metadata.

Crucially, the preview channel is deliberately unverified. Registry verification does not launch or auth-check preview distributions, probe their URLs, or include them in the protocol matrix; only offline schema/version consistency checks apply. The 19 September 09:33:55 UTC matrix directly probes stable/distributed coordinates including claude-acp 0.79.0, codex-acp 1.12.0, Grok Build 1.0.38, Dirac 0.5.13, Kilo 7.7.5 and siGit 1.5.10; preview distributions remain outside that matrix. Those direct matrix results are version-bounded and are not silently upgraded by later registry changes. This registry/client distribution feature does not advance ACP v1 or v2 wire maturity, create protocol conformance, change UHP 2026-09-12, or establish a UHP↔ACP binding.

SDK version numbers are not protocol version numbers

Section titled “SDK version numbers are not protocol version numbers”

ACP currently has three independent version surfaces that are easy to conflate:

  1. Protocol line: ACP v1 remains the stable wire protocol; ACP v2 remains Draft.
  2. Schema artifacts: stable v1 schemas evolve independently, while the v2 schema is currently published as a prerelease alpha.
  3. SDK/package semver: an SDK may take a major release for API or transport-boundary changes without changing the stable wire protocol.

The current official Rust SDK is v2.2.0. Its v2.0.0 major release remains the clearest versioning example: it explicitly states that version 2.0 keeps the stable ACP v1 wire schema unchanged while making coordinated breaking changes to Rust SDK APIs and its low-level transport boundary. Current v2.2.0 advances SDK implementation and portability without promoting ACP v2: the tagged release pins agent-client-protocol-schema 1.9.1, carries stabilized Tool Call Name, preserves captured subprocess stderr when bounded shutdown draining times out, and adds opt-in JavaScript-hosted WebAssembly support; draft v2 still requires unstable_protocol_v2. The TypeScript SDK v1.4.0 likewise includes stable-v1 work plus fixes around opt-in draft-v2 behavior. Therefore, “Rust SDK 2.x” is not evidence that ACP v2 became stable.

Stable tool-call names separate programmatic identity from UI copy

Section titled “Stable tool-call names separate programmatic identity from UI copy”

The Tool Call Name RFD moved from Preview to Completed on 17 September 2026 in PR #2166. ACP now exposes optional name directly in the current v1 and v2 schema sources and removes the unstable_tool_call_name gate. This makes Tool Call Name stable v1 protocol metadata; its v2 copy remains inside the still-Draft, opt-in v2 line. Release PR #2122 merged later on 17 September and published that stabilized field in agent-client-protocol-schema v1.8.0, schema-v1.22.0 and Draft-v2 prerelease schema-v2.0.0-alpha.4.

The field deliberately keeps four identities separate: toolCallId identifies one invocation, name identifies the programmatic tool used, title remains human-readable invocation copy, and kind stays a coarse presentation category such as read or execute. Tool names are opaque strings: ACP defines no naming or namespacing scheme and assigns no behavioral or authorization semantics to the spelling.

For bridges, the cross-version asymmetry is now explicit. V1 permits name both on the initial tool call and in later updates, but omission or null on a v1 update means “leave the existing name unchanged”; there is no wire representation that clears a previously reported v1 name. V2 also permits updates, but its update semantics use explicit null to clear the field. A bridge therefore must preserve the distinction between v1’s omit/null-as-no-change behavior and v2’s explicit-null clear operation.

claude-agent-acp has provided concrete adapter-side implementation evidence since stable v0.77.0; later releases retain it. Current stable codex-acp v1.12.0 also supplies the programmatic tool-name surface. Those implementations preceded protocol stabilization and now align with the current stable v1 field, but remain adapter interoperability evidence rather than UHP behavior or vendor-native adoption by the underlying model providers.

For UHP comparison, this is ACP presentation/observability metadata at the client↔agent boundary. It does not alter UHP tool execution, create a UHP↔ACP binding, standardize cross-harness tool naming or make a displayed ACP name an authorization identity.

Preview Session Compaction remains unstable

Section titled “Preview Session Compaction remains unstable”

ACP’s Session Compaction RFD moved from Draft to Preview on 23 September 2026 in PR #2215. The protocol implementation had already landed in PR #2002, but the feature remains behind unstable_session_compaction and is excluded from the stable schemas. Preview therefore means the proposal is implemented enough for broader agent/client interoperability validation; it does not make Session Compaction stable ACP-v1 semantics.

The feature adds two ID-addressed session updates to v1 and v2: compaction_update creates or patches a compaction entity at a fixed timeline position, while compaction_summary_chunk can append retained user-displayable summary content while compaction is in progress. compactionId is opaque, Agent-owned, unique within the session and not reused; initial status values are in_progress, completed, failed and cancelled, with the status enum intentionally open for future values.

The update keeps lifecycle separate from conversational text. summary, error and _meta use patch semantics; a completed update can carry the authoritative retained summary, while Agents are told to omit summary material when no unencrypted user-displayable form exists or exposing it could reveal otherwise hidden context. For ACP v1, an Agent may send these updates only when the Client advertises clientCapabilities.session.compaction; v2 adds no equivalent capability.

Preview validation still has real work left. The RFD calls for agent/client integration checks around v1 capability enforcement, lifecycle transitions, summary chunk ordering/replacement/clearing, replay with stable compaction IDs and timeline placement, unknown future statuses and v2 updates. Four existing schema tests exercise the wire representation, but they are not end-to-end interoperability evidence for those runtime behaviors.

claude-agent-acp PR #1134, merged on 14 September, first exposed experimental support through the v0.77.1-preview.* line. Stable v0.78.0, published 15 September, contains the same merge commit and explicitly lists experimental ACP compaction support as a feature. Later adapter distributions retain the behavior. This is stable-distribution implementation evidence around a Preview/unstable RFD, not stable ACP-v1 behavior and not a UHP session/compaction primitive.

Preview session notices separate advisory UI from durable history

Section titled “Preview session notices separate advisory UI from durable history”

ACP’s Session Notices RFD defines a deliberately small live-only primitive for operational information that should be visible without pretending it is part of the conversation. PR #2221, merged on 24 September 2026 as 5b45096e, moved the RFD from Draft to Preview after the protocol implementation and v1 runtime implementations had landed. Current main and the published schema-v1.23.0 unstable artifact implement the v1 capability-gated schema; v2 remains capability-free. The feature still sits behind unstable_session_notices and is excluded from stable schemas, so Preview does not stabilize the wire contract.

A notice is carried as a session/update variant. severity and a non-empty plain-text title are required; description and _meta are optional. Initial severities are info, warning and error, while the severity enum is open for future values. The Client owns presentation and local dismissal — toast, banner, notification center or another accessible surface — and ACP defines no notice ID, acknowledgement, update, removal or response path.

That absence of lifecycle is intentional. Notices should not be replayed as session history, and an Agent must behave as though a notice may never be received, understood, displayed or seen. A notice therefore cannot carry protocol correctness, required user action, authorization, task completion or fatal-error semantics; those belong in response-bearing or lifecycle primitives. Even severity: "error" is only an advisory presentation hint and does not itself fail a JSON-RPC request, stop foreground work, change session state or imply a prompt stop reason.

Capability semantics differ by protocol line. PR #2171, merged 18 September 2026 as 7a54388c, adds clientCapabilities.session.notices to the unstable v1 schema. A v1 Client advertises support with {}; omission or null means unsupported, and a v1 Agent MUST NOT send SessionUpdate::Notice unless that capability was advertised. If advisory information still needs to reach an unsupported v1 Client, the draft permits an ordinary Agent message as fallback, which is intentionally a different, durable conversational surface. ACP v2 remains capability-free for Session Notices. In either line, support means only that the Client can present notices: it does not acknowledge receipt, display or visibility of any particular notice.

The publication boundary now has two distinct steps. Release PR #2122 merged on 17 September as 9b4c23b9 and published protocol-repository crate v1.8.0, stable-v1 schema-v1.22.0 and Draft-v2 schema-v2.0.0-alpha.4; its changelog still labeled Session Notices unstable. PR #2171 then added the v1 capability gate, and the 18 September release train published it in protocol-repository crate v1.9.0 and schema-v1.23.0’s unstable schema. The stable schema-v1.23.0/schema.json has the same SHA-256 digest as schema-v1.22.0/schema.json (3c17bd6385d90cf672d8a661fddc359d73422cf8b8ce6865213d25cfd4c0eca7). Therefore the release coordinate advanced, but stable ACP-v1 wire bytes did not: Session Notices remain unstable semantics.

A later same-day protocol-repository patch, v1.9.1, does not alter that publication boundary. PR #2178 changes Rust deserialization only: explicit null now maps to Default for 32 audited defaultable request/response payloads (19 v1, 13 v2), while serialized output, generated JSON Schema and the main protocol docs remain unchanged. The result member itself is still required for successful JSON-RPC responses even when result: null is accepted. This is compatibility tolerance for existing clients, not promotion or modification of Session Notices or other ACP wire semantics.

For UHP comparison, this is an ACP client↔agent presentation primitive rather than a UHP session-history or server-durability rule. The architectural lesson is the separation between ephemeral advisory UX and durable/reliable task state; it does not create a UHP-compatible event type or alter UHP’s outer client→server→harness contract.

Draft v2 prompt insertion now returns message identity

Section titled “Draft v2 prompt insertion now returns message identity”

ACP PR #2175, merged on 18 September 2026 as 43451e74, makes the v2 session/prompt response an insertion receipt. A successful v2 PromptResponse now carries required non-null messageId; acceptance means the user message has been inserted into the ACP conversation, not merely received or queued and not fully processed. Corresponding live user-message updates must use that returned ID, but ACP allows the response and update to arrive in either order.

The identity boundary is intentionally narrow. The change does not promise that the inserted message is archived, make retries safe after a lost response, add a client-generated prompt ID, introduce execution IDs, create queueing/steering APIs or change cancellation semantics. If the message is retained and replayed, it keeps the returned ID; history retention itself remains optional. The same release also applies reset-before-chunked-replay consistently to retained user, agent and thought messages to avoid duplicate replay content.

This is unstable-v2 behavior carried by schema-v2.0.0-alpha.5; v1 source/artifacts are unchanged. For UHP comparison, the useful architectural distinction is between admission/insertion identity and execution/completion identity. The new ACP receipt does not create a UHP response ID, task lifecycle state or cross-protocol binding.

Draft subagent sessions are reaching real adapters before standardization

Section titled “Draft subagent sessions are reaching real adapters before standardization”

ACP core PR #1992, “Add subagents RFD,” remains open. Its proposed wire model is capability-negotiated: a client may advertise clientCapabilities.subagents, an agent may advertise agentCapabilities.sessionCapabilities.subagents, and the agent can then announce a child with subagent_spawned, route later child updates on the child’s opaque session ID, and report terminal state with subagent_state_update. The draft types include completed, failed, cancelled and disconnected, plus child-specific cancel/close capability flags.

The maturity label is decisive: the ACP repository marks these fields and updates UNSTABLE, says they are not part of the spec yet, and warns that they may change or disappear. This is therefore evidence of active protocol design, not a stable ACP v1 guarantee.

Two ACP-side adapters now provide useful implementation evidence around the same proposal:

  • codex-acp v1.7.0, released 27 August 2026, introduced negotiated native ACP subagent sessions. It exposes Codex collaborators as independent child-session streams with separate histories, routes child messages/tools/permissions/elicitations to the child session, emits terminal lifecycle updates, reconstructs the child tree during session/load, and falls back to the legacy ordinary tool-call representation when the client does not negotiate the draft capability. v1.9.0, published 4 September, retained that model and added an ACP authStatus extension for reporting the agent’s authentication identity plus more complete usage/limit reporting. v1.10.0, published later on 4 September, retained native subagents and added a separate JetBrains AIR asyncTasks extension for Codex-owned background terminals. A client must advertise asyncTasks in _meta.jetbrains.air.capabilities; only then does the adapter advertise the extension and emit task updates. It maps active background terminals to spawned tasks, maps terminal completion to completed/failed state, restores root and child tasks during session/load, marks vanished announced terminals as stopped, and maps _session/async_task/stop back to Codex’s native background-terminal termination. v1.11.0, published 9 September, retained those behaviors and added the opt-in AIR recommendedValue extension: after client negotiation it advertises Codex’s default selectable model and that model’s supported default reasoning effort separately from the session’s current selection. The same release finalized standalone MCP elicitation permission requests and paginated thread history when forking or loading sessions. Current v1.12.0, published 15 September, retains those behaviors while adding Tool Call Name, improved request_user_input elicitation, turn-diff file-change reporting, validated ACP diff statistics and Codex 0.154.0. These are adapter/AIR/runtime behaviors, not stable ACP v1 recommended-value, async-task or MCP-wire changes; Tool Call Name is separately stable in current ACP v1 source after PR #2166.
  • claude-agent-acp v0.71.0 ships merged PR #1017 / commit 14d192d, which maps Claude Agent/Task lifecycle to the same negotiated child-session shape and separately exposes selected background work through an AIR asyncTasks extension. GitHub published v0.71.0 on 1 September 2026, replacing this guide’s earlier classification of #1017 as merged-but-unreleased behavior. v0.72.0 followed later the same day with Claude Agent SDK, per-model effort and user_message_uuid updates. v0.75.0, published 5 September, retained the subagent/AIR source surfaces and added ACP authStatus identity reporting, Markdown usage statistics and context compaction as an ACP tool lifecycle. v0.75.1, published later on 5 September, fixes persisted session-fork restoration and session loading: fork targets can be resolved from the complete persisted transcript even outside the active parent chain, repeated assistant content and message fingerprints are handled, resumed models are recovered from Claude Code’s local assistant transcript record, and automatic getContextUsage control requests are removed. Upstream’s reproduced 69-message forked-session cold load fell from 20–29 seconds to 1.9 seconds; this is an upstream benchmark for that fixture, not a universal latency guarantee. v0.76.0, published 9 September, added the opt-in AIR recommendedValue capability family and richer model presentation. v0.77.0, published 14 September, retained those prior subagent/AIR/auth-status/usage/fork-loading surfaces, incorporated the main-thread Agent-config removal that first appeared on the preview channel and added programmatic tool names. Stable v0.78.0, published 15 September, retained those surfaces and added experimental ACP Session Compaction, preserved a picked AskUserQuestion option when custom text is supplied, reported file changes from Claude checkpoints and supplied AIR diff counts from structured patches. The 19 September matrix now directly probes claude-acp 0.79.0; its subagent/AIR/auth-status/Session Compaction behavior remains adapter or experimental semantics; Tool Call Name is now separately stable current-v1 protocol metadata.

The official ACP registry matrix directly probes claude-acp 0.79.0 and codex-acp 1.12.0 on 19 September at 09:33:55 UTC. It initializes both measured versions: Claude with terminal authentication and Codex with agent authentication; each advertises loadSession, session/list, session/fork and session/resume. Preview distributions are not included in the matrix. This keeps current distribution coordinates separate from version-bounded direct-probe evidence and from stable ACP-v1 guarantees.

codex-acp’s authStatus extension is also not evidence that stable ACP v1 now standardizes an auth-state method. ACP core’s separate Agent Authentication State Query RFD proposes capability-negotiated auth/status, but that RFD explicitly describes the current status quo as lacking a dedicated auth-state query. Likewise, codex-acp and claude-agent-acp exposing JetBrains AIR async tasks or recommendedValue is adapter-extension evidence, not proof that stable ACP v1 standardizes those extension surfaces.

The convergence is architecturally meaningful because two different harness adapters are mapping their native child-agent behavior toward the same proposed ACP child-session model while separately exposing selected background work and recommended configuration through AIR extension surfaces. It is not evidence that PR #1992 has been accepted, that stable ACP v1 already requires subagent sessions, async tasks or recommended config metadata, or that OpenAI or Anthropic natively adopted ACP. Both projects here are adapters in the ACP ecosystem.

What each side does not claim

Section titled “What each side does not claim”

Because those boundaries differ, the protocols can conceptually coexist — for example, an editor can speak ACP to an interactive agent while a product backend speaks UHP to a harness server. Stable Hermes v0.21.3 retains concrete evidence that ACP can also appear inside a harness runtime as an agent-provider boundary; that path first shipped in v0.20.6, and its presence in the current stable line does not establish that HarnessRouter’s UHP→Hermes adapter uses ACP for any particular UHP task.

Concrete inner-boundary evidence: Hermes ACP agent providers

Section titled “Concrete inner-boundary evidence: Hermes ACP agent providers”

On 26 August 2026, upstream Hermes merged changes that generalize ACP-backed CLIs from a Copilot-specific integration into an agent-as-provider runtime class. Those commits first shipped in v2026.8.27 / Hermes Agent v0.20.6, were rolled into v0.21.0, and remain part of current stable v2026.9.14 / Hermes Agent v0.21.3, published 14 September 2026.

The implementation illustrates how ACP can sit below a parent harness without becoming that harness’s external protocol:

  • Hermes shares one ACP/OpenAI bridge that carries allowed Hermes tool schemas through ACP’s text prompt/response boundary and converts Hermes-level tool requests back into the OpenAI-shaped objects used by the parent loop.
  • Runtime exclusions key on generic acp:// rather than acp://copilot, because ACP-connected CLIs return their own one-shot completion shape and do not implement Hermes’ normal Responses-API/iterable-stream assumptions.
  • An autonomous agent provider can return already-completed tool-call/result rows plus an iteration count. Hermes projects those completed actions into the parent transcript for memory and skill-review visibility without re-running them as pending tools.

This is ACP-mediated harness composition, not UHP↔ACP protocol fusion. HarnessRouter independently supports Hermes as a UHP backend, but no primary evidence reviewed here shows that its UHP adapter invokes Hermes’ ACP provider path. Even if a future UHP-served Hermes task does so, UHP would remain the outer client→server→harness contract and ACP would remain an internal agent/provider boundary.

See harness composition and Hermes for the implementation-level view.

Adapters are not vendor adoption

Section titled “Adapters are not vendor adoption”

ACP’s agent listings include adapter-based routes into products such as Codex CLI and Claude Agent. The native child-session behavior first shipped in codex-acp v1.7.0 and claude-agent-acp v0.71.0; current codex-acp v1.12.0 retains the native-subagent, AIR async-task and negotiated recommendedValue surfaces while adding Tool Call Name, improved user-input elicitation and richer file/diff reporting. The 19 September matrix directly probes claude-acp 0.79.0, whose lineage retains the subagent/AIR/auth-status/usage/persisted-fork/session-load and Tool Call Name surfaces and the experimental Session Compaction behavior first documented in stable v0.78.0. Adapter extensions still do not become stable ACP v1 merely by shipping. None of this means OpenAI or Anthropic adopted ACP natively. The same rule this guide applies to UHP integrations applies to ACP adapters.

OpenCode is one native counterexample: its own upstream repository implements and documents opencode acp, and the official ACP registry lists the upstream agent directly. Harn is another. Tagged Harn v0.10.128, published 3 September 2026, added typed durable control events for accepted stop/steer/interrupt/queued-note actions and hardened MCP tasks with authenticated-principal binding, cancellation ownership, expiry and a retained-record cap. v0.10.129, published 4 September 2026, retained the first-party harn serve acp backend over stdio or WebSocket and fixed a served-session policy regression where ACP/Agents-API sessions in ask mode could fail before the first model call because Harn’s own session bookkeeping was misclassified as a workspace mutation. v0.10.130, published 5 September, was the next registry distribution. v0.10.131, published 6 September, added an opt-in typed task_complete tool whose completion claim names each requirement and cites recorded tool calls; Harn rejects fabricated, self-referential, incomplete and ambiguous claims before invoking its completion judge, and completion-judge gaps can be attributed to exact acceptance-row ids. It also fixes a feedback-integrity bug where the judge could read its own prior veto back as evidence. v0.10.132, published 7 September, added a SQLite workspace cache with fallback, backend writer/maintenance leases for cleanup correctness, MCP lazy-server/credential-preparation refinements and outcome/retry metadata, while removing the obsolete artifactVersion field from Harnfile/harnlock and generated protocol bindings. v0.10.133, published 7 September 2026 at 23:41:15 UTC, is historical direct-probe evidence from the 9 September matrix. v0.10.134, published 9 September, is historical direct-probe evidence from the 12 September matrix. v0.10.135, published 12 September, is historical 14 September matrix evidence. The 19 September matrix directly probes current measured Harn 0.10.138: initialization succeeds with agent authentication and advertises loadSession, session/list and session/resume. Harn also exposes MCP client/server/control-plane surfaces and an A2A server/orchestrator. These are Harn runtime/protocol-surface semantics, not UHP behavior.

Qwen Code is also a first-party native ACP implementation. Tagged v0.23.0, published 3 September 2026, documents direct editor integration through the ACP registry and a manual qwen --acp process. The official registry now distributes 0.24.1 through @qwen-code/qwen-code@0.24.1 --acp --experimental-skills after registry commit 9bd27065 on 19 September 2026 at 09:59:26 UTC. The 19 September 09:33:55 UTC protocol matrix directly probes 0.24.0: initialization succeeds with agent authentication and advertises loadSession, session/list and session/resume. Upstream stable is now v0.24.1, published 19 September 2026 at 08:18:42 UTC; the later registry/stable coordinate does not retroactively change the matrix’s direct-probe version. v0.24.0 carries Qwen host/runtime changes including budget-based ACP child admission, idle-child reclamation when admission is full, a session-scoped ACP permission queue and stable background-execution ownership. v0.24.1 promotes additional host/runtime work including Browser Use. Post-v0.24.1 current main separately carries the fail-closed workspace-trust admission change documented on workspace trust. Those are Qwen host semantics, not new stable ACP-v1 wire behavior. The earlier v0.23.3 internal composition path that delegates a Qwen subagent turn to an external agent over ACP, registers daemon-managed ACP sessions in Qwen’s own session registry and forwards shell execution settings remains inherited by the later stable line. HarnessRouter separately exposes Qwen Code through its UHP backend using CLI stream-json/resume; no primary source reviewed here shows that UHP path invoking Qwen’s ACP mode or revalidates the adapter against Qwen v0.24.1. See UHP and Qwen Code.

CodeBuddy Code is another first-party native ACP implementation. Tencent Cloud’s official CodeBuddy documentation states that CodeBuddy Code natively supports ACP and starts its agent server with codebuddy --acp. The vendor documents client-proxied filesystem/terminal operations plus CodeBuddy-specific ACP extensions for authentication metadata, command updates, context-window configuration and Agent Teams/multitask coordination; those extensions are product behavior layered on ACP rather than additions to stable ACP v1 itself. The 19 September matrix directly probes 2.155.0: initialization succeeds with agent authentication and advertises loadSession. No HarnessRouter CodeBuddy backend or native CodeBuddy UHP implementation was verified.

Factory Droid is another first-party native ACP implementation. Factory’s own repository explicitly advertises ACP support for JetBrains IDEs and Zed. The 19 September matrix directly probes Factory Droid 0.223.0: initialization succeeds with agent authentication and advertises loadSession, session/list and session/resume. No HarnessRouter Factory Droid backend or native Factory Droid UHP implementation was verified.

Cline is another first-party native example. Tagged Cline CLI 3.0.60 directly documents cline --acp: an ACP client launches the Cline process and talks to it over stdio. The tagged surface exposes client-driven sign-in, Plan/Act modes, model/provider selection, permission prompts, session loading, images and organization switching. The 19 September matrix directly probes 3.0.62: initialization succeeds with agent authentication and advertises loadSession. This is especially useful for distinguishing protocol surfaces because HarnessRouter also ships Cline as a UHP backend, but its released adapter invokes Cline through --json, not --acp. HarnessRouter’s measured --json headless-resume limitation therefore does not contradict Cline’s separately documented ACP session-loading behavior. See UHP and Cline.

Cursor is another first-party native ACP implementation. Cursor’s current CLI documentation tells custom clients to launch agent acp, communicate over stdio using newline-delimited JSON-RPC 2.0, authenticate with the advertised cursor_login method, create or load sessions, stream session/update notifications, answer session/request_permission, and optionally cancel a session. The same documentation exposes Cursor-specific ACP extension methods and confirms that project/user .cursor/mcp.json servers can remain available inside ACP mode. Cursor’s 4 March 2026 JetBrains announcement independently describes Cursor ACP as the path for running Cursor’s own agent in JetBrains IDEs and directs users to install it from the ACP Registry.

The 19 September protocol matrix directly probes Cursor 2026.09.15: initialization succeeds with agent authentication and advertises loadSession plus session/list. No HarnessRouter Cursor backend or native Cursor UHP implementation was verified.

DeepSeek Harness is another first-party native example. Current upstream prerelease v0.1.6-alpha.1, published 15 September 2026, retains @deepseek-ai/dsh-acp; pnpm dsh --profile acp starts the upstream JSON-RPC/stdio ACP server. The ACP surface was introduced in v0.1.2-rc.1. The v0.1.6-alpha.1 package documentation still describes stable ACP v1 automation with persistent session/new, session/list, session/resume and session/close, stdio/Streamable HTTP MCP attachment, model and reasoning-effort configuration, prompts, cancellation, semantic updates and permission requests. It intentionally omits session/load, deletion, forks, transcript replay, additional directories and DSH-specific interactive presentation. HarnessRouter separately adapts dsh behind UHP and still pins 0.1.2rc1; no primary evidence reviewed here shows that its UHP→dsh path invokes dsh-acp. See UHP and DeepSeek Harness.

GitHub Copilot CLI is another first-party native example, with ACP still in public preview. GitHub’s current ACP server reference tells clients to launch copilot --acp; stdio is the default transport and --port enables a TCP server. Both transports carry ACP JSON-RPC messages as newline-delimited JSON. GitHub’s 28 January 2026 announcement labels the feature public preview rather than generally available. The 19 September protocol matrix directly probes 1.0.86; initialization succeeds with terminal authentication and advertises loadSession plus session/list. Copilot CLI’s MCP and richer ACP delivery work remain first-party Copilot interoperability surfaces, not UHP adoption. HarnessRouter stable v0.19.0 has thirteen released backends and contains no Copilot backend.

Gemini CLI is another first-party native example. Google’s ACP mode documents gemini --acp as an ACP-compatible agent process that serves JSON-RPC 2.0 over stdio to IDE/developer-tool clients. Its ACP initialization path can accept connection details for an MCP server exposed by the client; Gemini CLI then connects to that MCP server, discovers its tools and makes them available to the model. The 19 September matrix directly probes 0.60.0, successfully initializes with agent authentication and advertises loadSession. This is first-party ACP hosting plus MCP-client composition inside Gemini CLI, not an ACP adapter around Gemini and not evidence that MCP and ACP are the same protocol. HarnessRouter separately ships Gemini CLI as its ninth UHP backend from v0.13.24; that adapter fact does not make Gemini CLI a native UHP implementation.

Goose is another first-party native example. Goose’s upstream ACP architecture describes ACP as the default interface to Goose and explains that terminal, desktop and third-party clients converge on that server. The 19 September protocol matrix directly probes 1.51.0: initialization succeeds with agent authentication and advertises loadSession plus session/list. HarnessRouter stable v0.19.0 still ships Goose, introduced as its eleventh UHP backend; that adapter support does not make Goose a native UHP implementation.

Google Antigravity is another first-party native example. The official ACP registry’s current antigravity-acp manifest pins version 1.1.1, identifies Google LLC as the author, points to Google’s Antigravity documentation, and distributes agy_acp_server binaries for macOS, Linux and Windows from dl.google.com. The registry entry itself was added as “Google Antigravity” with live ACP handshake/auth verification, and Google’s Zed integration guide directs users to install Antigravity through Zed’s External Agents registry. The 19 September ACP matrix directly probes 1.1.1: initialization succeeds with agent authentication and loadSession, session/list and session/resume. This is first-party Google ACP/IDE integration evidence, not native Antigravity UHP adoption and not a HarnessRouter backend.

Grok Build is another first-party native example. SpaceXAI’s public Grok Build repository describes the agent as usable interactively, headlessly or embedded in editors through ACP. Its first-party Agent Mode guide exposes grok agent --always-approve stdio for local JSON-RPC ACP clients and grok agent --always-approve serve for a self-hosted WebSocket server, with ACP session create/load/resume, prompts, streamed message/thought/tool updates and permission requests. Grok also layers discoverable SpaceXAI-specific x.ai/* methods over the base protocol for filesystem, Git/worktree, search, terminal, session/history, authentication and telemetry surfaces. The 19 September matrix directly probes 1.0.38, where initialization succeeds with agent authentication and advertises loadSession, session/list and session/resume.

MiniMax Code is now another first-party native ACP implementation. On 12 September 2026 at 18:02:13 UTC, official ACP registry commit e6ee4459 added MiniMax Code 0.2.7, identifies MiniMax as the author, and distributes @minimax-ai/code@0.2.7 with the acp argument. ACP core PR #2152 then added the same agent to the protocol project’s official agent documentation. The 19 September 09:33:55 UTC matrix directly probes 0.2.7: initialization succeeds with terminal authentication and advertises loadSession, session/list, session/fork and session/resume. This is official registry plus direct-probe evidence, not a stable ACP wire change, native UHP adoption or a HarnessRouter backend.

ACP registry sync #2083, merged 1 September 2026, and earlier daily matrices remain historical version evidence. The 19 September 09:33:55 UTC matrix supersedes the 14 September direct-probe snapshot: it re-probes all 34 registry agents with no reused unchanged-version results, directly measuring that run’s coordinates including OpenCode 1.18.31, Harn 0.10.138, Sigit 1.5.10, Qwen Code 0.24.0, CodeBuddy Code 2.155.0, Factory Droid 0.223.0, Cline 3.0.62, Cursor 2026.09.15, GitHub Copilot CLI 1.0.86, Gemini CLI 0.60.0, Grok Build 1.0.38, Goose 1.51.0, MiniMax Code 0.2.7, codex-acp 1.12.0 and claude-acp 0.79.0. Its method summary reports session/list as 21 supported, 4 auth-required, 8 method-not-found and 1 other; session/fork as 8 / 3 / 18 / 5; session/resume as 10 / 5 / 16 / 3; session/stop as 1 / 0 / 31 / 2; and session/set_model as 17 / 2 / 10 / 5. This is measured daily probe evidence, not a protocol-version change.

None of these native ACP implementations establishes native UHP adoption. HarnessRouter exposing OpenCode, Qwen Code, Cline, DeepSeek Harness, Gemini CLI and Goose behind UHP are separate adapter paths; the released Qwen path uses CLI stream-json/resume rather than the upstream --acp endpoint, the Cline path uses --json, and no source reviewed establishes that HarnessRouter’s dsh path uses dsh-acp, its Gemini path uses Gemini CLI’s ACP mode or its Goose path invokes Goose’s ACP endpoint. No native Qwen Code UHP implementation was verified. No HarnessRouter Harn, CodeBuddy Code, Factory Droid, Cursor, GitHub Copilot CLI, Grok Build, Google Antigravity or MiniMax Code backend, and no Harn, CodeBuddy Code, Factory Droid, Cursor, DeepSeek Harness, GitHub Copilot CLI, Gemini CLI, Grok Build, Goose, Google Antigravity or MiniMax Code native UHP implementation, was verified at this cutoff.

A concrete coexistence example

Section titled “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.

Section titled “Related pages”

Compare further: Cline, DeepSeek Harness, OpenCode, Qwen Code, workspace trust, harness composition, Hermes, UHP vs MCP, UHP vs A2A, UHP vs model APIs, and UHP architecture for the Client/Server/Harness roles referenced throughout this page.

Primary sources

Section titled “Primary sources”