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

News

Unified Harness Protocol news

A dated evidence ledger for meaningful UHP and reference-implementation changes, with protocol changes separated from product releases and adoption claims.

Verified: Protocol: 2026-09-12Static SSG

Latest: UHP 2026-09-12 adds the Harness Plugins sub-protocol (12 September 2026)

Section titled “Latest: UHP 2026-09-12 adds the Harness Plugins sub-protocol (12 September 2026)”

Classification first: UHP’s current published protocol version is now 2026-09-12. PR #165 merged on 12 September 2026 at 23:40:40 UTC as a7406cbde6192a5bdd8943b012574fd3ee4ac38e. HarnessRouter stable remains v0.16.1; the protocol merge advanced current main without publishing a new stable Community Edition release.

The new optional Harness Plugins sub-protocol uses Agent Plugins 1.0.0 as the package format. A UHP plugin can carry plugin.json, optional mcp.json and Agent Skills; UHP standardizes how the package is bound to a hosted harness, transported/stored, exposed through derived manifest/MCP/skill state, combined with direct harness configuration, retrieved and exported again. UHP does not define a competing plugin package format.

The protocol adds plugin capability discovery (plugins, plugin_schemas), package-file retrieval, harness export, stdio-MCP package materialization, five plugin-specific error codes and explicit plugin execution-security rules. Export omits credentials and records omissions rather than treating package headers/environment fields as portable secrets.

Conformance advances to package 2026.9.12 and 74 checks: Core 40, Extended +8 and Full +25. The ten new P-01 through P-10 checks are capability-gated. A server reporting plugins: false skips them; a skip is not a pass.

The implementation boundary matters. PR #165 explicitly states that the HarnessRouter Community Edition reference gateway at the merge point still serves 2026-08-11 and reports no plugins capability. Its checked-in live reference result therefore remains the earlier 64/64 Full run from 4 September under suite 2026.8.11.post1; there is no verified 74/74 HarnessRouter runtime result to claim at this cutoff.

Read Harness Plugins for the new package/runtime contract and UHP vs Agent Plugins for the updated standards boundary.

Oh My Pi v18.1.19 promotes the tracked reliability line to stable (12 September 2026)

Section titled “Oh My Pi v18.1.19 promotes the tracked reliability line to stable (12 September 2026)”

Classification first: Oh My Pi stable is now v18.1.19, published 12 September 2026 at 23:57:09 UTC. The tag and checked upstream main both point to e4dd2ec3b487f216c569281e2cdb7ec476a81f2e at this cutoff. HarnessRouter stable remains v0.16.1 and still measures/pins Oh My Pi 18.1.13, so upstream latest and HarnessRouter adapter evidence remain separate coordinates.

The release promotes the previously tracked post-v18.1.18 reliability work into stable behavior: PR #11787 releases obsolete MCP tool generations after reconnect; PR #11799 corrects the bare deepseek-flash alias to DeepSeek V4.1 Flash semantics; PR #11823 makes incomplete tool-call starts replay-safe; PR #11842 adds per-fallback reasoning effort; PR #11335 persists /btw side conversations outside the main transcript/model context; and PR #11545 makes fatal JSON print-mode turns return a non-zero process status after cleanup.

v18.1.19 also adds Agent.getPendingToolResults() and fixes live tool-card continuity before buffered results are persisted, discards speculative sessions when a hook/argument transform changes the call arguments, accepts valid Codex OAuth account tokens that omit chatgpt_account_id when an email is present, repairs the Windows zcode:// OAuth callback path, exposes OS-backed file-lock APIs and fixes the PowerShell 5.1 installer path.

These are Oh My Pi harness/runtime/platform semantics. They do not change UHP, MCP or ACP wire behavior, do not establish native UHP adoption by Oh My Pi, and do not retroactively upgrade HarnessRouter’s measured 18.1.13 evidence to v18.1.19.

Oh My Pi persistent /btw side conversations are now stable in v18.1.19 (12 September 2026)

Section titled “Oh My Pi persistent /btw side conversations are now stable in v18.1.19 (12 September 2026)”

PR #11335 turns /btw into persistent session-local side-conversation history. A bare /btw reopens history, completed topics support multi-turn follow-ups, cancelled requests retain partial output and interrupted records reopen without automatic replay. Crucially, upstream keeps those exchanges outside the main transcript and model context. Follow-ups reuse an isolated topic-specific provider session for cache locality, while cancellation or failure starts a fresh transport generation.

