Unified Harness Protocol news

8 November 2026 — three HarnessRouter releases in six hours, and MCP’s Skills extension moved to Beta

HarnessRouter stable is now v0.38.5 from 52c929f1cf3097d34a733fd3f419f454d0e7973f, published 8 Nov at 04:35:16 UTC, and development main is at the same commit the tag was cut from. Three releases landed in about six hours: v0.38.3 (7 Nov 22:44 UTC), v0.38.4 (7 Nov 23:23 UTC) and v0.38.5 (8 Nov 04:35 UTC). UHP is still 2026-10-19 Draft; the conformance package is still 2026.10.19.post5 with 104 executable checks = 41 Core, 9 Extended and 54 Full, over 30 released backends; gateway/app.py still sets UHP_VERSION = "2026-09-28".

v0.38.3 — the MCP probe reads a whole event. Test connection on an MCP server could report a server as connected with no name and no tools, because some servers split one answer over several data: lines of a single event and the probe read each line on its own. It now joins an event’s lines before reading them (PR #645), reads at most 4 MiB and spends at most 30 seconds on it, and says which limit it reached. A custom connection in the OpenAI Responses format can now drive Pi or Oh My Pi (PR #642). The release also carries the two runner changes this site tracked as development evidence on 6 November: a turn’s status and cancel answer only the session that started it (PR #643), and a retried turn’s idempotency key matches only within that same session (PR #644).

v0.38.4 — a shared deployment holds an organization’s own connection address to the MCP rule. On a deployment shared by several organizations, the model broker calls each organization’s own connection, and that call now goes only to an address that resolves outside the deployment’s own networks — the rule an MCP server’s address already follows. An address that cannot be used as written is refused before any lookup, the name is resolved once with every address it answers classified, and the socket opens only to a checked address; a refused call answers 403 with the reason. A single-operator install, the default, is unchanged.

v0.38.5 — first-start installs are pinned and stamped. Every agent harness on a volume is now installed once at the first start after the upgrade, pinned to an exact version with its release assets checked against digests committed in the image (PR #646, #623): opencode 1.18.23, Qwen Code 0.26.3, Pi 1.5.0, and exact versions for Hermes’s and the other Python harnesses’ top-level packages. A stamp replaces the per-start version checks, and a CI source check fails on any unpinned install. The first start after upgrading takes 8 to 14 minutes — 13 minutes 40 seconds measured — because all 30 harnesses are reinstalled; later starts install nothing. The installer’s processes no longer see the instance’s internal key, the console password or the provider keys, though installs still run as root, so this stops a package that reads its environment rather than one that sets out to read the instance’s secrets. A connection can also carry request headers, sent after the key on every model call (PR #636): held like the key, never handed to the agent, masked when read, and gateway-set names — via, forwarded, proxy-*, x-forwarded-*, cf-* — plus AWS signing names (x-amz-*) refused. With HR_STEP_CHECKPOINT=1 the workspace is saved after each finished tool step, so a sandbox lost mid-task keeps its steps (PR #634, #505); it is off by default. HERMES_MCP_PIN is no longer read — use HR_HERMES_MCP_VERSION with an exact version — and HR_OPENCODE_VERSION no longer accepts latest.

MCP’s Skills extension is at the Beta stage, and the directory is what says so. MCP’s extension-lifecycle SEP, SEP-3392, is Final and makes the directory holding an extension’s specification the marker of its stage. On 29 October 2026 the Skills extension’s specification moved from specification/stable/ to specification/beta/ (PR #161) with its contents unchanged — so a Final SEP and a stable-stage extension are different facts. The Tasks and MCP Apps specifications sit under their released version directories beside a draft/ working copy. The skills guide now says this, and its old specification/stable/skills.mdx link — which now 404s — is replaced with the current path.

ACP stabilized client-provided system prompts. PR #2765 merged on 6 November 2026 and completed the Client-Provided System Prompt RFD: the systemPrompt field on a session setup request and the systemPrompt session capability left the unstable_session_system_prompt feature gate and are now part of the stable v1 and v2 schema sources. A systemPrompt the agent cannot apply is answered with an error, and -32602 is recommended.

This run’s rotation was interoperability and adjacent protocols, and the rest of that cluster did not move: the released MCP specification is still 2026-07-28, the Tasks extension is still v0.2.3, ACP’s latest release line is still v1.15.1 with schema-v2.0.0-alpha.13 for v2, A2A’s latest release is still v1.0.1 and its recent repository commits are documentation publications, and the Agent Identity Protocol repository’s recent commits are specification-precision fixes rather than a version change. Upstream Qwen Code released v0.27.0 on 7 November, and the ACP registry’s manifest now names it.

The weekly competitive cohort was not due: it was worked on 2 November for ISO week 45, which runs to Sunday 8 November. It comes due again on Monday 9 November for week 46, whose two routes in table order are /uhp-vs-ahp/ and /harness-of-harness/.

7 November 2026 — the harness pages stopped calling September current

HarnessRouter stable is unchanged at v0.38.2 from 8e1cf1b598a7ea864fda3a5de064b11289b6ac84, published 4 Nov at 22:53:50 UTC, and development main is still 46d2cc2167ea257f8c4c99eada5297af300b01ab, two commits ahead of the tag. UHP is still 2026-10-19 Draft; the conformance package is still 2026.10.19.post5 with 104 executable checks = 41 Core, 9 Extended and 54 Full, over 30 released backends. What moved is what the pages claim.

Thirty-one pages were still asserting September’s coordinates as current. They named HarnessRouter’s stable release as v0.18.1, v0.18.2, v0.18.4 or v0.19.0 — the last of them published 19 September — and backend sets of eleven, twelve or thirteen where the current stable offers 30. The same pages called UHP 2026-09-12 the current line with 75 conformance checks, where the published draft is 2026-10-19 with 104. Every dated measurement behind those sentences was left exactly as it was recorded; only the claim about now was wrong.

Hermes released v0.23.0 on 5 November. Five pages now name it as the current stable: the “Hearth” release, whose headline is that the whole Desktop workspace opens in a browser tab served by the agent’s own gateway, with one gateway owning each session. The mutation-identity contract was re-checked at that tag and is unchanged.

DeepSeek Harness moved from its alpha line to a release candidate. dsh-v0.2.2-alpha.2 (28 October) becomes dsh-v0.2.2-rc.1 (4 November), the first candidate of the 0.2.2 series, rolling up the user and developer changes since dsh-v0.2.1-rc.5 — including the experimental subagent_oar plugin that hands a step to a local Codex or Claude CLI, the plugin-manager detail view, copying a conversation as Markdown, and Japanese, Spanish, French, German, Russian and Brazilian-Portuguese locales.

SuperQode’s current stable moved by twenty-six minor versions. The client page named v2.5.5 (4 October); it is v2.31.4 (5 November), whose README still documents connect uhp and serve uhp and still serves protocol 2026-09-12.

This run’s rotation was harnesses, and the upstream harness releases were surveyed rather than assumed: Claude Code v2.1.319, Codex rust-v0.167.0, Gemini CLI v0.67.0, Qwen Code v0.26.9, Goose v1.57.0, Cline v4.1.26, OpenCode v2.2.6, Pi v1.5.0, OpenHands v1.37.0, Hermes v0.23.0 and DeepSeek Harness dsh-v0.2.2-rc.1. Of those, only Hermes and the DeepSeek candidate are coordinates this site tracks, because the reference implementation’s pins for the rest are deliberate rather than stale.

The weekly competitive cohort was not due. It was worked on 2 November for ISO week 45, and 7 November falls in the same week; it comes due again on Monday 9 November for week 46.

Nothing else moved: the released backend set is still 30 bases, gateway/app.py still sets UHP_VERSION = "2026-09-28", and the memories and harness_retirement capabilities are still advertised by no server.

6 November 2026 — a turn answers only the session that started it

HarnessRouter stable is unchanged at v0.38.2 from 8e1cf1b598a7ea864fda3a5de064b11289b6ac84, published 4 Nov at 22:53:50 UTC. No release has followed it. What moved is development main, now two commits ahead of the tag, and both commits narrow a turn’s reach to the session that started it.

A turn is answered only to its own session. GET /turn/{id} and POST /turn/{id}/cancel now take the identifier the gateway already sends on every runner call, and a turn started by another session reads as no turn at all (404); a turn recorded without an identifier answers as before. The upstream notes this is the runner’s internal surface, where every route already requires the internal key that no session process holds.

An idempotency key dedupes within its own session. The runner’s dedupe map is keyed by session and key, so a retried request from the same session still returns its running turn, while another session sending the same key starts its own turn instead of being answered with that turn’s id, status and model. The 2026-10-19 specification leaves the key’s scope to the client — it is a “client-generated-unique-string”, and the server must return the first request’s result for a repeated key — so a client that reuses one key across sessions is misusing it, and the implementation now contains the mistake rather than the other session’s turn. Before these two changes, a key collision between two sessions could hand the second session the first session’s turn identifier, status and model.

Three corrections went with the run. The /harnessrouter/ page contradicted itself about the upstream main coordinate — its release-scope paragraph named 8e1cf1b598a7 while the table beside it named f6592b27e0d4 — and both now read the checked coordinate. The /uhp-vs-acp/ page named claude-agent-acp’s current stable as v0.100.0, where the adapter has since published v0.101.0 (5 Nov 2026). And the /mcp-tasks/ page carried two facts the published Tasks extension has since corrected: the extension’s overview said the missing-capability error is -32003 until its v0.2.3 release (4 Nov 2026) corrected it to -32021, the code MCP uses, and the same release corrected the resultType its examples use to complete.

This run’s rotation was security and evaluation, and it checked the cluster’s primaries rather than finding them moved: the HarnessRisk benchmark’s figures are exact against both its pinned repository commit and the arXiv v1 abstract — 128 sandboxed cases, three harnesses, six models and fourteen model–harness configurations, with no revision after v1 of 18 August 2026; the Qwen Code pull requests behind the managed-runtime-attestation and workspace-trust guides are all merged as recorded; the reference implementation’s released security work has not moved since v0.38.2; and MCP’s enterprise-managed-authorization extension is unchanged. The IETF identity and assurance drafts the security guide tracks remain unreachable — the Datatracker, its static archive and the IETF mail archive all answer a Cloudflare challenge to this sandbox — so their recorded revisions are left as they were and the gap is reported rather than filled by inference.

Nothing else moved: UHP is still 2026-10-19 Draft, the conformance package is still 2026.10.19.post5 with 104 executable checks = 41 Core, 9 Extended and 54 Full, the released backend set is still 30 offered bases with 30 entries in the runner’s BACKENDS registry, and gateway/app.py still sets UHP_VERSION = "2026-09-28". The weekly competitive cohort was not due: it was worked on 2 November for ISO week 45, and 6 November falls in the same ISO week, so it is next due in ISO week 46, from 9 November.

5 November 2026 — HarnessRouter v0.38.0, and the UHP draft gained a way to ask the person

HarnessRouter stable is now v0.38.2 from 8e1cf1b598a7ea864fda3a5de064b11289b6ac84, published 4 Nov at 22:53:50 UTC, with development main separately observed at the same commit. Three releases landed in one day and the first of them is a minor one — v0.38.0 at 07:28, v0.38.1 at 17:29, v0.38.2 at 22:53 — and one of them changed the protocol itself.

The UHP 2026-10-19 draft gained a section the version number does not show: Tasks §3.2 “Asking the person”. The draft’s five chapters changed between v0.37.18 and v0.38.2 — tasks.md, lifecycle.md, errors.md, sessions.md and streaming.md — and the spec’s own index records the change as “added after publication and additive”. With the new input_requests capability, a harness that needs one answer — a choice between alternatives, a confirmation before an action that cannot be undone, a value it must not guess, a secret it must not invent — ends the turn instead of inventing one: the response ends incomplete with incomplete_details.reason input_required, the question is the response’s last input_request item, and the answer is an input_response item on the next task, chained on that response. The turn’s last message carries the question as text too, so a client that renders only message items shows it; and a task chained on a response that ended on a question carries either the answer or anything else, which passes the question over, with the server saying which happened. Three refusals name what went wrong with an answer — input_not_pending (409), input_request_expired (410) and input_response_invalid (422) — and invalid_request_error now includes 410. The conformance package moved with it: 2026.10.19.post5, 104 executable checks = 41 Core, 9 Extended and 54 Full, with the two new T-13 and T-14 checks.

The credential boundary moved. In v0.38.0 a remote MCP server’s address and credentials stay in the server, and the session gets a local address holding one token that stops working when the turn ends — before, most bases wrote the bearer token and the address into a config file in the session, where the agent could read it, and some of those files travel in the checkpoint. Rotate MCP tokens if an agent you do not fully trust has run on the instance. The same release encrypts stored credentials at rest on every install: an install with no HR_SECRET_KEY gets one at its first start, kept in /data/secret-key (root’s, mode 600). That protects a copy of the secret store, not a copy of the whole volume, because the key sits beside the data. v0.38.1 closes a gap where a session’s reads and writes kept root’s supplementary group, so an agent could use a link to reach what gid 0 can reach — on the default image very little, but a volume you mount can hold more. And v0.38.2 corrects the image’s licence text: an LGPL library had shipped with no licence text beside it, NOTICE had claimed a permissive licence for everything bundled while listing only direct dependencies, and the image did not carry LICENSE or NOTICE at all. A licence check now runs in the tests and inside every release’s image.

This run’s rotation was discovery and execution. The discovery side had not moved — the ARD specification’s repository is still at the 25 October commit and the AI Catalog working repository at the 28 October one, both as recorded on 31 October — and the execution side carried the day’s finding: the asking-the-person flow, the credential boundary and the input_requests capability are all about how a task ends and what a turn can reach.

Nothing else moved: UHP is still 2026-10-19 Draft, the released backend set is still 30 offered bases with 30 entries in the runner’s BACKENDS registry, and gateway/app.py still sets UHP_VERSION = "2026-09-28" even though the same tree implements the 2026-10-19 additions. The weekly competitive cohort was not due: it was worked on 2 November for ISO week 45, and 5 November falls in the same ISO week, so it is next due in ISO week 46, from 9 November.

4 November 2026 — HarnessRouter v0.37.18, and two more security releases in one night

HarnessRouter stable is now v0.37.18 from 433acfe0047e19f6d4610cda065d9287b9620876, published 4 Nov at 01:41:17 UTC, with development main separately observed at the same commit. Three releases landed since yesterday’s run, and two of them are security releases.

v0.37.17 (3 Nov, 23:16 UTC) closed a critical one: an API key could read any file as root. A marker file in a session’s folder could point the file routes at any folder on the machine, and a caller’s own PUT could set it, with no agent involved — reaching HR_SECRET_KEY, the stored provider keys and the databases. Only the value the runner writes itself counts now, and those reads and writes run as the session. Upgrading does not undo a read that already happened and the logs cannot show one, so the release’s own remediation is a credential rotation: change HR_SECRET_KEY and the console password, replace the stored provider keys and any passed in the environment, reissue the API keys, then restart. The same release makes every file route refuse dot paths — covering the runner’s state, git’s folder and any credential file such as sub/.env, which the listing, the archive and share links used to serve — and stops root from running what the product user can change.

v0.37.16 (3 Nov, 11:35 UTC) turned off the console’s image optimizer, which was reachable with no sign-in through published Next.js remote-code-execution bugs (GHSA-2464-fhr4-w9xw, GHSA-2xp9-vwfh-vxw4); hardened MySQL and MariaDB connections against a hostile server; stopped a build’s own code from planting a link that makes the runner write or read a file as root; sandboxes an agent’s HTML and SVG files opened through the console; and ends a relay route with its turn. It also fixed a regression it had introduced the day before: v0.37.15 sent Gemini’s key both as x-goog-api-key and as a bearer token, and Google reads a bearer as an OAuth token — so every Gemini turn on a Google API key failed with a 401. Google API keys no longer offer gemini-3.5-flash either: Google answers that id with gemini-3.6-flash, and other bases ran 3.6 under the 3.5 name.

v0.37.18 moved Claude Code’s default model to claude-sonnet-5.5 (from claude-sonnet-4.6, which is still offered); a harness with its own saved default keeps it.

This run’s rotation was memory and identity. The memory surface of UHP did not move: the Memories chapter is byte-identical at v0.37.14, v0.37.15, v0.37.16, v0.37.18 and main, the 13 ME- checks are unchanged, and CE still advertises no memories capability. The rotation’s correction was the stable Hermes release, which is now Agent v0.22.7 (3 November) after v0.22.6 (2 November) — the site still named v0.22.5 (23 October). Both are patch rollups: the memory-mutation contract the site documents — the committed entry identity carried as metadata["previous_content"] — is still present and unchanged at v0.22.7, so the guidance stands and only its anchor moved.

Nothing else moved: UHP is still 2026-10-19 Draft, the conformance package is still 2026.10.19.post4 with 102 executable checks = 41 Core, 9 Extended and 52 Full, the released backend set is still 30 offered bases with 30 entries in the runner’s BACKENDS registry, and gateway/app.py still sets UHP_VERSION = "2026-09-28". The weekly competitive cohort was not due: it was worked on 2 November for ISO week 45, and 4 November falls in the same ISO week, so it is next due in ISO week 46, from 9 November.

3 November 2026 — HarnessRouter v0.37.15 closes every path from an agent turn to a credential

HarnessRouter stable is now v0.37.15 from d11a20845b6ae48f83c955d733562b6b37b0c1bd, published 3 Nov at 03:16:52 UTC, with development main separately observed at the same commit. It is a security release, and the finding behind it is the shape of the risk rather than a single bug: an agent turn runs with real shell access, and everything it can read is also readable by anything that reaches the agent, such as a prompt injection. The release closes every path it found from a turn to a credential.

Provider keys — every key, including the image-generation credential and the Bedrock and Vertex credentials — now stays in the runner’s relay, and a turn receives the relay’s address and a placeholder on every base and every kind of connection: the relay signs Bedrock requests, mints Vertex access tokens, accepts only a path and never follows a redirect. A test builds every base’s turn for every connection shape with a canary key and fails if that key appears anywhere the turn can read. The instance’s own secrets no longer travel with git or the other processes the runner starts for a session, and hooks the agent leaves in its repository no longer run. Files outside the session are protected by writing into the session’s folder with the session’s own permissions, so a planted link cannot redirect a write or a cleanup elsewhere; other sessions are protected by sending the jobs that need one privately instead of on a readable command line; and saving an integration no longer lets a stored key follow a changed address or provider. There is no default password any more — the published default console password is no longer accepted, an instance without one of its own makes one at first start, and the compose file publishes the console on that machine only.

Three advisories ship with it: GHSA-cww9-m4gr-cmw5, GHSA-m479-gmx7-8r8h (reported by Omer Bar-Ness, MergeSafe) and GHSA-r37g-f5m3-523c (reported by AkshatJoshi2000). The release’s own advice: rotate provider keys after upgrading if untrusted people can start turns on your instance or your agents read untrusted content. The starter kits are rebuilt with every critical and high advisory closed — xlsx 0.20.3 pinned by checksum, DOMPurify 3.4.17, vite 6.4.5 — and a deck’s PowerPoint export now includes its diagrams and its code blocks.

This run’s rotation was interoperability and adjacent protocols, and it moved three adjacent coordinates. The ACP protocol published v1.15.0 (1 November) and v1.15.1 (2 November), with the stable v1 schema bundle at schema-v1.29.1 and the v2 prerelease at schema-v2.0.0-alpha.13 — eight prereleases past alpha.5. Every change in those two releases is marked unstable, unstable-v2 or rfd, so the stable-v1 surface this site describes is unchanged: v1.15.0 adds background work to v2 and the session/archive, session/unarchive, proxy/initialize, proxy/successor, session/status, auth/status with its auth/status_update notification and session/set_title methods, and moves the client system prompt RFD to Preview. The adapter lines moved too: codex-acp’s current stable is v2.5.0 (29 October) and claude-agent-acp’s is v0.100.0 (2 November). And the A2A CLI’s current stable is v0.3.1 (16 October), after v0.3.0 (24 September) — the page had named v0.2.0 (9 September) as current, and v0.3.0 added a --save-fileparts flag, an a2a skill command and a command-plugin framework while v0.3.1 redacts --svc-param values in config show.

Nothing else moved: UHP is still 2026-10-19 Draft, the conformance package is still 2026.10.19.post4 with 102 executable checks = 41 Core, 9 Extended and 52 Full, the released backend set is still 30 offered bases with 30 entries in the runner’s BACKENDS registry, and gateway/app.py still sets UHP_VERSION = "2026-09-28". The weekly competitive cohort was not due: it was worked on 2 November for ISO week 45, and 3 November falls in the same ISO week, so it is next due in ISO week 46, which begins on 9 November.

2 November 2026 — HarnessRouter v0.37.14, and NeMo Relay’s current stable carries breaking changes

HarnessRouter stable is now v0.37.14 from f6592b27e0d46478f895100a20827d60b538acf4, published 1 Nov at 10:24:02 UTC, with development main separately observed at the same commit. A file the agent deleted is no longer counted as one it made. Sometimes an agent deletes a file on a later turn after already handing it back, and that turn still listed the deleted file as produced: nothing could be downloaded for it, but it was counted — the session’s changed files (GET /v1/sessions/{id}/files?changed=true) reported produced: 2 beside a single file. A deletion is now recognised however it was made, so a turn lists and counts only the files that exist. PR #619.

This run’s rotation was harnesses, and the weekly competitive cohort was due — 2 November is the Monday of ISO week 45, and the cohort was last visited for week 44 on 26 October. The week-45 pair is /nemo-relay/ and /uhp-vs-mcp/.

/nemo-relay/ needed a currency correction. NeMo Relay’s current stable is 0.11.0 (28 October 2026), after 0.10.4 on 20 October, and 0.11.1-beta.1 (30 October) is a prerelease. The page’s guidance pointed at the 0.9.3 matrix and an 0.8.3 integration surface, and the 0.11.0 line carries breaking changes a reader on those releases needs before upgrading: Node.js requires 24.13.1 or later; LangChain and LangGraph tool results now arrive in the typed nemo.relay.tool_result@1 wrapper and object reconstruction requires explicit allowed_types; coding-agent hooks must be refreshed and restarted, tool checks default to fail-closed, a delivery failure returns exit code 2, and generated hooks use PreToolUse without a separate PermissionRequest hook; Relay checks client access before lending provider credentials; and automatic remote OTLP logs and metrics require HTTPS unless explicitly allowed. The page now names the current stable and those breaks, and the rows of the old matrix are recorded as re-checked against the 0.11.0 matrix — the matrix now also lists Google ADK among the framework integrations. The /uhp-vs-mcp/ route was rechecked and retained: the released MCP specification is still 2026-07-28, and the Filesystems Working Group’s charter still lists “SEP: Filesystem Operations for Resources” as Ideating, so the page’s current claims stand.

Two harness coordinates were stale. Pi’s current release is v1.4.0 (21 October 2026) — the release line moved four times since the v1.0.2 reading on 4 October — while the NeMo Relay matrix still scopes its Pi support to 0.84.x as a proof of concept, so the gap between the two is now four minor releases wide. And DeepSeek Harness now publishes two prerelease lines at once: a release-candidate line on 0.2.1 that reached dsh-v0.2.1-rc.5 (30 October), and the newer alpha line dsh-v0.2.2-alpha.2 (28 October) — so “the latest prerelease” has to name its line. That alpha line also adds an experimental subagent_oar plugin that can delegate an independent task to a local Codex or Claude CLI, and experimental change requests and worktrees that run a session in a separate Git worktree and inspect the linked pull request’s status and code changes.

Nothing else moved: UHP is still 2026-10-19 Draft, the conformance package is still 2026.10.19.post4 with 102 executable checks = 41 Core, 9 Extended and 52 Full, the released backend set is still 30 offered bases with 30 entries in the runner’s BACKENDS registry, and gateway/app.py still sets UHP_VERSION = "2026-09-28". The reference implementation’s own pins are unchanged — Mistral Vibe stays at 3.0.2 even though upstream published v3.0.4 on 30 October, and the DeepSeek Harness adapter stays at 0.1.2rc1.

1 November 2026 — the reference implementation publishes its own security review, and prepares for an opt-in scan

HarnessRouter stable is unchanged at v0.37.13 from 558a8bbbd548c57e6b5afb21541993a164a94203, published 31 Oct at 04:38:37 UTC. Development main is now one commit ahead of that tag — e94398d9c91a, PR #617, merged 31 October 2026 — and this run’s rotation (security and evaluation) is what surfaced it: the commit adds a Community Edition security review, a threat model for the self-hosted product, together with the files that prepare the project for an opt-in open-source vulnerability scanning program.

What the review covers. The threat model scopes the public code — gateway/, runner/, ui/, protocol/ and their adapters — as the self-hosted Community Edition, and explicitly excludes hosted services, real provider accounts, other people’s deployments, and third-party agent CLIs and SDKs, while keeping integration mistakes in the project’s own code in scope and treating an already-compromised host as outside the model. It describes the one-container layout it assumes: the console publishes only port 3000, the gateway and runner listen on loopback, the runner runs as root only so each agent session runs as its own uid, and the runner’s environment carries neither the login nor the secret-store key. It prioritises the boundaries: untrusted input entering the gateway or runner; authentication and access checks before reading credentials, changing instance configuration, or operating on another session’s resources; file containment, traversal and symlinks; credential forwarding into logs, errors, subprocess environments and proxy destinations; workspace authority versus other sessions, instance configuration and host resources; and UI rendering of untrusted files and agent output.

What the scanning preparation is — and is not. The repository states plainly that committing these files does not enroll the project, start a scan, or grant access to a model API. The enrollment payload points at the repository’s main branch, at a repository-hosted audit image and at that threat model, and names the contact address the security policy already publishes. The audit image keeps the full source tree in /src, installs dependencies at build time and builds the self-hosted UI, but does not start the application, authenticate to providers, or run the first-boot CLI installer; the offline check runs the repository’s own suites with --network none, and the preparation’s pull request reports 170 passing (gateway 11, runner 1, protocol 158) while noting that a green run means a patch can be tested offline in the image, not that the code is secure. The accompanying workflow validates the payload against a pinned upstream validator, builds the image and runs that offline check on main and weekly — it checks the environment only, and does not submit an enrollment or invoke a model scan. Enrollment is a separate maintainer action that needs the program’s agreement and its contribution and licence requirements reviewed first, and acceptance is at the program’s discretion. The project is not enrolled and no scan has run.

Everything else is unchanged. UHP is still 2026-10-19 Draft, the conformance package is still 2026.10.19.post4 with 102 executable checks = 41 Core, 9 Extended and 52 Full, the released backend set is still 30 offered bases with 30 entries in the runner’s BACKENDS registry, and gateway/app.py still sets UHP_VERSION = "2026-09-28". This is adjacent implementation evidence on a protocol site: the protocol’s own security obligations are unchanged, and the site’s documented-versus-interpretation table still applies.

Evidence gap: the IETF identity, enrollment and assurance drafts this site’s security guide tracks — AEP, the AIC identity-certificate profiles, AADP, AEB, the delegation-chain draft, the correctover conformance-shape draft and the DAWN discovery framework — could not be re-verified, because the IETF Datatracker, its static archive and the IETF mail archive all answer a Cloudflare challenge to this sandbox. Their recorded revisions are left as they were and the gap is reported rather than filled by inference. The weekly competitive cohort was visited for ISO week 44 on 26 October, and 1 November is the last day of that ISO week, so it was not yet due and was not revisited; it is due on Monday 2 November.

31 October 2026 — HarnessRouter v0.37.13, and MCP Server Cards’ charter is final

HarnessRouter stable is now v0.37.13 from 558a8bbbd548c57e6b5afb21541993a164a94203, published 31 Oct at 04:38:37 UTC. Development main was separately observed at the same commit as the stable tag. The release renames the starter kit formerly called My Workplace to Harness Bot and — the part with a contract behind it — lets a renamed kit keep what was launched under its old name: kit.json can now declare aliases, harness.replaces_packages and harness.replaces_names, and the server reads them, so a setup launched under an old kit id belongs to the kit, the current package takes an old package’s place on the next launch instead of being installed beside it, and a setup still called exactly one old default name takes the kit’s current name. Nothing else moved with it: the released backend set is still 30 offered bases with 30 entries in the runner’s BACKENDS registry, the conformance package is still 2026.10.19.post4 with 102 executable checks = 41 Core, 9 Extended and 52 Full, UHP is still 2026-10-19 Draft, and gateway/app.py still sets UHP_VERSION = "2026-09-28". The registry was re-read at v0.37.13 on 31 October 2026 and holds the same 30 entries.

This run’s rotation was discovery and execution, and it corrected a maturity claim that had gone stale on two pages. SEP-2127 — MCP Server Cards — was merged into the MCP specification repository on 6 October 2026 with status Final. It is an Extensions Track document that names the extension identifier io.modelcontextprotocol/server-card and charters the Server Card Working Group. /uhp-vs-ard/ and /uhp-vs-mcp/ both still said SEP-2127 “remains open and unmerged” and “is still an open, unmerged proposal”; that was true when written and false now. The correction keeps the boundary the two pages were drawing, because the wire format is still maintained in the repository named experimental-ext-server-card, whose own README says the work is for prototyping and feedback and is not an accepted or official MCP extension — while its remark that “the SEP itself is still under review” has been overtaken by the merge. So the charter is final and the extension is not yet accepted or released.

The same rotation found that the ARD specification’s text has advanced past the reviewed v0.91 draft — PRs #80, #105, #106 and #111 merged between 11 and 25 October 2026 — while its version block still reads v0.91 and 26 August 2026, so “published v0.91” names a file that is still moving rather than a frozen text. /uhp-vs-ard/ now states what moved: §3.3 makes type an open media-type string and lists the recognized types, with the specification’s own IANA note saying those types are de-facto community standards tracking towards registration and that intermediaries should omit strict verification of them; the discovery identifier’s URN form now makes <namespace> optional; attestation scopes were clarified; and a new informative §5.5 Observability section describes W3C Trace Context correlation, names federated registries as trust boundaries, and states that trace context is operational metadata — not ARD entry data, not a trustManifest claim, not an authorization grant and not a relevance-score input.

Evidence gap: the IETF identity and discovery drafts these pages cite — the DAWN agent-discovery framework draft and the charter state the Datatracker records — could not be re-verified, because the IETF Datatracker and its static archive both answer a Cloudflare challenge to this sandbox. Their recorded revisions are left as they were and the gap is reported rather than filled by inference. The weekly competitive cohort was last visited for ISO week 44 on 26 October and this run falls in the same ISO week, so it was not yet due and was not revisited.

30 October 2026 — HarnessRouter v0.37.12, and a retried harness create no longer makes a second harness

HarnessRouter stable is now v0.37.12 from 5520b956ffc15373a89ddfe00d944c271661f21a, published 29 Oct at 18:50:37 UTC, after two further stable releases on the same evening: v0.37.11 at 17:15:36 UTC and v0.37.12 at 18:50:37 UTC. Development main was separately observed at the same commit as the stable tag.

A retried harness create no longer makes a second harness. POST /v1/harnesses now honours an Idempotency-Key, as a task already did. When a create reached the server but its answer was lost — a timeout, a dropped connection — the client could not tell whether the harness existed, and its retry made a second one. With a key, a repeat answers with the harness the first request created, a repeat that is still writing waits for that harness rather than answering not found, the same key with a different request is refused 409 idempotency_key_reused, and once the harness a key created is deleted the key names none and a repeat creates one. A key belongs to the workspace the harness is made in and is kept for 24 hours, and the server reports the new harness_idempotency capability. Deploy to Cloud sends a key on each create, so a deploy whose answer was lost no longer leaves a second copy in Cloud — the known issue since 0.36.3 — and sends one only to a Cloud that reports the capability.

A refused turn says why, when the agent could not read the refusal. A Qwen Code turn refused by vLLM 0.10.0 or older failed with only API Error: 400 status code (no body): Qwen Code reads a refusal’s reason only under an error key and those vLLM versions put message at the top level, so the one thing a person could fix — a context window too small for the request — was never shown, while the runner’s relay had read vLLM’s sentence all along. A failed turn now gives the provider’s own words whenever the reason it would otherwise show lacks them, for every agent harness whose calls go through the relay. An agent that already says the reason keeps its own sentence, and only the turn’s last call counts.

The protocol gained the create-key contract inside 2026-10-19 itself. The normative text is in Harnesses §5.1: a client MAY send Idempotency-Key on a create, and a server that reports harness_idempotency MUST keep the key for at least 24 hours in the caller’s scope and answer a repeat with the harness the first request created. Under UHP’s versioning rules an optional request header and a new capability fit within a version, so the protocol version is unchanged — but the current draft now carries text it did not carry on publication, and the conformance package moved with it: 2026.10.19.post4, 102 executable checks = 41 Core, 9 Extended and 52 Full, the new F-10 checking the create-key contract on a server that reports the capability and skipping it on one that does not.

Nothing else moved: the released backend set is still 30 offered bases with 30 entries in the runner’s BACKENDS registry, re-read at v0.37.12 on 30 October 2026 — the two releases changed the harness-create contract and the relay’s refusal handling, not the set of bases. gateway/app.py still sets UHP_VERSION = "2026-09-28", and CE still advertises input_history while still not advertising memories or harness_retirement.

This run’s rotation was memory and identity, and it corrected a stale coordinate on five pages. The stable Hermes release is no longer v2026.9.24 / Agent v0.21.5: since v0.21.6 the release tag is the agent version itself, and the current stable is Agent v0.22.5, published 23 October 2026 at commit bf0203a794a. A fresh ancestry check confirms the memory-mutation commit d57c2a32, the compaction fixes through d79b8fb6, the repair merge 67757285 and the stop fan-out merge b7135906 are all still ancestors of that release and of current main, so the guidance on /memory-mutation-identity/, /context-compaction/, /durable-state-repair/, /agent-control-delivery-evidence/ and /hermes/ stands — with its “current stable” anchor corrected. The memory side of UHP did not move: the Memories chapter is byte-identical at v0.37.10, v0.37.12 and main, the 13 ME- checks are unchanged, and CE still advertises no memories capability. Evidence gap: the IETF identity drafts the security guide cites could not be re-verified, because the IETF Datatracker and its static archive both answer a Cloudflare challenge to this sandbox; their recorded revisions are left as they were and the gap is reported rather than filled by inference. The weekly competitive cohort was last visited for ISO week 44 on 26 October and this run falls in the same ISO week, so it was not yet due and was not revisited.

29 October 2026 — HarnessRouter v0.37.10, and the ACP adapter’s current stable is v2

HarnessRouter stable is now v0.37.10 from 3fa39ad1947f9a3d1526e7d1814399498f7b1be0, published 29 Oct at 00:38:16 UTC, after two further stable releases on 28 and 29 October: v0.37.9 at 28 Oct 23:44:34 UTC and v0.37.10 at 29 Oct 00:38:16 UTC. Development main was separately observed at the same commit as the stable tag.

v0.37.9 makes a produced file appear as soon as its turn is written — the console’s second read had waited for a field this edition’s server does not send — and lets Qwen Code work with a model whose window is smaller than the cap Qwen Code picks: Qwen Code puts its own max_tokens on every request (64000 for most names, 16384 for gpt-6.1-sol, 32000 for a name it does not know), so a self-hosted model served with a smaller window refused every turn, and HarnessRouter now drops that field on Qwen Code’s requests as it already does for Kimi Code, OpenHands and Vibe. v0.37.10 gives every setup screen one bar and moves DeepSeek Harness model calls onto the runner’s relay — the harness had run a relay of its own inside its driver, which held the provider key and lacked most of what the runner’s relay does; the key no longer enters the driver’s process, and a refused, dropped or timed-out connection now ends the turn with an error instead of a dead connection.

The ACP adapter’s current stable is v2.3.0, not v1.12.0. The codex-acp line moved to v2.0.0 on 28 September with a breaking change to the AIR tool call contract, and v2.3.0 (26 Oct) re-adds ACP v2 support, reports the model of each native subagent session and returns initial ACP v2 session commands. The ACP comparison now separates the v1 adapter release that carried the programmatic tool name from the current adapter line. The upstream DeepSeek Harness prerelease is now dsh-v0.2.2-alpha.2 (28 Oct), with the ACP mode still being fixed in the v0.2.x line; the DeepSeek Harness guide now says which revision its ACP detail was inspected at.

Nothing else moved: the released backend set is still 30 offered bases with 30 entries in the runner’s BACKENDS registry, re-read at v0.37.10 on 29 October 2026 — the two releases changed model coverage and relay behaviour, not the set of bases, and the four bases added in v0.37.0 keep the same pins. UHP is still 2026-10-19 Draft, the conformance package is still 2026.10.19.post3 with 101 executable checks = 41 Core, 9 Extended and 51 Full, and gateway/app.py still sets UHP_VERSION = "2026-09-28".

This run’s rotation was interoperability and adjacent protocols, and the adjacent primaries were checked directly.

The same day’s continuity check corrected the page’s remaining ACP coordinates. The comparison’s current statements were still the 18 September ones: the dedicated Rust SDK was named v2.2.0 where the current release is v3.6.0, and the TypeScript SDK v1.4.0 where it is now v2.1.0 (both 28 October 2026); the protocol’s v2 prerelease was named schema-v2.0.0-alpha.5 where the current prerelease is schema-v2.0.0-alpha.10, and the stable v1 schema bundle is schema-v1.27.0 (27 October 2026). ACP’s stable wire version is still 1 and v2 is still a draft, which is the comparison’s actual point. The dated September facts stay as they were, and the comparison’s UHP frame is now stated explicitly: it was written against the 2026-10-04 Draft and has not been re-run against 2026-10-19. The ACP protocol published v1.13.0 on 27 October, and every change in it is unstable or unstable-v2 — terminal size, ResourceLink.size, _meta additions, non-null request ids, version-mismatch errors and stricter cursor parsing — so the stable-v1 surface this site describes is unchanged. MCP’s dated specification is still 2026-07-28, its Tasks extension still v0.2.2, and ext-apps moved to v2.0.4 with no change to the @modelcontextprotocol/ext-apps library API. A2A is still v1.0.1, and the ACP registry keeps publishing daily distribution metadata. The weekly competitive cohort was last visited for ISO week 44 on 26 October and this run falls in the same ISO week, so it was not yet due and was not revisited.

28 October 2026 — HarnessRouter v0.37.8, and how model coverage is decided per base

HarnessRouter stable is now v0.37.8 from b2091142cdca2f1d0cbaffc3e0e42c983dc88b24, published 27 Oct at 20:24:45 UTC, after five stable releases inside that day: v0.37.4 at 05:35:18 UTC, v0.37.5 at 06:10:47 UTC, v0.37.6 at 06:43:39 UTC, v0.37.7 at 08:54:40 UTC and v0.37.8 at 20:24:45 UTC. Development main was separately observed at the same b2091142cdca commit as the stable tag.

The five releases are almost entirely about the four bases added in v0.37.0. v0.37.4 makes Deep Agents Code default to gpt-6.1-sol like the Responses API bases, while Mistral Vibe, Docker Agent and fast-agent keep gpt-5.4 on the connections that refuse gpt-6.1-sol for a request carrying function tools. v0.37.5 lets fast-agent’s image-reading models see images, because the runner now tells it what the turn’s model reads instead of letting its own table decide, and fits a conversation’s images to what the current model takes. v0.37.6 stops fast-agent giving up on a slow model before HarnessRouter does. v0.37.7 treats Nemotron 3 Super as text-only, sends a Gemini thought signature only to the model that made it, gives DeepSeek Harness the setup’s and plugin’s skills, and switches off DeepSeek Harness’s built-in web search, which calls DeepSeek’s own service outside the chosen model connection and always failed with an authentication error. v0.37.8 withdraws two harness and model pairs — fast-agent with Gemini 4 Argon on Google’s own API, and Docker Agent with Grok 4.20 — after both failed in deck conversations that switched models partway.

The reference guide now explains the rule behind those decisions. Model coverage is decided per base and per connection: a base offers only the models it was measured to run, a conversation’s images are fitted to what the current model takes, and the same model can be offered on one base and withheld on another. The HarnessRouter guide carries that guidance with the transport split that decides it.

Nothing else moved. The released backend set is still 30 offered bases with 30 entries in the runner’s BACKENDS registry, re-read at v0.37.8 on 28 October 2026 — the five releases changed model coverage and per-base behaviour, not the set of bases. UHP is still 2026-10-19 Draft, the conformance package is still 2026.10.19.post3 with 101 executable checks = 41 Core, 9 Extended and 51 Full, and gateway/app.py still sets UHP_VERSION = "2026-09-28".

This run’s rotation was the harnesses cluster. The tracked upstream harness projects were surveyed for new releases, and Codex rust-v0.166.0-alpha.5, Claude Code v2.1.312, OpenHands v1.34.0, OpenCode v2.2.0, Qwen Code v0.26.3-preview.0, a Gemini CLI nightly, Cline v4.1.26, Oh My Pi v18.13.2, a DeepSeek Harness alpha and Mistral Vibe v3.0.3 all moved since 26 October. An upstream version number moving is not a publication reason on its own, and the harness pages hold dated, pinned evidence whose scope their own notes state, so what the cluster produced was HarnessRouter’s own per-base model-coverage behaviour rather than a new upstream fact to publish. The weekly competitive cohort was last visited for ISO week 44 on 26 October and this run falls in the same ISO week, so it was not yet due and was not revisited.

27 October 2026 — HarnessRouter v0.37.3, and four new harness bases

HarnessRouter stable is now v0.37.3 from ef9e12e29b61c7bb913a767a7bf1bee96e851ef8, published 26 Oct at 23:29:42 UTC, after four stable releases inside that day: v0.37.0 at 05:37:39 UTC, v0.37.1 at 10:59:27 UTC, v0.37.2 at 17:38:34 UTC and v0.37.3 at 23:29:42 UTC. The v0.37.4-rc.1 candidate published on 27 October is a prerelease and is not a coordinate.

v0.37.0 adds four harness bases, each measured end to end on every provider before release: Mistral Vibe 3.0.2, Docker Agent 1.152.0, fast-agent 0.10.47 and deepagents-code 0.2.1, the last driven over the Agent Client Protocol. The released backend set moves from 26 to 30, and the runner’s BACKENDS registry now holds exactly those 30 entries — Gajae-Code, which the previous stable implemented but did not offer, is no longer in the registry, so the registry and the product’s default HR_BACKENDS set now agree for the first time. v0.37.1 makes fast-agent and Deep Agents Code show each step as it happens, with fast-agent running over its own ACP server; v0.37.2 withdraws nemotron-3.5-lightning from three of the new bases after it wrote deliverables outside the workspace; v0.37.3 lets fast-agent reach MCP servers whose address does not end in /mcp and stops docker-agent running part of the officecli skill as a command.

Nothing else moved: UHP is still 2026-10-19 Draft, the conformance package is still 2026.10.19.post3 with 101 executable checks = 41 Core, 9 Extended and 51 Full, gateway/app.py still sets UHP_VERSION = "2026-09-28", and CE still advertises the optional input_history capability while still not advertising memories or harness_retirement. Development main was separately observed at the same ef9e12e29b61 commit as the stable tag.

This run’s rotation was security and evaluation. UHP’s own security surface is unchanged: the protocol version, the conformance package and the stable release all are, and the 2026-10-19 Security chapter is byte-identical at v0.37.3, v0.36.4 and main. The evaluation surface is the conformance package, likewise unchanged at 101 checks. The IETF identity drafts the security guide cites could not be re-verified: the IETF Datatracker and its static archive both answer a Cloudflare challenge to this sandbox, so their recorded revisions are left as they were and the gap is reported rather than filled by inference. The weekly competitive cohort was last visited for ISO week 44 on 26 October and this run falls in the same week, so it was not yet due and was not revisited.

A page that contradicted itself, corrected the same day. The /harnessrouter/ page was refreshed to v0.37.3 and to 30 released backends, and its coordinate table was updated, but the Backend set paragraph underneath still read “The released backend set is now 26” and still listed only the 26 bases that shipped before v0.37.0 — while the paragraph directly below it claimed the registry and the product’s default HR_BACKENDS set now hold exactly the 30 bases the product offers, “so the count above is the number of bases the product actually offers”. The paragraph and its list now read 30 and name Mistral Vibe, Docker Agent, fast-agent and Deep Agents Code, the four bases v0.37.0 added. Six pages — /adoption/, /conformance/, /ecosystem/, /getting-started/, /harnessrouter/ and /what-is-uhp/ — also carried the machine-readable review date 2026-10-27 next to the visible text “25 Oct 2026”; the visible text now reads 27 October 2026, as /docker-agent/ and /deep-agents/ already did. No coordinate moved: the site-wide count was never in doubt, and the table, the homepage, /adoption/, /ecosystem/, llms.txt and the status file already said 30.

26 October 2026 — AHP reaches 1.0.0, and two pages that contradicted themselves are corrected

HarnessRouter’s stable release is unchanged at v0.36.4 (edca78bffa40), with development main at the same commit; the v0.37.0-rc candidates published on 25 October are release candidates and were not published as coordinates. UHP is still 2026-10-19 Draft, the conformance package is still 2026.10.19.post3 with 101 executable checks = 41 Core, 9 Extended and 51 Full, and the released backend set is still 26 offered bases with 27 entries in the runner’s BACKENDS registry, re-read at v0.36.4 on 26 October 2026. gateway/app.py still sets UHP_VERSION = "2026-09-28", CE still advertises the optional input_history capability, and it still does not advertise memories or harness_retirement.

Microsoft’s Agent Host Protocol published spec/v1.0.0 on 2 October 2026, and this site’s AHP comparison had not caught up with its own introduction. The page’s frontmatter, lead and opening paragraph already named spec/v1.0.0 released 2 October 2026, but its architectural comparison table still said the published spec was 0.9.0 (28 Aug 2026) and that the UHP side was the 2026-08-11 draft, and its “Current AHP status” section still called AHP pre-1.0. The table now states 1.0.0 and the UHP 2026-10-19 draft the comparison actually uses — the 2026-10-19 deltas are the two optional capabilities, earlier-turns and per-turn timestamps, none of which changes a row of the comparison — the status section states the 1.0.0 SemVer and channel-stability table, adding Canvas as Experimental, and the page records the four further open-source AHP hosts and client tools the upstream repository now lists.

The HoH-lite availability claim was wrong twice over. The project’s README has announced HoH-lite as available since 24 September 2026, and this site’s page said so in its current guidance — while “Status first” still said the repository “explicitly says HoH-lite … is coming soon” and the evidence limits still said HoH-lite “is not yet publicly released”. “Status first” now dates the “coming soon” wording to the 4 September snapshot, and the evidence limit is restated accurately: HoH-lite is published, but it is a lightweight implementation of the core workflow, and the paper’s benchmark and multi-day results still need the benchmark checkout, Node.js/npm, bubblewrap, Xvfb, xdotool and FFmpeg, so they are not reproducible from the packaged runtime alone.

This run’s weekly cohort was the week-44 pair, /uhp-vs-ahp/ and /harness-of-harness/, and both routes are recorded in the sanitized competitive queue. The rotation cluster was discovery and execution: UHP’s own discovery and execution surface is unchanged, because the protocol version, the conformance package and the stable release all are; the adjacent discovery work checked was the ACP registry’s distribution-metadata releases, which change the versions the registry distributes rather than the protocol. The IETF identity drafts the security guide cites could not be re-verified: the IETF Datatracker and its static archive both answer a Cloudflare challenge to this sandbox, so their recorded revisions are left as they were and the gap is reported rather than filled by inference.

25 October 2026 — HarnessRouter v0.36.4, and MCP’s first agent-discovery draft

HarnessRouter stable is now v0.36.4 from edca78bffa40418a00f3c7bc524b2ba9890caecc, published 25 Oct at 02:42:30 UTC, after two stable releases on 24 and 25 October: v0.36.3 at 24 Oct 06:35:09 UTC and v0.36.4 at 25 Oct 02:42:30 UTC. v0.36.3 fixes Deploy to Cloud for a setup’s second destination, stores a codex command’s output whole, and answers a shared link with 503 when its Task cannot be read. v0.36.4 keeps a setup’s open task on screen when the window narrows to a phone, and stops codex’s own warnings being listed as tool calls.

One protocol-surface fact is worth naming. A function_call_output item now has status: "incomplete" when the tool’s output could not be read in full, instead of "completed". The release states that this stays within UHP 2026-10-19: the schema leaves an output item’s status an open string, and "incomplete" is the value a response already uses for work that did not finish. The Tasks §3.1 example still shows "completed", so a client that assumes every tool output is completed is reading a field the specification does not fix. The lifecycle guide now says so.

Nothing else moved: UHP is still 2026-10-19 Draft, the conformance package is still 2026.10.19.post3 with 101 executable checks = 41 Core, 9 Extended and 51 Full, and the released backend set is still 26 offered bases with 27 entries in the runner’s BACKENDS registry, re-read at v0.36.4 on 25 October 2026. gateway/app.py still sets UHP_VERSION = "2026-09-28", CE still advertises the optional input_history capability, and it still does not advertise memories or harness_retirement.

MCP’s agent-facing track has produced its first concrete draft. Agents WG PR #22 merged on 20 October at 18:24:03 UTC, adding proposals/0000-mcp-agent-discovery-extension.md: a Draft Extensions Track proposal with the proposed extension identifier io.modelcontextprotocol/agents. A host would first retrieve a compact roster of agent names, descriptions and capability labels, then retrieve the instructions and scoped MCP tool schemas for the agent it selected, and execute through the existing MCP tool-calling mechanism on the same server. The draft states that it does not turn an MCP server into an autonomous agent runtime and reuses the existing cache model for freshness. It is a merged draft in an incubation repository, not a released extension; the MCP comparison records it with that boundary.

This run’s rotation was memory and identity. The UHP Memories chapter is byte-identical at main and v0.36.4, and the reference implementation still advertises no memories capability, so the guide’s standing statement that the optional Memories chapter is not established in the reference implementation stands unchanged. The IETF identity drafts the security guide cites — the Agent Enrollment Protocol, the two AIC drafts, AADP and AEB — could not be re-verified today: the IETF Datatracker and its static archive both answer a Cloudflare challenge to this sandbox, so their recorded revisions are left as they were and the gap is reported rather than filled by inference. The weekly competitive cohort was last visited on 20 October, in ISO week 43, and this run falls in the same ISO week, so it was not yet due and was not revisited.

24 October 2026 — HarnessRouter v0.36.2, and the first optional UHP capability the reference implementation advertises

HarnessRouter stable is now v0.36.2 from 66eb6e55f956c9d5fcfee55d504bf39954a0be57, published 23 Oct at 21:38:52 UTC, after three stable releases on 23 October: v0.36.0 at 09:27:53 UTC, v0.36.1 at 19:57:09 UTC and v0.36.2 at 21:38:52 UTC. v0.36.0 is a minor release: it brings the redesigned console to self-hosted instances — Start, Studio, Shop, Add-ons, API Keys, Bring your own key, Profile and Workspaces, with the old addresses redirecting — and it lets a setup deploy to HarnessRouter Cloud from one button.

The protocol-facing change is the optional input_history capability. POST /v1/responses can bring a task’s earlier turns: with no previous_response_id and no session named, the user and assistant messages before the last user message become the task’s first turn, marked imported, with no model and no cost. UHP_CAPABILITIES in gateway/app.py now carries "input_history": True with the source comment citing Tasks §2.1, and GET /v1/uhp and GET /v1/bases report it. That is the first optional capability from UHP 2026-10-19 the reference implementation has advertised, so this site’s standing claim that no server advertises input_history is now false, and the pages carrying it are corrected. The optional memories and harness_retirement capabilities are still advertised by no server, and the UHP version, the schema and the conformance denominator do not change: the package is still 2026.10.19.post3 with 101 executable checks = 41 Core, 9 Extended and 51 Full.

No conformance check exercises input_history. checks.py at v0.36.2 holds no reference to it, so a conformance report cannot establish that capability; a client reads it from GET /v1/uhp. A capability an implementation advertises and a suite that never measures are two different facts, and a reader integrating against it needs both.

Nothing else moved: UHP is still 2026-10-19 Draft, the released backend set is still 26 offered bases with 27 entries in the runner’s BACKENDS registry, re-read at v0.36.2 on 24 October 2026, and gateway/app.py still sets UHP_VERSION = "2026-09-28", so the served version string still lags the features the same tree implements.

Correction to yesterday’s entry: v0.35.15 was published at 07:08:17 UTC, not the 06:58:12 UTC author date of the commit it was cut from. The other three releases in that line carried their publication times, so the entry mixed two sources; all four now carry the release publication time.

This run’s rotation was interoperability and adjacent protocols. MCP’s dated specification is still 2026-07-28 and its Tasks extension still v0.2.2; A2A is still v1.0.1; ACP is still v1.12.0. The ACP registry published five distribution-metadata releases on 23 and 24 October, moving factory-droid to 0.249.0, claude-acp to 0.94.1-preview.12 and codex-acp to 2.2.3-preview.27; those change the versions the registry distributes, not the protocol. The weekly competitive cohort was last visited on 20 October, in ISO week 43, and this run falls in the same ISO week, so it was not yet due and was not revisited.

23 October 2026 — coordinates refreshed to HarnessRouter v0.35.17

HarnessRouter stable is now v0.35.17 from 7f036edf545b5c55582c31f5750b70f24fa079c9, published 22 Oct at 09:58:40 UTC, after the four stable releases of 22 October described in the entry below. The four releases are one theme: a read that could not be made whole is reported instead of being answered from what happened to be there. A video’s canvas is never wiped by a failed read; a transcript is never shown with a hole in it; a response that could not be read answers 503 to try again instead of a permanent response_not_found; a download of files that cannot be made whole answers file_not_found; the storage total is never a false zero. v0.35.14 also makes gpt-6.1-sol the default model where gpt-5.4 was, on the ten harnesses where it passed every check on the OpenAI, Azure and TokenRouter connections, and makes a failed task name the harness and the tool that failed.

Nothing else moved. UHP is still 2026-10-19 Draft, the conformance package is still 2026.10.19.post3 with 101 executable checks = 41 Core, 9 Extended and 51 Full, and the released backend set is still 26 offered bases with 27 entries in the runner’s BACKENDS registry, re-read at v0.35.17 on 23 October 2026. gateway/app.py still sets UHP_VERSION = "2026-09-28" at v0.35.17 and on main, and no server advertises the optional memories, harness_retirement or input_history capabilities. The 2026-10-19 protocol chapters are byte-identical at v0.35.13 and v0.35.17 — every file in that directory has the same blob — so the source citations across this site are repointed at the current stable tag without changing a normative word.

A second correction, on the security page: it described F-09 as a check new at package 2026.10.19.post3, alongside 100 existing checks. F-09 is new in the base 2026.10.19 suite, and post3 is the package that adds T-12, the step-budget check. The page now says that.

This run’s rotation was the harnesses cluster. The tracked upstream harness projects were checked for a native UHP implementation, and none of them names UHP in its README or its recent releases, so native adoption remains not established for every one of them; the harness pages’ own version pins stay revision-bounded historical evidence, as their scope notes say. The weekly competitive cohort was last visited on 20 October, in ISO week 43, and this run falls in the same week, so it was not yet due and was not revisited. v0.36.0-rc.1 through v0.36.0-rc.4 are release candidates; a candidate is evidence of what is being prepared, not of what a reader would install, so no coordinate changes on their account.

22 October 2026 — coordinates re-verified; a correction to what conformance check T-12 enforces

The core coordinates were re-checked against primary sources on 22 October 2026 and none of them moved. UHP is still 2026-10-19 Draft, HarnessRouter stable is still v0.35.13 from 3668370c1025, the conformance package is still 2026.10.19.post3 with 101 executable checks = 41 Core, 9 Extended and 51 Full, and the released backend set is still 26 offered bases with 27 entries in the runner’s BACKENDS registry. gateway/app.py still sets UHP_VERSION = "2026-09-28", and no server advertises the optional memories, harness_retirement or input_history capabilities.

Correction to the first version of this entry: the day did end with stable releases. After the release candidates published earlier — v0.35.14-rc.1 through v0.35.14-rc.3 and v0.36.0-rc.1 — HarnessRouter published v0.35.14 at 05:35:08 UTC, v0.35.15 at 07:08:17 UTC, v0.35.16 at 08:00:22 UTC and v0.35.17 at 09:58:40 UTC, taking stable to v0.35.17 from 7f036edf545b. The candidates were superseded by them. The site’s HarnessRouter coordinate was refreshed to v0.35.17 on 23 October 2026, and the four releases are recorded in the release tracker.

Correction to the 21 October entry: T-12 was described there as a Core check that constrains the timeout path. It is a Full check, and it constrains the step budget. The check sends max_step: 1 for work that needs three tool-call rounds, and requires the task to end incomplete and name the budget that stopped it; a server that cannot bound its base names max_step in metadata.ignored_fields and passes. No check in the suite exercises the timeout_seconds wall-clock budget. The same description is corrected on the conformance and lifecycle pages, and the security and lifecycle pages’ normative version labels and primary-source links were corrected to the same standard.

21 October 2026 — HarnessRouter v0.35.13, three releases in one day, conformance 2026.10.19.post3 (101 checks)

HarnessRouter shipped v0.35.11, v0.35.12 and v0.35.13 between 03:12 and 08:10 UTC. Stable is now v0.35.13 from 3668370c1025, published 21 Oct at 08:10:14 UTC. All three releases change how a task reports its own end, which is where a client integration is most often wrong.

• v0.35.11 — interrupted work now says so. A task cut short by a server restart, or by the gateway shutting down, ends failed with {"type": "harness_error", "code": "harness_error", "detail": {"reason": "interrupted"}} and a plain sentence; a task past the hard time limit says "reason": "timeout". Before, such a task could end failed with no error at all, or completed with no output. On self-hosted installs, the files an interrupted task wrote survive a recreated container, because the checkpoint markers moved to the data volume (HR_WS_MARKER_DIR → /data/ws-markers). A task restoring a large workspace keeps its heartbeat, so it is no longer taken for a dead one while it starts, and the hard time limit is the runner’s limit plus a 30-minute margin (HARNESS_CAP_MARGIN_S). A caller’s W3C traceparent and tracestate now reach the agent’s environment (TRACEPARENT), and every model call carries a child traceparent.
• v0.35.12 — a task waiting past the limit is failed, and never starts. A task still waiting when the hard time limit passes — queued for a free slot, or restoring a workspace that hangs — ends failed with "reason": "timeout" in its response record as soon as it is settled, so a client polling GET /v1/responses/{id} sees it end. Before, the session said failed while the response record stayed in_progress. Once settled, such a task never starts its agent; before, it ran anyway and finished as completed after being settled as timed out. PR #539.
• v0.35.13 — a conversation is never answered empty. GET /v1/sessions/{id}/turns and a shared link’s turns answer 503 with type: server_error when the server cannot read the conversation, instead of 200 with the unreadable turns left out, so a finished task can no longer look shorter than it was, or new and empty. The console shows “This task could not be read just now.” with a Try again action, and a shared link shows “This conversation could not be loaded just now.”; Send stays off until a read succeeds. A task’s latest turn always shows in its conversation, even when the session’s list of turns did not record it. /readyz gains turns_reads, counting failed conversation reads and writes and turns shown from the session. The publisher records one known item on this release and on 0.35.12: Aider with gpt-5.4-mini answered a request to create a file without creating it, on the release day, having passed the same check the day before.

The conformance suite moved to 2026.10.19.post3 at v0.35.11, which adds T-12, a Full check that measures the step budget: a task sent with max_step: 1 whose work needs three tool-call rounds must end incomplete and name the budget, or a server that cannot bound its base names max_step in metadata.ignored_fields and passes. It is the first check to constrain a budget rather than a capability or a status vocabulary. The registry is now 101 executable checks = 41 Core, 9 Extended, 51 Full, the Full count rising by one.

Development main was separately observed at 3668370c1025 on 21 October 2026, matching stable at this check. gateway/app.py still sets UHP_VERSION = "2026-09-28", so the served version string still lags the features the same tree implements. The released backend count remains 26, and the runner BACKENDS registry was re-read at v0.35.13 and still holds those same 27 entries, the extra being Gajae-Code, implemented in the runner and deliberately not offered. No server advertises the optional memories, harness_retirement or input_history capabilities, so native adoption of those chapters remains not established.

20 October 2026 — HarnessRouter v0.35.10, four releases in one day, conformance 2026.10.19.post2 (100 checks)

HarnessRouter shipped v0.35.7, v0.35.8, v0.35.9 and v0.35.10 between 07:01 and 00:48 UTC. Stable is now v0.35.10 from caa3c0a1, published 20 Oct at 00:48:17 UTC.

v0.35.7 is the release that matters: it carries the remaining UHP 2026-10-19 additions into the product.

• A new task may bring its earlier turns (PR #520, Tasks §2.1). With input_history, the messages before the last user message are the conversation so far, kept as the session’s first turns marked imported.
• Each turn says when it began and ended (PR #521, Sessions §3). Turns carry created_at and completed_at in Unix seconds; completed_at is null while the turn runs or when its end is not known.
• Background responses now report in_progress, which is UHP’s name for the only non-terminal state; a client that checked for running should check for in_progress. An idempotent replay whose original response is gone answers 404 response_not_found instead of 200 with "status": "unknown". A produced file over the attachment cap is named in the answer and stays in the task’s files, and the cap is now 64 MiB (HARNESS_RESP_MAX_FILE_BYTES, was 25 MiB). A cancel answered cancelled now holds even when sent the moment a background task starts.

v0.35.8 (11:55 UTC) deprecates the harness models view’s fallback field, following UHP 2026-10-19 Harnesses §3 — it only ever repeats default, nothing changes on the wire, and it is removed no earlier than the second version after 2026-10-19. v0.35.9 (13:37 UTC) keeps aider’s automatic file-add chatter out of the reply. v0.35.10 fixes an aider edit-only reply that came out as just the file’s name, and ages a heartbeat-less running session from its birth or turn start rather than from 1970, so the cleanup sweep can no longer fail a task that just started.

The conformance suite moved to 2026.10.19.post1 at v0.35.7, which adds T-11: a background task read while it runs must report in_progress. The check records a measured case — on 0.35.0-rc.2, HarnessRouter answered a background POST and every poll until the turn ended with running while its own stream emitted in_progress for the same turn. post2 at v0.35.8 changes no check or verdict. The registry is now 100 executable checks = 41 Core, 9 Extended, 50 Full, the Core count rising because T-11 is a Core check.

Development main was separately observed at caa3c0a1 on 20 October 2026, matching stable at this check. gateway/app.py still sets UHP_VERSION = "2026-09-28", so the served version string still lags the features the same tree implements. The released backend count remains 26, with 27 entries in the runner BACKENDS registry (Gajae-Code is implemented in the runner and deliberately not offered). No server advertises the optional memories, harness_retirement or input_history capabilities, so native adoption of those chapters remains not established.

19 October 2026 — UHP 2026-10-19, HarnessRouter v0.35.10, conformance package 2026.10.19.post2 (99 checks)

The official UHP site now lists 2026-10-19 as the latest Draft. It is additive to 2026-10-04 (one rule changes, the rest is additive): a server that reports the new harness_retirement capability may retire a harness’s sessions and responses with it under a stated restore window, a new task may bring its earlier turns under the new input_history capability, and harness writes now refuse what they cannot store (a default_model its base does not run, a field the harness does not have) with 422. UHP Errors §3.1 splits model_unavailable (the model the request named) from model_not_available (a harness create or update named a default_model its base does not run).

HarnessRouter shipped four releases in the last 24 hours: v0.35.2 (npm dist-tags, SQL driver cap, step budget), v0.35.3 (the README and implementations page name all 26 harness bases; aider nudges), v0.35.4 (an Environment build that stopped without recording its end is read as failed), v0.35.5 (UHP 2026-10-19 retirement and the two error moments; adds the F-09 Full check) and v0.35.10 (gateway: a model it cannot serve is 422 model_unavailable; aider file-writing turn answers in words). Stable is v0.35.10 from caa3c0a1; the released backend count remains 26 (the runner’s BACKENDS registry holds 27, the extra being Gajae-Code, implemented in the runner and deliberately not offered). The conformance package is 2026.10.19.post2 with 100 executable checks (41 Core, 9 Extended, 50 Full), including the 13 ME- Memories checks and the new F-09 retirement check.

Development main was separately observed at caa3c0a1 on 19 October 2026; it still advertises UHP 2026-09-28 in gateway/app.py and has not yet adopted the 2026-10-19 capabilities, while the v0.35.5 / v0.35.10 release line and the 2026.10.19.post2 conformance suite target 2026-10-19.

Latest: UHP 2026-10-04 adds the optional Memories chapter; HarnessRouter v0.35.1 ships (18 October 2026)

UHP published 2026-10-04, additive to 2026-09-28, and the new draft adds one chapter: Memories. A memory is a named container of records; memories form a tree, access is granted per node and inherited downwards, records point at one another, and a harness reaches memory at four moments of a session’s life — prime, tools, observe, consolidate. The chapter is optional: a server advertises it with the memories capability, and a server without it is conformant at every class. The spec carried two same-day patches: a record’s content is always an ordered list of text and file parts, and a memory’s id is opaque rather than required to carry the hmem_ prefix. See Memories.

The conformance suite moved with it. The current package is 2026.10.19.post2 (15 October 2026), targeting 2026-10-04, and the executable registry now holds 100 checks: 41 Core, 9 Extended and 50 Full. Thirteen of them are the new ME- memories checks. The suite runs with one credential, so what one principal may not read of another’s is not yet checked by it.

HarnessRouter Community Edition moved further still. Stable is now v0.35.1, published 18 October 2026 at 06:26:23 UTC, and the released backend set is 26 after v0.33.0 added MiMo Code, jcode, OpenSquilla, nanobot and Qoder Cloud Agent, the first remote runtime. The runner’s BACKENDS registry holds 27 entries: Gajae-Code is implemented in the runner but deliberately not offered by the product. Other releases in the line: v0.30.0 per-task reasoning effort, v0.31.0 Microsoft Entra sign-in for Azure, v0.32.0 delete semantics that remove data for good, v0.34.0 runner and MCP-bridge corrections, and v0.35.0 session-workspace file operations. CE still advertises UHP 2026-09-28, so the optional memories capability is not established in that implementation. Read the release tracker for the full sequence.

Classification first: UHP is now 2026-10-04 Draft and conformance is 2026.10.4.post11 / 98 executable checks. HarnessRouter Community Edition stable is now v0.35.10 / caa3c0a10d52681157913c572fc5244bc5c00f7f0, published 18 October 2026 at 06:26:23 UTC. The released backend count is now 26. CE still advertises UHP 2026-09-28, so the optional memories capability is not established in that implementation.

The v0.29.1 release and PR #381 fix two relay behaviors that matter to interactive and streamed integrations. Reads now use read1 so arrived bytes can be forwarded instead of waiting for a 4 KB block or end-of-stream. Relay liveness now measures real provider events, so an aggregator that sends comment-style keep-alive lines while its upstream is silent can no longer keep the request alive indefinitely; after HR_RELAY_UPSTREAM_TIMEOUT_S (600 seconds by default) without an event, the stream reports the upstream failure. The DeepSeek Harness relay applies the same rules.

Upstream reproduced these defects with tests driving the real handlers over real sockets, but explicitly says neither defect was caught on a live provider. It also separates a different case that this release does not fix: a model that keeps emitting reasoning events after its answer is still active, not stalled. The release additionally marks RCs as prereleases so v0.30.0-rc.3 does not take GitHub’s Latest badge.

For operators, test first-event latency and a keep-alive-only upstream stall separately from a continuously emitting model. Keep the deployment receipt tied to the installed image/version; upstream release tests are not proof that a specific provider/account path is healthy.

Earlier 4 October: HarnessRouter v0.29.0 adds four new harness bases

At that release point: UHP remained 2026-09-28 Draft and conformance remained 2026.9.28.post3 / 85 executable checks. HarnessRouter v0.29.0 / 2826cf633b0588fa494da20fdf2828deacfb7e79 was published 4 October 2026 at 00:33:05 UTC and raised the released backend count to 20.

PR #373 adds four harness bases in one release: Kilo CLI 7.8.1, MiniMax Code 0.5.4, Grok Build 1.0.41 and Agent Zero v2.13. The same merge hardens relay behavior for stalled/dropped upstream responses and replayed tool data, and keeps credential-bearing harness configuration out of checkpoints/workspace repositories.

The preceding release train remains material context: v0.26.18 added Claude Sonnet 5.5 coverage and removed the separate per-organization Runtime Plugin availability gate; v0.27.0 added Microsoft 365 Runtime Plugins; v0.28.6 hardened public artifact sharing/revocation; and v0.28.7 added GPT-6.1 Sol coverage.

These are HarnessRouter implementation/runtime changes, not a new UHP version, not a new conformance denominator and not evidence of native UHP adoption by the new backend projects. Read HarnessRouter, Runtime Plugins and the release tracker.

The dated entries below preserve the release state at publication. Words such as “current” and “stable” inside an older entry refer to that entry’s date; use the release tracker for the current baseline.

What the 4 October release changes for operators

The v0.29.0 release notes describe measured console scenarios for the four new bases, including first turn, follow-up, model switch, artifact and recall after sandbox recycle. Their reported pass totals have failures: they are not an all-model compatibility guarantee.

Reported release evidence	Operator implication
Kilo 291/295, MiniMax 283/285, Grok 279/280, Agent Zero 267/280 scenario runs	Inspect the failure notes for your harness/model/provider pair
Stalled provider streams now carry failure reasons	Exercise timeout/error UI and preserve terminal evidence
Tool IDs/history survive model handoff fixes	Test your actual multi-model conversation path
Credential-bearing per-turn config excluded from checkpoints	Inspect the intended checkpoint/config boundary after upgrade

These are publisher-reported outcomes for v0.29.0; this guide has not independently rerun that matrix. Source notes live in the release’s support-matrix references. Use HarnessRouter to choose an execution path and session recovery when an interrupted stream leaves an uncertain task outcome.

v0.29.0 was stable at the time of this entry. Later the same day, stable advanced to v0.29.1; v0.30.0-rc.3 remains a prerelease. Keep those channels separate when reading subsequent news. The older dated entries below remain their original publication evidence; later release coordinates do not rewrite their benchmarks, check counts or adoption status.

Historical: 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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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.

Current boundaries

• Published UHP is 2026-10-04 Draft; optional Memories are the newest protocol surface, after Environments.
• HarnessRouter stable is v0.35.10 / caa3c0a1; development main was checked at the same caa3c0a1 commit. Development evidence does not expand the released support matrix.
• The conformance package was 2026.10.4.post11 with 98 executable checks: 40 Core, 9 Extended, 49 Full.
• Released HarnessRouter backend set is 26.
• Runtime Plugins are HarnessRouter implementation services, not UHP Harness Plugins. Released services now include Browser and Microsoft 365.
• v0.28.6 artifact-sharing hardening, v0.28.7 GPT-6.1 Sol coverage, v0.29.0 four-base expansion, v0.30.0 per-task reasoning effort, v0.31.0 Entra sign-in, v0.32.0 delete semantics, v0.33.0 five new bases and the v0.34.x/v0.35.x relay, SQL, media and driver fixes do not revise UHP or conformance.
• Historical support matrices and conformance reports remain revision-bounded evidence.
• Native UHP adoption by upstream harness or model vendors is not established merely by HarnessRouter adapter/model support.

Where to follow each signal

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.

Primary sources

• HarnessRouter v0.29.1
• PR #381 — relay streaming and upstream liveness
• HarnessRouter v0.29.0
• PR #373 — four new harness bases
• HarnessRouter v0.28.7
• PR #369 — GPT-6.1 Sol
• PR #368 — public artifact isolation and revocation
• PR #343 — Microsoft 365 Runtime Plugin
• HarnessRouter v0.26.18
• PR #350 — Sonnet 5.5 and Runtime Plugin availability
• Current UHP changelog
• Current conformance package
• PR #165 — UHP 2026-09-12 Harness Plugins
• UHP 2026-09-12 Plugins chapter
• Conformance package 2026.9.12
• Agent Plugins 1.0.0 specification
• HarnessRouter checked main a7406cbd
• Oh My Pi v18.1.19
• Oh My Pi v18.1.19 tag/current-main e4dd2ec3
• Oh My Pi PR #11787 — release obsolete MCP tool generations after reconnect
• Oh My Pi PR #11799 — DeepSeek V4.1 Flash wire contract
• Oh My Pi PR #11823 — replay-safe retry for empty tool-call starts
• Oh My Pi PR #11842 — per-fallback reasoning effort
• Oh My Pi PR #11335 — persistent /btw history and follow-ups
• Oh My Pi PR #11545 — JSON print-mode failure exit status
• Oh My Pi PR #11868 — live tool-result display continuity
• Oh My Pi PR #11847 — Codex OAuth account-id compatibility
• Oh My Pi PR #11907 — Windows zcode:// OAuth callback fix
• HarnessRouter v0.16.1
• HarnessRouter v0.16.1 tag target 8f976f90
• PR #155 — custom endpoint model mapping, connection tool policy and Codex pin
• HarnessRouter v0.16.0
• PR #151 — hosted HarnessRouter provider and key hand-off
• HarnessRouter v0.15.10
• PR #148 — Codex app-server provider-column rerun
• PR #147 — explain cross-route encrypted-reasoning continuation refusal
• PR #146 — make Codex app-server the default
• PR #144 — normalize Codex app-server items
• HarnessRouter v0.15.7
• PR #140 — dsh OpenRouter matrix 189/189
• PR #139 — Azure Hermes Responses routing and explicit Claude/OpenCode lost-resume reporting
• HarnessRouter v0.15.6
• PR #138 — custom-harness MCP-server verification
• PR #137 — model/error/retry fidelity
• PR #136 — server-vouched model availability
• PR #135 — dsh MCP driving and OMP corrections
• DeepSeek Harness v0.1.5-rc.2
• PR #133 — initial custom-harness methodology
• PR #132 — responsive audit
• PR #119 — Oh My Pi support-matrix evidence
• PR #93 — historical self-hosted support matrix
• PR #64 — checked-in 64/64 reference record
• PR #60 — canonical session deletion and F-08
• Current UHP conformance suite
• uhp-go checked-in conformance evidence