YYLO vs Conductor

Conductor is the closest architectural peer this hub has compared so far, and the matrix below treats that parity as the story instead of inventing a chasm. Conductor's own reference draws the layer map this site uses: "A harness is the agent runtime that writes code; Conductor is the workspace layer around it." The homepage adds the crew — "Conductor runs the first-party Claude Code, Codex, Cursor, and OpenCode agents under the hood" — and the docs' unit of work rhymes with YYLO's: "Each task gets its own workspace, branch, files, terminal, diff, and review path." YYLO answers from its README in one line — "YYLO orchestrates AI coding agents and structured development workflows." — aiming installed agent services at admitted tasks: "Switch between Claude, Codex, Gemini, Pi, or Cursor with one flag". Both sides of every quote were fetched from their live sources on 2026-08-28; the panel beneath the matrix names each claim source, and the demand section counts only what the dated corpus actually holds.

Six rows sit in the matrix, and the honest tally is that two end in agreement: both products chose Git worktrees as the isolation unit, and both spread work across many agents at once. One row belongs to Conductor alone, because it operates a cloud its counterpart does not have. Three favor YYLO, for reasons the sections below take one at a time — who guards the landing, what record survives it, and which cockpit the whole system answers to.

Two control planes, different cockpits

Conductor ships from Melty Labs as a macOS application, and its front door is unapologetic about that: conduct "from the desktop app, mobile, or your own integrations to the Conductor API", with the homepage's iOS tile still marked SOON. The app layer is social in a way terminals are not — "Conductor is now multiplayer", with workspace links to share, teammates to follow, and agents prompted together in real time. Above the app sits the cloud: "Conductor Cloud runs on isolated microVMs with your repos and dependencies pre-installed", sandboxes that boot in seconds and host runs measured in hours. Billing stops at the layer boundary in the docs' own words: "Conductor is free to use. We do not bill or resell model usage."

YYLO's cockpit is a shell. The @yylo/cli package — 0.2.0 in the generated facts — exposes task start, dispatch, evidence, and merge as commands, which makes cron, CI, and plain scripts first-class operators rather than afterthoughts. The service set overlaps Conductor's harness list on claude, codex, and cursor, then splits: Conductor bundles an OpenCode runtime, while YYLO reaches gemini and pi through its documented dispatch table. Neither list contains the other; they point at different default crews. The harness boundary guide defines that layer once for every product on this hub, and the switching guide holds the dated matrix for moving between services inside YYLO.

The convergence is the worktree

Ask either product how it keeps parallel agents off each other's files and the answer is the same Git feature. Conductor's docs define the unit plainly — "An isolated workspace is a separate, git-backed copy of a project for one stream of work" — and then name the mechanism: "Conductor uses Git worktrees to give each workspace its own files, branch, commands, chats, and review flow." One workspace maps to one branch, one branch to one working tree, usually materialized under ~/conductor/workspaces/<repo>/<workspace>. YYLO builds the same shape from the ledger side: every task record resolves to a worktree cut from a recorded exact base, so the base commit is part of the evidence rather than an accident of timing. The worktree guide owns the mechanics for all of this — what a worktree is, when one branch per agent is right, and how to recover when a boundary fails.

Fan-out is where the convergence gets interesting, because each product splits the same problem on a different joint. Conductor's rule is quotable: "Use multiple workspaces when tasks should land independently." Its mirror — several agents inside one workspace when the work shares a branch, code state, and context — lets multiple runtimes co-edit one checkout under one review. YYLO holds the boundary stricter: "Run multiple tasks simultaneously with the parallel runner", one bounded invocation per task, each inside a dedicated worktree, with concurrency capped explicitly and the batch drawn from task IDs the ledger's ready query returns. Two both-verdicts sit in the matrix because both answers are real answers; the runner-choice guide covers when the stricter split pays for itself.

Who guards the landing

Conductor's workflow page compresses its philosophy into two sentences: "The workspace is the unit of delegation. The branch and pull request are the unit of integration." Between delegation and integration stands a person. "The Checks tab collects the state you need before merging a workspace" — Git status, CI results, deployments, review threads, open todos — and the app itself frames its blockers gently: "Conductor may block or discourage merge actions when required work is still open", with the usage advice to "Treat these as prompts to inspect the workspace before merging". The pass ends in a pull request, a merge, and an archived workspace, and it is a good pass — but its arbiter is human.