The merge also treats that side history as session-integrity state rather than disposable UI state: stale cross-process writes are rejected, active topics are protected with an OS-backed per-topic lease, and session selection/deletion plus create/switch/branch and working-directory/worktree transitions settle or refuse around pending /btw writes. A terminal save failure blocks the transition rather than being treated as a successful flush. Upstream reports 186 focused tests across 12 files plus package checks and direct TUI exercise.

This is an Oh My Pi auxiliary-context/session-isolation and persistence change. It does not add a UHP Session/Task primitive, does not change MCP or ACP wire semantics, and does not establish HarnessRouter revalidation against the newer OMP stable line.

Oh My Pi v18.1.18 adds Anthropic remote compaction and tightens session/task recovery (11 September 2026)

Section titled “Oh My Pi v18.1.18 adds Anthropic remote compaction and tightens session/task recovery (11 September 2026)”

Classification first: v18.1.18, published 11 September 2026 at 21:43:45 UTC with tag target 00085d4e7dfdcfbf302c122fa2682b410a0f43d1, is now superseded by v18.1.19. HarnessRouter stable remains v0.16.1, and its measured OMP adapter/evidence remains pinned to Oh My Pi 18.1.13. Upstream latest and adapter evidence are separate coordinates.

The release adds first-party Anthropic server-side compaction under OMP’s existing remote-compaction path. The native compact-2026-01-12 path is gated by provider/model/endpoint capability, persists a readable summary plus provider replay payload, falls back to ordinary text summary when the native route is unsupported, and reissues the actual live system prompt for provider-native compaction. This is a harness/provider context-management boundary, not a UHP, MCP or ACP wire change.

v18.1.18 also makes set_steering_mode, set_follow_up_mode and set_interrupt_mode RPC changes session-scoped instead of letting short-lived clients alter machine-global queue-mode defaults. Isolated tasks now preserve otherwise-lost nested-repository work as recovery patches and fail visibly when manual recovery is required. /mcp reload distinguishes servers that are still connecting after the bounded reload window instead of reporting them as zero active.

The PR #11799 DeepSeek V4.1 Flash correction, PR #11787 MCP reconnect-generation cleanup, PR #11823 replay-safe provider retry, PR #11842 per-fallback reasoning effort and PR #11545 JSON print-mode process-status correction were post-release observations relative to v18.1.18; they are now released in stable v18.1.19.

HarnessRouter v0.16.1 makes custom-endpoint mapping and connection tool policy explicit (11 September 2026)

Section titled “HarnessRouter v0.16.1 makes custom-endpoint mapping and connection tool policy explicit (11 September 2026)”

Classification first: HarnessRouter Community Edition stable is v0.16.1, published 11 September 2026 at 07:28:18 UTC. Its annotated tag resolves to 8f976f903683b928a6cb554188547b96fbbd4d74. Checked upstream main is now later a7406cbde6192a5bdd8943b012574fd3ee4ac38e because UHP 2026-09-12 merged after the stable release. The released harness-backend set remains ten.

PR #155 makes each custom provider connection’s model rows an exact map from the canonical model id selected by a harness to the arbitrary wire id expected by that endpoint. The console now edits and persists those rows; a blank wire id preserves the canonical id. Custom endpoints also gain OpenAI Responses format, allowing a Responses-compatible proxy to drive Codex without borrowing another provider’s catalogue. The mapping is connection-scoped, so two harness vocabularies for one endpoint are represented as two connections rather than one ambiguous map.

The release also adds connection-level disabled_tools, merged with the harness-disabled list on every turn. For Codex web_search, HarnessRouter writes the CLI’s working top-level web_search = "disabled" setting; other tool names continue through the existing standing-instruction mechanism. The runner now pins Codex 0.154.0 via HR_CODEX_VERSION and re-pins at startup, eliminating persistent-volume age as a source of CLI-version drift from the previous unpinned first install.

PR #155 records a candidate TokenRouter Codex matrix on pinned 0.154.0: nine models, 43/44 checks, with one gpt-5.6-luna recycle-recall miss. These are HarnessRouter provider/runtime and reproducibility controls, not UHP conformance, not a new backend, and not native UHP adoption by an upstream harness or provider. At the v0.16.1 release point UHP was still 2026-08-11; the protocol later advanced independently through PR #165.

HarnessRouter v0.16.0 adds its hosted service as an optional CE provider (11 September 2026)

Section titled “HarnessRouter v0.16.0 adds its hosted service as an optional CE provider (11 September 2026)”

HarnessRouter v0.16.0, published 11 September 2026 at 04:52:35 UTC, resolves to 2af4f349f2cbc56f2f1c5be040a3dbb0953f714e and is now superseded by v0.16.1.

