YYLO vs OpenCode

Verdict before caveats, because one matrix row refuses to be polite: the pairing below separates an open-source harness from the control plane that governs work above it, and the row asking whether either product drives the other scores neither — no first-party bridge between the two products exists, and the YYLO side of that absence rests on artifact verification, which nothing on this page upgrades by implication. OpenCode is "The open source AI coding agent", and its homepage answers the obvious follow-up plainly: "OpenCode is an open source agent that helps you write code in your terminal, IDE, or desktop." YYLO works the tier above that — no models and no interface of its own, just the apparatus that admits bounded tasks, aims your installed agent services at each admitted task, logs what each task answered, and walks finished work into shared history through one queue at a time. Each verdict in the matrix is a dated, per-job pick; evidence for both sides was reviewed 2026-08-28; the dispatch row alone was re-scored 2026-08-30, when the closure gate confirmed against the released artifacts that no first-party bridge exists, and the claim-sources panel names where each side's facts come from: package facts from the generator plus the committed YYLO README for one side, OpenCode's published site and docs for the other, and a competitor-keyword corpus that the demand section puts in its exact place.

If the question is which package to install tonight, the answer divides along that layer line. For picking, connecting, and swapping the model that reasons over your code — and for auditing the agent loop as source you can read — the dated evidence favors OpenCode without qualification. For the layer that decides what work exists, what any invocation may cost, and how finished work lands — bounded invocations, durable records, receipts, serialized landings — the pick is YYLO, which does no model selection at all. For driving one product from inside the other, neither side documents the seam — and the YYLO side of that absence is settled by the artifact check; the support flag rendered above the matrix holds that fact where it belongs.

Identify the layer before choosing a tool

YYLO's README compresses the product into one line — "YYLO orchestrates AI coding agents and structured development workflows." — and @yylo/cli, currently 0.2.0, is that line shipped as a package: no model of its own, no editor of its own, and a dispatch surface the README renders as "Switch between Claude, Codex, Gemini, Pi, or Cursor with one flag". Around dispatch sits what agents never carry with them: a per-run iteration bound, Git-native task records through YYLO Ledger, an isolated worktree for every task, with a merge queue standing between finished work and shared history. The five-service list quoted in that sentence returns where it decides something, further down.

OpenCode's own site draws its half of the picture. The surfaces line up behind the tagline: "Available as a terminal interface, desktop app, and IDE extension". The model story is the product's spine: "Free models included or connect any model from any provider, including Claude, GPT, Gemini and more." Underneath sit the automation doors — the CLI reference documents opencode run with the summary "Run opencode in non-interactive mode by passing a prompt directly", and opencode serve, summarized as "Start a headless OpenCode server for API access". Every OpenCode quote above was matched against opencode.ai as served on 2026-08-28, and every YYLO quote against the README committed in this repository, same date.

Open source in the harness, discipline in the control plane

What this decision really turns on is where openness sits and what it purchases. OpenCode's openness is verifiable in the way that matters for redistribution: the GitHub API reports an MIT license on the anomalyco/opencode repository, whose entire self-description is "The open source coding agent." — and that repository is the destination the older sst/opencode address redirects to, a fact anyone assembling a stack from older blog posts should know. Readable source buys real things: you can audit the permission lattice instead of trusting a changelog, point the harness at local weights, and check the model plumbing — "75+ LLM providers through Models.dev, including local models" — against code rather than claims.

A harness you can read does not by itself produce a system of work you can audit. Nothing in the repository decides which task a bounded run should pick up next, what evidence it must leave behind, or how two agents finishing at the same moment enter the target repository without overwriting each other. Those are the control-plane jobs — dispatch, isolation, bounds, admission — and the harness boundary guide draws that line precisely; the open-source stack guide maps which layers open source fills richly and where it thins out.

This page also owes you the uncomfortable half of its own side's ledger. On the 2026-08-28 check, the two YYLO evidence repositories — Ledger and Benchmark — showed MIT licenses on GitHub, while the CLI repository showed none, so assembling a whole stack from licenses you have read is a property OpenCode holds today and YYLO holds only in part. That asymmetry is exactly why the source-access row above scores the way it does. The stack guide owns the full two-document license treatment; for this decision, the practical reading is enough: audit OpenCode's source with confidence, and let the CLI repository itself, not this page, answer your redistribution questions.

Observed demand for this decision