YYLO puts the gate in software. yy task finish admits a clean committed tip into a queue; one serialized merge arbiter owns target mutation, applies validation and review selected by the task's risk policy, and advances the target by comparing the exact SHA it expected. A person can still read every receipt — nothing is hidden — but nothing lands because a person clicked; it lands because the queue's checks passed. The matrix scores this row for YYLO on that specific job, automated guarded admission, not because Conductor's human gate is careless.

What survives the merge

Conductor keeps its history attached to the workspace that made it. Chats, diffs, checkpoints, and pull-request state stay bound to the workspace inside the app, workspace notes live in a gitignored .context folder, and the workspace archives once its branch lands. That is a memory built for reopening the app: the teammate who asks what happened in a given workspace finds the conversation, the turn-by-turn checkpoints, and the diff exactly where the app left them.

YYLO's records are made for a reader who installs nothing. A ledger entry lands in repository history — intent, status, the recorded response, the commit that carries the result — and typed receipts plus content-addressed checkpoints hang off the same Git truth. An auditor clones the repository and gets the work's story without the tool that produced it; the same cannot be said of an archived app workspace. The row goes to YYLO for repository-native evidence, with the honest note that Conductor's in-app record is the friendlier of the two for its own audience.

The demand this route actually owns

Unlike the Pi page's empty ledger, this decision owns thirteen keyword rows in the 2026-08-26 competitor exports, with an estimated combined volume of 1,980. "conductor claude code" (estimated 480 monthly searches) and "conductor claude" (estimated 390) lead; "conductor github" (estimated 210), "conductor ide" (estimated 210), "conductor oss" (estimated 140), and "conductor terminal" (estimated 110) follow, with the remainder — agent, orchestration, alternatives, and CLI phrasings — running between 40 and 90. One thread in that list deserves its own sentence: repository demand exists — "conductor oss", "conductor github", and "conductor build github" together — while the pages fetched for this comparison link no public source repository, pointing instead to Discord, Reddit, X, and YouTube. The searchers asking that question are not wrong to ask it.

Demand this route does not own has named destinations. "conductor vs cursor" (estimated 40) is owned by the harness-versus-harness matrix this hub has approved but not yet shipped; "gemini cli conductor" (estimated 170) waits on a planned CLI-alternatives page the same way, and neither is linked from here. Pure navigational tokens — "conductor build" (estimated 720), "conductor app" (estimated 480), "conductor company" (estimated 320) — fall to the corpus's navigational exclusions, while "conductor pricing" (estimated 90) is excluded as pricing research. For footprint, conductor.build holds ranking positions on 55 of the exports' 8,366 unique keywords, twelfth among the thirteen ranking domains — ahead of omp.sh and behind the other four products this hub compares. And the string "yylo" appears in no keyword in any of the fifteen export files, an absence this page recomputed from the raw export files instead of carrying it forward from a sibling. Every figure in this section is a DataForSEO estimate — directional input, not a counted observation; the paid competition field measures advertiser bidding and is never presented here as organic ranking difficulty; no sentence in this section forecasts rankings.

Six dated calls and what decided them

• One working tree per stream of work: agreement — the same Git primitive, chosen independently, is the isolation unit on both sides.
• Fanning out across many agents: agreement again — Conductor across and inside workspaces, YYLO across exact-base task worktrees under explicit caps.
• Hosting long unattended runs off your machine: Conductor — microVM sandboxes are an operated cloud; YYLO's documented execution stays local to each worktree.
• Guarded admission into shared history: YYLO — a serialized queue with policy-selected checks, against a review pass a person closes.
• The record that outlives the tool: YYLO — ledger entries and receipts live in the repository; Conductor's chats, diffs, and checkpoints live in the app and archive with the workspace.
• The cockpit: split by design — YYLO for terminals, scripts, and schedules; Conductor for people who want windows, multiplayer, and eventually a phone.

If the cockpit decides it, the decision is quick: teams that live in a Mac app with shared links and cloud sandboxes have their product, and operators who need the whole system answerable from a shell have theirs. The overlap is real but partial — three shared harness names, one shared isolation primitive — and the divergent rows are the durable ones. Start with the worktree guide for the primitive both products share, follow the lifecycle guide through one task from prompt to validated change, and bring any still-gathering decision back to the comparison hub.