PR #151 adds HarnessRouter API as an optional provider in the Community Edition Integrations surface. CE’s gateway brokers the hosted /v1/connect hand-off, keeps the connect secret and provider key server-side, stores the returned endpoint/model-catalog coordinates, and routes the existing harness runner through that provider. The default provider base is https://api.harnessrouter.ai/v1/provider, overridable by HR_HOSTED_BASE for the deployment.

Candidate verification also drove reliability fixes: delivery is poll-driven so a partial browser message cannot win the credential race; a ready result remains available for the code lifetime so an overtaking poll cannot turn a delivered key into a 410; polling is serialized; hosted balance is fetched server-side; and Gemini relay routing preserves the selected hosted provider instead of falling through to direct Google. PR #151 records successful candidate turns through the hosted row for Claude Code, Codex app-server and Gemini CLI. Those are point-in-time provider/runtime checks, not UHP conformance or an exhaustive all-model/backend matrix.

The classification boundary matters: HarnessRouter API is a provider integration, not an eleventh harness backend, not a new UHP transport and not native UHP adoption by any upstream harness vendor.

HarnessRouter v0.15.10 makes Codex app-server the normal CE path and clarifies provider-history refusal (10 September 2026)

Section titled “HarnessRouter v0.15.10 makes Codex app-server the normal CE path and clarifies provider-history refusal (10 September 2026)”

HarnessRouter v0.15.10, published 10 September 2026 at 09:07:08 UTC, resolves to fba2ac903c483bf359d1bcaaa70e05f599eeaf97 and is now superseded by later releases. PR #148 carries the later Codex app-server matrix rerun; PRs #152-#154 are documentation/onboarding/integration-guide work.

The material runtime change spans v0.15.8–v0.15.10. PR #144 normalizes Codex app-server item spelling so user/agent/reasoning items are not recorded as tools, names MCP calls as server.tool, recognizes web-search items and preserves command output/exit status. PR #146 then makes Codex app-server the default Community Edition execution path, matching hosted HarnessRouter; HARNESS_CODEX_APPSERVER=0 explicitly restores the older codex exec path.

PR #147 handles a provider-history boundary. Encrypted reasoning produced under one upstream route/account cannot necessarily be opened by another. When that causes continuation refusal, HarnessRouter now turns the raw provider JSON into an actionable explanation to start a new task or keep the previous model. This improves diagnosis and recovery guidance; it does not make cross-route continuation succeed.

PR #148 records the Codex provider-column rerun on app-server: Vercel 43/44, TokenRouter 43/44, OpenAI 44/44, Azure 44/44 and OpenRouter 43/44. Earlier Codex columns were measured on codex exec; this is specifically app-server provider/runtime evidence, not UHP conformance.

HarnessRouter v0.15.7 makes lost resumes explicit and fixes Hermes/Azure API-mode selection (8 September 2026)

Section titled “HarnessRouter v0.15.7 makes lost resumes explicit and fixes Hermes/Azure API-mode selection (8 September 2026)”

HarnessRouter v0.15.7, published 8 September 2026 at 19:31:35 UTC, resolves to 4cd936dc8473b5754cde5c3ae7e62c19a5499a23 and is now superseded by later releases.

PR #139 fixes a Hermes/Azure routing mismatch. Hermes 0.19.0’s built-in azure-foundry API-mode inference did not include later GPT-family names such as gpt-6-astra; that model could therefore fall through to Chat Completions, where Azure rejected reasoning plus function tools. HarnessRouter now explicitly selects codex_responses for azure-foundry using the same later-GPT family test used on generic OpenAI-compatible routes.

The same PR closes a session-continuation evidence gap for Claude Code and OpenCode. If a requested prior session is missing from the restored workspace, HarnessRouter now detects that the built CLI command did not carry the native session id, emits system/resume_lost, and prefixes the reply with a lost-context note. The support-matrix recall judge treats that result as failed recall instead of accepting a fluent fresh-session response as successful continuity.

PR #139 records four motivating hosted OpenCode restored sessions whose recall turns behaved as fresh conversations before this hardening. That is point-in-time HarnessRouter evidence, not a universal claim about OpenCode or Claude Code. The release changes reference-implementation/runtime fidelity, not the UHP protocol, conformance denominator or native adoption status.

PR #140 later reran the quota-limited dsh OpenRouter column at 189/189 across 38 models on HarnessRouter 0.15.7 / dsh 0.1.2rc1; that evidence shipped in v0.15.8 and remains provider/runtime evidence rather than UHP conformance.

