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

Harness integration

UHP and Oh My Pi

Oh My Pi became HarnessRouter's tenth released harness backend in v0.15.0, with dedicated provider/scenario evidence and a clear adapter-versus-native-adoption boundary.

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

Verified relationship

Section titled “Verified relationship”

HarnessRouter Community Edition v0.15.0, published 7 September 2026, added Oh My Pi (omp) as its tenth built-in harness backend through PR #68. HarnessRouter drives Oh My Pi behind the UHP server boundary; this is HarnessRouter adapter support, not evidence that the upstream Oh My Pi project implements or endorses UHP natively.

Oh My Pi is the upstream project at can1357/oh-my-pi, described by its repository as a coding agent with the IDE wired in. The project is MIT-licensed and publishes standalone omp binaries. HarnessRouter’s adapter defaults to Oh My Pi 18.1.13; the upstream Oh My Pi project has already published v18.1.14, so the adapter pin and upstream latest release must be tracked separately.

How the HarnessRouter adapter works

Section titled “How the HarnessRouter adapter works”

PR #68 adds Oh My Pi to HarnessRouter’s backend catalogue, runner, console mapping and default container installation. The Community Edition container includes omp in the default backend set and downloads the upstream Linux binary for the running architecture. The default version is controlled by HR_OMP_VERSION and is 18.1.13 in the checked source.

The runner writes Oh My Pi’s per-session model and MCP configuration under the harness home, supplies provider-specific credentials/endpoints, applies tool and permission policy, supports session resume, and consumes Oh My Pi’s progressive JSON stream for normalization into the HarnessRouter/UHP event path.

PR #68 also wires Oh My Pi across supported provider families including direct and OpenAI-compatible paths. These are HarnessRouter implementation choices. UHP clients do not need to reproduce Oh My Pi’s CLI flags, config-file layout or provider-specific environment variables.

Dedicated compatibility evidence

Section titled “Dedicated compatibility evidence”

PR #119 publishes a dedicated Oh My Pi matrix run using the pre-release HarnessRouter OMP branch and Oh My Pi 18.1.13. It records 705 of 705 scenario runs across seven provider columns:

Provider columnScenario result
Google AI Studio55 / 55
OpenRouter184 / 184
Vercel AI Gateway184 / 184
TokenRouter164 / 164
Anthropic40 / 40
OpenAI39 / 39
Azure OpenAI E239 / 39

The PR states that every turn stayed on the column’s own integration and that no identifier was served as another model under the matrix judgement. It also updates the matrix’s same-model alias rule so provider prefixes or version suffixes can be treated as aliases only when they still identify the same model family/tier.

This evidence is not UHP conformance. It measures HarnessRouter’s Oh My Pi adapter across provider/model/scenario combinations. The older PR #93 matrix remains a separate 695-pair, eight-backend point-in-time run measured before Gemini CLI and Oh My Pi became released backends.

Artifact and continuation follow-up

Section titled “Artifact and continuation follow-up”

HarnessRouter v0.15.1 fixes two console/runtime issues found while verifying the post-v0.15.0 line: a send latch could leave a settled task silently unable to accept later messages, and the same produced file could render twice when delivered once by the POST stream and again by a late live-forward broadcast event.

PR #121, released in v0.15.2, documents the stronger artifact-row judgement after that duplicate-card fix and records one stored file/one rendered card on the release across Gemini, Cline, Qwen, DSH, OpenCode and OMP. This is useful implementation evidence for the Oh My Pi path, but it remains separate from protocol conformance.

HarnessRouter v0.15.3 hardens hosted login-state cookie handling and session reconciliation. Its upstream change explicitly states that the relevant paths are inert self-hosted, so it does not alter the Oh My Pi adapter, its 18.1.13 default, the ten-backend count or the recorded PR #119 evidence.

Current status

Section titled “Current status”

As of 8 September 2026:

  • UHP remains 2026-08-11 Draft.
  • HarnessRouter Community Edition stable is v0.15.3, annotated tag target 90d6cb0c2f221b9649200a43c363398fcc0ab289.
  • Upstream HarnessRouter main is the same 90d6cb0 at the checked cutoff.
  • HarnessRouter has ten released harness backends, with Oh My Pi added in v0.15.0.
  • HarnessRouter’s Oh My Pi adapter defaults to 18.1.13.
  • Upstream Oh My Pi’s latest observed release is v18.1.14, published 7 September 2026; the newer upstream version is not silently treated as the version measured by HarnessRouter.
  • PR #119 records 705/705 Oh My Pi scenario runs across seven provider columns under its stated pre-release conditions.
  • v0.15.3 changes hosted login-state handling, not the OMP adapter; those auth paths are explicitly inert self-hosted.
  • Current UHP conformance coverage remains 64 checks, and the checked-in HarnessRouter reference result remains 64/64 Full from the 4 September run.

What is not proven

Section titled “What is not proven”
  • No primary evidence reviewed here establishes native UHP implementation or endorsement by the upstream Oh My Pi project.
  • PR #119 does not prove every future Oh My Pi release, every model, every provider state or every deployment environment will behave identically.
  • HarnessRouter’s 18.1.13 default does not imply that 18.1.13 is the newest upstream Oh My Pi release.
  • The acronym OMP in this backend context does not refer to Open Memory Protocol.
Section titled “Related pages”

Read HarnessRouter, release tracker, ecosystem, adoption and UHP vs Open Memory Protocol.

Primary sources

Section titled “Primary sources”