YYLO

2026-08-29 · Updated 2026-08-30 · 11 min read

The YYLO harness support and interoperability matrix, version 2

A versioned support ledger for YYLO's agent-harness dispatch surface: one dated cell per harness, each with the command that re-verifies it against your own installed release, plus the update policy that keeps a citation honest.

By Juno AI INC · agent-harness · support-matrix

Near every harness comparison sits a smaller, undated claim — this control plane runs that harness. This page is where that claim gets checked for YYLO. It is a support ledger, not a review: one cell per agent harness, and every cell carries three things together — the fact, phrased as what the committed sources behind this site's pinned package facts record; the date the fact was checked; and a command that re-derives it against the release you actually operate. Version 1 was checked on 2026-08-29; version 2 records one movement — the external closure gate ran against the released package artifacts on 2026-08-29 and verified that Kiro and OpenCode have no first-party dispatch surface, so those two cells now state verified absence at the gate date instead of pending. The update policy below is what keeps the cells worth citing once they drift.

The reader this page serves is an operator verifying a support claim before betting a workflow on it. Three neighbors hold adjacent ground, and this matrix leans on each exactly once: the harness boundary guide explains why a control plane and the harnesses beneath it are separate layers at all; the switching guide owns the procedure for moving in-flight work between services; the state report tracks the wider landscape and deliberately refuses to be a support ledger. This page owns the narrow, checkable facts: which harnesses the dispatch surface documents today, and what interoperates around every dispatch.

Two honesty rules frame every cell. Nothing here is a demand estimate or a market observation; no search-demand corpus backs this route, and none was invented. And the matrix records YYLO's own committed surface only; it never grades any external product, and the two named cells that were pending in version 1 now record the closure gate's answer: verified absence of first-party dispatch for both subjects, with the documented extension seam as the path.

What a cell promises

Every cell states one fact at one depth, and three pieces travel together: the fact, the evidence date, and the verification command. Cells come in four states:

  • documented. The committed product sources behind the pinned package facts record the fact, and the cell names the surface it was read from. The command re-derives the fact on your installed release.
  • pending. The fact is gated: this site may not assert released support for the subject until the external closure gate has independently confirmed what the released package contains. No cell currently sits in this state.
  • verified absent. The closure gate has checked the released package artifacts themselves and verified that the subject has no first-party dispatch surface. The cell records that verdict, names the instruments, and points at the documented extension seam as the path. The verdict holds until a future release changes it, which is a new gate act, not an editorial edit.
  • extension. The fact is the documented custom path rather than a named service.

Dates belong to cells, not to the page. When a later version re-checks one cell, that cell's date moves and the page re-versions, while untouched cells keep their dates; the page-level evidence date is simply the newest cell date. Verification commands are yours to run: they check the release you operate, and that release — not this page — is the truth a support claim is finally about.

Harness support cells

