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

Harness integration

Kimi CLI

Kimi CLI is now integrated on HarnessRouter current main as its twelfth backend, but that support is not yet in stable v0.17.3 and does not establish native UHP adoption by Kimi.

Verified: UHP: 2026-09-12HarnessRouter: current main only

Status first

Section titled “Status first”

Kimi CLI is now a HarnessRouter backend on current main, but it is not part of stable HarnessRouter v0.17.3. HarnessRouter PR #191 merged on 17 September 2026 as f895f1b6603447aede7fd535f8a7170c921b8e10, making kimi the twelfth backend on current main. The latest stable release remains v0.17.3 at 54fadfb3, where the released backend count remains eleven.

HarnessRouter pins Kimi CLI 1.50.0 for this adapter. Upstream MoonshotAI also publishes Kimi CLI 1.50.0 as the latest observed GitHub release at this cutoff.

This is HarnessRouter adapter support, not native UHP adoption by Kimi CLI. No reviewed Kimi upstream source establishes a native UHP server/client implementation.

Integration architecture

Section titled “Integration architecture”

HarnessRouter does not treat Kimi as a generic command passthrough. PR #191 adds installation, routing, state, stream normalization, tool policy, skills, MCP configuration, checkpointing and support-matrix coverage around the pinned CLI.

UHP client
  -> HarnessRouter gateway
    -> HarnessRouter runner
      -> Kimi CLI 1.50.0
        -> loopback OpenAI-compatible relay
          -> selected provider/model

Kimi reaches HarnessRouter-supported providers through the loopback OpenAI-compatible relay, following the same broad routing shape used by Qwen. The real provider credential stays behind the relay rather than being exposed directly to the CLI process. The relay also supplies served-model evidence because Kimi’s stream does not report the served model itself.

HarnessRouter writes a Kimi config with an openai_legacy provider and exact model id, disables Kimi telemetry for the managed turn, and points the CLI to the relay. The relay removes only reasoning_effort: null when Kimi sends it because at least one measured OpenAI-compatible gateway rejects that null value; an actual non-null reasoning setting is preserved.

Session identity and resume correctness

Section titled “Session identity and resume correctness”

Kimi’s stream-json output does not emit a session id or explicit terminal/result event. HarnessRouter therefore owns two pieces of normalization that are essential for UHP-facing continuity:

  • it assigns a deterministic session name so the first turn and later continuation address the same Kimi conversation;
  • it treats process exit as the turn boundary and uses the CLI exit code as the success/failure signal.

Resume validity cannot be inferred from --session <id> alone. Kimi will create a new session when an unknown id is supplied, which can make a lost continuation look like a successful fresh conversation. HarnessRouter instead checks Kimi’s own session store predicate: the expected context.jsonl under the work-directory keyed session path must exist. A missing conversation is then surfaced as resume_lost rather than silently accepted.

That is a reference-runtime continuity safeguard, not a new UHP session primitive.

MCP, skills and hard tool policy

Section titled “MCP, skills and hard tool policy”

Kimi CLI 1.50.0 accepts MCP configuration and HarnessRouter maps UHP/Harness Plugins MCP declarations into that native surface.

For URL MCP servers, HarnessRouter writes the declared transport explicitly. That matters because Kimi’s underlying MCP configuration can infer transport from URL shape; an SSE endpoint whose URL does not look like /sse could otherwise be dialed as Streamable HTTP. Stdio servers are written with command, args and optional environment. On the measured pinned CLI, an MCP server that cannot start makes the turn fail rather than merely degrade it.

HarnessRouter also passes a dedicated skills directory so harness-provided skills do not accidentally merge with unrelated default-discovery trees from another backend.

Disabled-tool enforcement is hard in the adapter, but the implementation detail matters: Kimi’s exclude_tools matches internal tool paths, not the short names shown to the model. HarnessRouter maintains an explicit name-to-path table and a regression test pins the console catalog ids to that table. A bare-name exclusion would otherwise be a silent no-op.

State and checkpointing

Section titled “State and checkpointing”

HarnessRouter redirects Kimi’s persistent share directory into .harness/home/.kimi. That keeps sessions/configuration in the runner-owned checkpoint domain, outside the produced-file surface, so a sandbox recycle can restore Kimi conversation state without publishing private CLI state as an artifact.

The adapter also forwards the operator’s turn/step budget through --max-steps-per-turn. Without that mapping, Kimi’s much larger native default could let an unexpectedly slow turn run far beyond the product-level budget.

Current-main evidence

Section titled “Current-main evidence”

PR #191 records several evidence classes that should not be conflated:

  • Backend count: current HarnessRouter main has twelve backends after adding Kimi; stable v0.17.3 still has eleven.
  • Plugin matrix: the PR reports 48/48 across twelve backend bases × four plugin columns. This is HarnessRouter plugin/runtime evidence, not UHP conformance.
  • UHP conformance: the suite remains 2026.9.12 with 74 checks and the change does not publish a new UHP version.
  • Model/runtime checks: the PR records live Kimi/provider measurements and explicit unmeasured model rows. Those results are point-in-time adapter evidence, not universal model compatibility.

UHP boundary

Section titled “UHP boundary”

UHP remains 2026-09-12 Draft. Kimi’s addition changes the HarnessRouter reference implementation on current main; it does not change the UHP protocol, the 74-check conformance denominator, Agent Plugins 1.0.0, or the stable HarnessRouter release coordinate.

At this cutoff:

  • UHP: 2026-09-12 Draft.
  • HarnessRouter stable: v0.17.3 / 54fadfb3 — eleven released backends.
  • HarnessRouter checked main: f895f1b6603447aede7fd535f8a7170c921b8e10 — twelve backends including Kimi.
  • HarnessRouter Kimi pin: 1.50.0.
  • Kimi CLI upstream latest observed GitHub release: 1.50.0.
  • Native Kimi UHP adoption: not established.

See HarnessRouter for stable-vs-current-main reference-implementation state, release tracker for version boundaries, and Harness Plugins for the UHP package/runtime boundary.

Primary sources

Section titled “Primary sources”