Skip to content
UHPUHPDeveloper Guide
Independent resource · Not affiliated with HarnessRouter · Site data checked 7 Sep 2026

Harness integration

UHP and Gemini CLI

Gemini CLI became HarnessRouter's ninth released harness backend in v0.13.24. HarnessRouter v0.14.0 then makes requested Gemini model identity explicit and fails a turn when the serving model is substituted.

Verified: Protocol: 2026-08-11HarnessRouter: v0.14.0

HarnessRouter Community Edition v0.13.24, published 6 September 2026, added Gemini CLI as a released harness backend through PR #72. That changes the released HarnessRouter backend set from eight to nine: Claude Code, Codex, Hermes, Pi, DeepSeek Harness, OpenCode, Qwen Code, Cline and Gemini CLI.

This is HarnessRouter adapter support, not evidence that Google has implemented UHP natively in Gemini CLI. UHP remains the outer client-to-harness-server contract; HarnessRouter is the implementation that drives Gemini CLI underneath it.

PR #72 adds a dedicated Gemini runner and backend registry entry. The released integration pins Gemini CLI 0.58.0 and uses Gemini CLI’s stream-JSON execution path. For the direct Google path, HarnessRouter supplies GEMINI_API_KEY and invokes Gemini CLI with the requested model rather than routing the Gemini backend through an OpenAI-compatible relay.

The pin is an implementation choice by HarnessRouter. It should not be confused with the newest upstream Gemini CLI release.

HarnessRouter v0.14.0, published 7 September 2026, releases PR #111. The change addresses a model-identity problem specific to the Gemini CLI integration: Gemini CLI can normally rewrite or substitute some Gemini model identifiers.

HarnessRouter now configures every measured Gemini model identifier so that the requested identifier maps to itself. The support work records 11 measured Gemini IDs under this rule. HarnessRouter also evaluates the model actually observed for each turn; when the serving identifier differs from the requested identifier, the turn is treated as a routing failure rather than a pass.

That distinction matters for interoperability testing. A successful answer from a different model is not evidence that the requested model/backend pair works as declared.

Native ACP and A2A are separate boundaries

Section titled “Native ACP and A2A are separate boundaries”

Gemini CLI also exposes upstream interoperability work outside UHP. Its repository documents an ACP mode, and Google has separately developed an A2A server path around Gemini CLI. Those are meaningful ecosystem signals, but they solve different boundaries:

  • UHP through HarnessRouter: a product drives a complete configured Gemini CLI harness through a UHP server.
  • ACP: an editor/client integrates with an agent through the Agent Client Protocol boundary.
  • A2A: an agent system exposes agent-to-agent discovery and communication semantics.

Native ACP or A2A support does not imply native UHP support, and HarnessRouter backend support does not imply Google endorsement of UHP.

As of 7 September 2026:

  • UHP remains 2026-08-11 Draft.
  • HarnessRouter Community Edition stable is v0.14.0, tag target 57910f8.
  • Upstream HarnessRouter main is also 57910f8 at the checked cutoff.
  • HarnessRouter has nine released harness backends, with Gemini CLI added in v0.13.24.
  • Current UHP conformance coverage remains 64 checks and the checked-in HarnessRouter reference evidence remains 64/64 Full from the 4 September run.
  • The broad PR #93 self-hosted support matrix predates the Gemini backend and therefore remains an eight-backend point-in-time measurement rather than being silently relabelled as nine-backend evidence.

Read HarnessRouter, release tracker, ecosystem, adoption, UHP vs ACP and UHP vs A2A.