Support has two layers, and both are recorded per cell, because a service name with no resolvable script behind it is not support you can run: the service name the dispatch surface documents, and the service script a dispatch resolves to do the work.

  • Claude Code — documented, checked 2026-08-29. The -s/--subagent option names claude; the core-commands reference documents the yylo claude 'task' shortcut; the supported-services table carries the default-model row claude-sonnet-4-6 with :haiku, :sonnet, and :opus shorthands; the shipped service-script set includes claude.py. A per-service model default is configurable with yylo claude set-default-model. Verify with one bounded dispatch: yy start -b shell -s claude -i 1 -v.
  • Codex CLI — documented, checked 2026-08-29. The same layers: named at the -s option, yylo codex 'task' shortcut, default-model row gpt-5.3-codex with :codex, :codex-mini, :gpt-5, and :mini shorthands, shipped codex.py. Verify by swapping the service name in the same dispatch.
  • Gemini CLI — documented, checked 2026-08-29. Named at the -s option, yylo gemini 'task' shortcut, default-model row gemini-2.5-pro with :pro, :flash, :pro-3, and :flash-3 shorthands, shipped gemini.py. Verify: the same dispatch with gemini.
  • Pi — documented, checked 2026-08-29. Named at the -s option with the yylo pi 'task' shortcut; the default-model row reads :gpt, resolving to openai-codex/gpt-5.6-sol; the table notes a multi-provider agent that installs separately (npm install -g @mariozechner/pi-coding-agent). Shipped pi.py. The global-options table marks exactly two flags Pi-only — live mode and clone — recorded with the seams below, and the pairing guide covers its session branching in depth. Verify: the same dispatch with pi.
  • Cursor — documented at the dispatch option, checked 2026-08-29. The -s option names cursor alongside the other four services, and the backend-choice section presents all five as one-flag choices. Two gaps stay on record: the supported-services table carries no default-model row for Cursor, and the shipped service-script set contains no cursor.py. Dispatch resolution tries <service>.py, then <service>.sh, then the generic subagent.py/subagent.sh names — and the shipped set carries neither a Cursor-named script nor a generic one, so a Cursor dispatch needs a script you supply and fails closed, naming the paths it checked, until one exists. The pairing guide wires that script; verify the script side with yylo services list and the dispatch itself with yy start -b shell -s cursor -i 1 -v.
  • Kiro — verified absent from first-party dispatch, checked 2026-08-29. The external closure gate ran on 2026-08-29 against both released registry channels — npm latest (@yylo/cli 0.2.0) and next (0.2.1-rc.1) — and verified the absence three ways: a case-insensitive word-boundary sweep over every file in both extracted tarballs, source maps included, returned zero matches for kiro; the dispatch-service enumeration in both builds names exactly claude, cursor, codex, gemini, and pi; and the shipped service-script set carries no kiro.py. The gate record in the checking section below names both tarball digests. That verdict is permanent until a future release changes it, and a change re-opens the cell through a new gate act, never an editorial assertion. The documented path is the custom-service seam below, which the pairing guide maps Kiro's spec-driven workflow onto. Verify on your side: the service list in your own release's option listing — a name appears there or it does not.
  • OpenCode — verified absent from first-party dispatch, checked 2026-08-29. The same gate instruments, the same date, the same result for opencode: zero word-boundary matches across both extracted packages, the same five-service enumeration in both builds, and no opencode.py in the shipped script set. First-party OpenCode dispatch is verified absent from released truth — permanently recorded, re-openable only by a future release and a new gate act. The documented path is the custom-service seam, which the pairing guide walks with OpenCode's agent configuration. Verify the same way: your release's own service list is the check that counts.
  • Any other harness — extension, checked 2026-08-29. The documented path for a service the package does not name: a plain Python script under ~/.yylo/services/, taking -p/--prompt, -m/--model, and -v/--verbose on its command line and writing JSON events to stdout as it runs. Verify what your install carries: yylo services list.
sh
yylo services list                    # which service scripts your release carries
yy start -b shell -s claude -i 1 -v   # one bounded dispatch; swap the service name

Interoperability seams

Support answers whether a harness can be dispatched at all; interoperability is what the control plane does around every dispatch, whichever service is named. Five seams, each dated and verifiable:

  • Model resolution — checked 2026-08-29. A dispatch resolves its model in a fixed order: the -m flag first; next a per-service default when one is configured (yylo <service> set-default-model ...); finally the built-in default, whose resolved form the services table prints. Verify by setting a default, dispatching without -m, and reading the recorded model.
  • Session record — checked 2026-08-29. Every run leaves its session ids in the run record and appends a session_history.json entry holding the prompt, the service, the model, the cost, and the session ids; yylo session list, yylo session info <id>, --resume <id>, and yylo continue address those ids afterwards. Verify: yylo session list after one dispatch.
  • Pi-only surfaces — checked 2026-08-29. The global options mark two flags Pi-only — --live, which runs Pi's interactive TUI and hands control back when the run finishes without abort, and --clone, which forks a session — plus the ypl shorthand that expands to yy pi --live. Verify against your release's own option listing, or one live run.
  • Audited envelope — checked 2026-08-29. yy pi --execution-envelope prints a single juno_execution_envelope.v1 object and nothing else on stdout; its provider, session, model, cost, and version values are taken from marked terminal evidence the backend produced, not from assistant prose. Verify: run it with a one-line prompt.
  • Skill surfaces — checked 2026-08-29. Skill files are provisioned into per-agent directories — .claude/skills/ for Claude, .agents/skills/ for Codex, .pi/skills/ for Pi — on every CLI run. Verify: yylo skills status.