These claim sources include competitor-keyword exports dated 2026-08-26, so demand gets stated as data, not vibes. Across the corpus's 8,366 unique normalized keywords, 232 contain "opencode", and opencode.ai holds ranking positions on 1,457 keywords overall — second of the thirteen ranking domains in the exports, behind openclaw.ai at 2,000 and ahead of the 1,000-keyword tier (openrouter.ai and every.to). Exactly one keyword maps to this route: "opencode alternative", with an estimated 110 monthly searches — every bit of corpus-observed demand this exact decision has, and an estimate that proves nothing by itself.

The heavier OpenCode phrases feed other decisions, each with a named owner. The brand phrase "opencode" (estimated 90,500) is pure navigation, which the rules exclude from any route's ownership, as are "oh my opencode" (6,600) and the github/install/go cluster around it. CLI intents, led by "opencode cli" at an estimated 1,300, feed a CLI-choice decision the comparison hub lists among its in-preparation entries. Agent-configuration queries — "opencode agents" at an estimated 880, "opencode subagents" at 390 — already have their canonical answer in the published OpenCode-with-YYLO wiring guide. Harness-versus-harness pairs, led by "pi vs opencode" at an estimated 390, wait on the hub's planned harness-versus-harness matrix. No keyword in the exports contains "yylo". Each figure is a DataForSEO estimate rather than a measurement; the paid competition field describes advertiser bidding, never organic ranking difficulty; and no count here forecasts anything.

The dispatch seam, verified absent

The dispatch row above earns its own explanation, because it is the one place this page refuses to guess — and its state has moved from waiting to settled. The README's dispatch sentence names five services, and opencode is absent from it. The closure gate (checklist item SEO-091) answered on 2026-08-29 with the packages npm distributes: both tagged builds — latest at 0.2.0, next at 0.2.1-rc.1 — unpacked and searched file by file, and opencode appears nowhere in either — no word match anywhere in the packages, five dispatch names in the validated list with opencode absent from it in both builds, and no shipped script bearing its name. The typed supportClaims metadata freezes the claim at verified_unsupported_first_party, the rendered flag above the matrix repeats it, and asserting released-current support is the one thing this page may not do. Hence the neither: no first-party contract joins the two products in either direction, and on YYLO's side the artifact check is what settles it.

Below the verdict, the dated evidence still supports two bridges. The first needs no dispatch contract at all: open a YYLO task worktree inside an OpenCode terminal session and the agent's blast radius stays inside the recorded boundary of that task — the wiring guide owns the full workflow, including a user-side service wrapper that points YYLO's documented user-service contract at OpenCode's headless CLI, the permanent route now that first-party dispatch is verified gone. The second is OpenCode's own automation surface: opencode run in non-interactive mode and the headless opencode serve are both documented, which shrinks a wrapper from a fork to a small script. The exit also stays cheap, because a service under YYLO is a selection rather than a marriage — the dated dispatch-surface matrix lives with the harness-switching guide. That re-score is already in the matrix above, resting on the 2026-08-29 verdict; a later release shipping a first-party seam moves the row only after a fresh gate run, never on this page's confidence.

The verdicts, one job at a time

• Source you can read, fork, and redistribute: OpenCode — an MIT-licensed repository with a one-line identity; the YYLO CLI repository showed no license file on the evidence date, so the same property is pending there, not proven.
• Model choice and provider plumbing: OpenCode — dozens of providers plus local models; YYLO forwards model selection to the dispatched service.
• Work records that outlive sessions: YYLO — ledger entries bind intent, response, and commit; OpenCode sessions are conversational records, listable, exportable, and shareable, but not a landing ledger.
• Landing finished work: YYLO — one serialized merge queue; a finished OpenCode session hands over a working tree with no arbiter attached.
• Several agents at once on one codebase: both — OpenCode's multi-session shares one checkout; YYLO's worktrees fan out from exact bases with serialized per-target merges.
• One product driving the other: neither — the five documented services leave opencode out, and the release gate (SEO-091) verified that absence; the user-side route is the extension seam.

Choose by layer, then. If the model under a license you can read is the real question, give OpenCode an evening and hold it to its own documentation. If what is missing is governance — bounded invocations, durable records, a queue that owns landings — register one small task in YYLO, dispatch any service you already have, and read the record it leaves behind. For OpenCode as that agent, the wiring guide is the shortest path; every decision still gathering evidence waits on the comparison hub.