HarnessRouter v0.15.6 closes the custom-harness MCP verification gap (8 September 2026)

Section titled “HarnessRouter v0.15.6 closes the custom-harness MCP verification gap (8 September 2026)”

HarnessRouter v0.15.6, published 8 September 2026 at 13:31:18 UTC, resolves to 200b21b56cb6db570f4b4130dcbd76229825d7b6 and is now superseded by later v0.15.x releases.

PR #135 upgrades its DeepSeek Harness pin from 0.1.0rc7 to 0.1.2rc1 and composes configured MCP servers into the dsh sdk profile. The same change corrects Oh My Pi MCP entries to type: "http" and stops advertising python/browser as OMP hard-switch tools because the measured 18.1.13 binary rejects them. PR #136 makes runnable-model availability yes/no/unknown; PR #137 tightens same-model, retry/error and final connection attribution; PR #138 adds a real MCP-server call to the custom-harness verification dimension and reports candidate coverage across all ten built-in harness bases when its external endpoint is reachable.

That real-MCP dimension is HarnessRouter implementation/runtime verification, not UHP conformance and not a blanket claim that every MCP server/tool works through every harness.

DeepSeek Harness upstream separately published v0.1.5-rc.2 on 10 September at 15:09:34 UTC. HarnessRouter’s 0.1.2rc1 adapter pin and upstream DeepSeek Harness latest prerelease are separate coordinates.

HarnessRouter v0.15.4–v0.15.5 strengthen presentation and verification methodology (8 September 2026)

Section titled “HarnessRouter v0.15.4–v0.15.5 strengthen presentation and verification methodology (8 September 2026)”

HarnessRouter v0.15.4 and v0.15.5 are primarily README/Quickstart-console refinements. PR #129 expands UHP/integration framing, PR #130 moves the Quickstart agent picker into the step it changes and clarifies the primary copy action, and PR #131 aligns each step’s first action.

PR #132 checks in a reproducible responsive audit. PR #133 then codifies support-matrix verdict rules for serving connection/model identity, artifact-card equality and catalog honesty, and adds the initial custom-harness skill/tool-policy/script/disabled-tool probe. PR #138 later covers the MCP-server part at the HarnessRouter implementation-verification layer, and PR #139 further prevents an explicit lost resume from passing recall judgement.

HarnessRouter v0.15.3 hardens hosted login-state cookies (8 September 2026)

Section titled “HarnessRouter v0.15.3 hardens hosted login-state cookies (8 September 2026)”

PR #125 moves the hosted bearer-bearing hr_auth cookie to a host-only, HttpOnly, Secure, SameSite=Lax server-set cookie while retaining only a non-secret cross-subdomain login hint. PR #127 reconciles those cookies from the current session and bounds the migration case where two same-name hr_auth cookies can arrive. Both paths are explicitly inert self-hosted.

Oh My Pi becomes the tenth backend in v0.15.0 (7 September 2026)

Section titled “Oh My Pi becomes the tenth backend in v0.15.0 (7 September 2026)”

PR #68 adds Oh My Pi (omp) as the tenth built-in HarnessRouter backend. PR #119 records 705/705 OMP scenario runs across seven provider columns under the stated pre-release conditions using Oh My Pi 18.1.13. Upstream Oh My Pi has separately published v18.1.19. The adapter pin, upstream latest release and later PR #138 MCP/custom-harness evidence are separate coordinates.

v0.15.1 fixes the console send latch and duplicate produced-file delivery. v0.15.2 strengthens artifact-card evidence, refreshes the ten-harness README state and adds gpt-6-astra on compatible routed paths.

v0.14.0–v0.14.5: Gemini fidelity and deleted-session finality (7 September 2026)

Section titled “v0.14.0–v0.14.5: Gemini fidelity and deleted-session finality (7 September 2026)”

The v0.14.x line makes requested-vs-served Gemini identity enforceable, prevents silent candidate fallback, adds TokenRouter’s native Google path for Gemini CLI, pins helper tiers and all eighteen model-naming helper aliases to the turn model, and makes deleted sessions final in HarnessRouter. These remain implementation/runtime changes rather than a UHP date-version.

Gemini CLI becomes the ninth backend (6 September 2026)

Section titled “Gemini CLI becomes the ninth backend (6 September 2026)”

HarnessRouter v0.13.24 releases PR #72 and adds Gemini CLI as the ninth backend, pinned by HarnessRouter to Gemini CLI 0.58.0 for that adapter line. The backend uses the direct Google API-key integration path. Google AI Studio provider routing had shipped earlier for six existing backends; provider and backend remain separate coordinates.

