Wink Pings

Agent harnesses now have a unified protocol—but don’t treat it as a universal plug just yet

UHP and HarnessRouter want to put Codex, Claude Code, Gemini CLI, and others behind a single backend interface. Official benchmarks say switching harnesses can save 25% to 64%, but the community is asking: does it still save when measured per passed task, and what about isolation and approvals?

Agent harnesses now have a unified protocol too. A developer built UHP (Unified Harness Protocol), and the open-source implementation is called HarnessRouter. The problem it aims to solve is very concrete: when a product backend connects to multiple harnesses, it no longer needs to rewrite task execution, sessions, streaming output, file returns, and failure handling for each harness.

On the left of the image is direct integration: the product backend connects separately to Codex, Claude Code, and Gemini CLI, handling sandboxing, streaming, and output formats itself. On the right is HarnessRouter, which centralizes sandboxing, files, recovery, tracing, sessions, and streaming, then dispatches to 24 tools. Source: Akshay's tweet.

How it works is not complicated. The product backend sends a task with harness_id; HarnessRouter starts the selected harness in an isolated session; the harness runs its own agent loop and streams progress back; files, artifacts, failure information, and final output are returned through the same interface.

HarnessRouter integration comparison

The image above comes from HarnessRouter's GitHub. Without a Router, 4 harnesses would carry 36 integration responsibilities, and adding a fifth would make it 45; with a Router, the product side keeps just one integration. The math is easy, and the pain point is real: every time you add a harness, you have to deal with task execution, sessions, streaming, files, recovery, and output formats all over again.

HarnessRouter currently lists 30 harness bases, including Codex, Claude Code, Hermes, Pi, DeepSeek Harness, OpenCode, Kilo Code, Qwen Code, Gemini CLI, Cline, goose, Aider, OpenHands, and others. It provides an OpenAI Responses-compatible API and supports persistent sessions, streaming progress, files and artifacts, cancellation, and structured failures. Alibaba Cloud Qoder has also integrated UHP and can serve as an agent backend for the HarnessRouter API.

Two numbers in the official benchmarks stand out. With a fixed model and only the harness changed, cost dropped by 25% to 64% on several healthcare compliance tasks. When both the harness and the model were changed, the gap between the highest- and lowest-cost configurations was 99.8%.

Official benchmark chart

But on the subject of cost, the comments are more sober than the benchmark chart. Max Petrusenko points out that if a cheaper harness completes fewer tasks, the 25% to 64% reduction does not hold; the right metric is cost per passed task. Solar Nomad uses their own reel tasks as an example: each run costs $2.55, and each accepted reel costs $5.74, because 5 out of 9 runs were thrown away. This metric is closer to production than the per-run price.

Steven's view goes closer to fundamentals: the first thing a unified interface should define clearly is the exit contract. What counts as completion, what is returned on partial failure, and how cost is reported. Without these, routing is just switching between different surprises.

Isolation was also called out. Saeid Sisakhti notes that HarnessRouter's session is an independent OS user and an independent workspace, not an independent container, and the Runner still retains the permission to create those users. For harnesses that can run arbitrary shell commands, this layer of isolation looks thin. They asked whether there is a roadmap for one container per session.

Approval flows are likewise not unified. Someone asked what happens when a harness pauses midway to wait for user authorization; Akshay replied that there is currently no unified pause/approve/resume flow, and HarnessRouter leans more toward autonomous operation. Tanul Mittal also asked whether UHP preserves each harness's own permission model or compresses it to the lowest common permissions. No clear answer to this question appears in the source material.

There is also an underappreciated use. SrinivasPadmanabhuni says a shared harness interface is best suited as a test fixture: run the same set of tasks on two harnesses, and once the interface is unified, the harness becomes the only variable; then look task by task at which results flip, how much tool calls differ, and where retries and timeouts differ. This use is more practical than rushing to do production routing.

What UHP lowers is integration cost; it does not automatically solve quality, cost metrics, isolation, and approvals. If you want to use it as a product backend, first run each candidate harness on a small set of your own tasks and record completion rate, cost per passed task, failure types, isolation requirements, and approval needs. After all, a protocol can unify interfaces, but it cannot unify how reliably each harness gets the job done.

Repo: https://github.com/HarnessRouter/harnessrouter

UHP spec: https://unifiedharnessprotocol.org

发布时间: 2026-11-04 06:42