sh
yylo session list                      # seam: the session record
yylo claude set-default-model :opus    # seam: model resolution
yy pi --execution-envelope 'reply ok'  # seam: the audited envelope
yylo skills status                     # seam: skill surfaces

What these seams are for — carrying in-flight work from one service to another without losing the thread — is a procedure this matrix deliberately does not restate. The command surface for the checks above is the product's committed README behind the pins named above; the site's operational reference instead owns the install, first-run, and loop surfaces that surround any dispatch.

How each version was checked

Version 1 used two instruments, both inside this site's control. The first is the generated package facts: they pin the product versions (@yylo/cli 0.2.0), the package URLs, and the repositories this page's cells sit behind. The second is the committed product sources behind those pins — the README's option table, core-commands reference, supported-services table, session-management and backend-choice and custom-backends sections, service- and skills-management sections, plus the shipped service-script set in the package templates — read on 2026-08-29. The script-resolution order in the Cursor cell was additionally read from the dispatch code behind the same pins. No live external surface was fetched for any version-1 cell, and that is deliberate: version 1 was not the released-truth gate.

Version 2 adds the released-artifact instrument the two verified-absent cells rest on, run on 2026-08-29 against the public npm registry: the registry's dist-tags were read (latest 0.2.0, next 0.2.1-rc.1, no newer publish at the reading), both tarballs were fetched and extracted, and their SHA-256 digests recorded — 7a815acf4e348ae288a6317132ec9858413b625cf4f687f2f99285f730f8a9d6 for @yylo/cli@0.2.0 and a6b646db9c526a389669379c3ef46ba59fd85a6887f44591462fbe2f0a01f90a for @yylo/cli@0.2.1-rc.1. Those digests are the re-derivation instrument: fetch the same tarballs, hash them, and sweep the extracted trees yourself — grep -rniE '\bkiro\b|\bopencode\b' over every file returns nothing in either package. The digests and the registry state were re-derived unchanged on 2026-08-30 before this version was published — a no-change pass under the policy below. Every documented cell was also verified against the released 0.2.0 artifact itself during the same gate, cell by cell against the surfaces each cell names — the model rows, the service shortcuts, the option schema, the script-resolution order, the Pi-only flags, the audited-envelope contract, the session record, and the per-agent skill directories — so no cell on this page outruns its instrument.

The boundary between the two instruments is stated once and binds every cell. The committed sources say what the repository behind the pins records; the released artifact is what the registry actually ships, and a committed README can move ahead of a released artifact — which is why each cell names the surface it was read from and why the verification command, run against your installed release, is the check that outranks this page. The same honesty covers drift in the other direction: a future release that ships a first-party Kiro or OpenCode service does not silently flip a cell here; the flip is a new gate act with new digests, and until it runs, the verified-absent verdict stands.

Versioning and update policy

The contract has four clauses. A changed cell produces a new page version: the changelog names the cells that moved and their new dates, while untouched cells keep their old dates. A gated cell flips only through a gate act — never by editorial assertion — and the flip itself is a new version; the same rule guards a verified-absent cell against a future release that ships the service. A re-check that moves nothing records a no-change pass under the standing version number. Cite the stable URL with the version number and the cell's date attached; a cell repeated without its date reads as if it could never drift, and cells can.

Changelog

  • Version 2 — published 2026-08-30. The external closure gate ran on 2026-08-29 against both released registry channels and verified first-party Kiro and OpenCode dispatch absent: the two pending cells became verified-absent cells at gate date 2026-08-29, the reading contract gained the released-artifact instrument and its digests, and the cell states gained their fourth member. No other cell moved; the five documented cells and the extension cell keep their 2026-08-29 dates, and each documented cell was additionally verified against the released 0.2.0 artifact during the same gate.
  • Version 1 — published 2026-08-29. First publication: seven named-harness cells — five documented at the dispatch option, two pending behind the external gate — plus the extension cell, five interoperability seams, the reading contract, and this policy. No earlier version exists; nothing is superseded.