PR #93 remains historical eight-backend evidence (6 September 2026)

Section titled “PR #93 remains historical eight-backend evidence (6 September 2026)”

PR #93 publishes the broad self-hosted matrix measured before Gemini CLI and Oh My Pi became released backends: 695 harness × model pairs across eight provider columns, with first turn, same-session follow-up, in-column model switch, artifact creation and recycle/recall scenarios. Published scenario totals are TokenRouter 832/840, Vercel 857/859, Azure OpenAI 267/271, OpenAI 267/273, Anthropic 245/245, OpenRouter 669/670 and Azure E2 267/270. Google AI Studio is 0/5 measured, not a compatibility score, because the notes say that day’s Free-tier quota had already been exhausted.

A separate 35-minute cold-recall probe reopened one session for each of the eight then-released backends and all eight answered on the model previously used. PR #139 does not rewrite those historical results; it strengthens the current recall judge so an explicit lost-resume result cannot be counted as successful continuity. PR #148 and PR #155 likewise record later Codex evidence without rewriting PR #93.

Conformance moved from the measured 64-check line to a 74-check protocol suite (4–12 September 2026)

Section titled “Conformance moved from the measured 64-check line to a 74-check protocol suite (4–12 September 2026)”

v0.13.2 released PR #60, naming DELETE /v1/sessions/{session_id} as the protocol’s session-delete path and adding Full check F-08, which took the then-current suite from 63 to 64 checks. PR #64 incorporated the live 4 September 64/64 Full, 0 failed, 0 skipped, 0 errored HarnessRouter reference measurement into source.

PR #165 later publishes UHP 2026-09-12 and adds ten capability-gated plugin checks, taking the current suite to 74. The old 64/64 measurement remains exact evidence for the suite/runtime actually tested; it is not silently relabeled 74/74.

Independent-server evidence remains revision-bounded

Section titled “Independent-server evidence remains revision-bounded”

Public aenawi/uhp-go records 63/63 Full, zero skipped for its pinned post-R-08 revision, measured 1 September against HarnessRouter 08d61ea. PR #55 separately records 63/63 Full against an unnamed independent Go UHP server. Neither is silently upgraded to the current 74-check shape.

  • Published UHP is 2026-09-12; Agent Plugins 1.0.0 is the package standard used by the optional Harness Plugins sub-protocol.
  • HarnessRouter stable is v0.16.1 / tag 8f976f90; checked upstream main is a7406cbd at this cutoff.
  • Current suite contains 74 checks under package 2026.9.12; the checked-in HarnessRouter live reference result remains the earlier 64/64 Full measurement.
  • PR #165 explicitly states the reference gateway still serves 2026-08-11 and reports plugins unsupported at the merge point; a verified HarnessRouter 74/74/runtime-plugin result is not established.
  • Released HarnessRouter backend set remains ten.
  • v0.16.1 adds custom-endpoint model mapping, custom Responses format, connection-level tool policy and a pinned Codex 0.154.0; these are provider/runner controls, not the UHP protocol change.
  • v0.16.0 adds the hosted HarnessRouter service as an optional provider and hardens its pairing/relay path; it is not a UHP protocol, backend-count or conformance change.
  • v0.15.8–v0.15.10 change Codex app-server normalization/default execution and provider-history refusal handling; PR #148 adds app-server matrix evidence. None is a UHP conformance or native-adoption event.
  • PR #139 changes Hermes/Azure API-mode selection and Claude/OpenCode lost-resume fidelity; it is not a UHP conformance check or native adoption event.
  • PR #138 closes PR #133’s custom-harness MCP verification gap at the HarnessRouter implementation layer; it is not a UHP conformance check.
  • HarnessRouter measures DeepSeek Harness 0.1.2rc1 from v0.15.6; upstream latest prerelease is separately v0.1.5-rc.2.
  • HarnessRouter’s OMP adapter/evidence still distinguishes measured 18.1.13 from upstream Oh My Pi v18.1.19.
  • PR #93, PR #119, PR #138, PR #139, PR #140, PR #148, PR #151, PR #155, the prior 64/64 measurement and the current 74-check suite are different evidence classes/scopes.
  • Native UHP adoption by upstream harness vendors remains not established by the primary evidence tracked here.

Use the release tracker for version-by-version state, Harness Plugins for the new sub-protocol, UHP vs Agent Plugins for the standards boundary, HarnessRouter for reference-implementation behavior, conformance for UHP suite evidence, ecosystem and adoption for scope boundaries, and primary sources for source links.