YYLO vs the Pi coding agent

Of the comparisons gathered on this hub, this is the pair that barely competes, and the matrix below refuses to blur that. Pi is a harness — the layer that holds one model, one conversation, and a tool belt while code gets written. YYLO is a control plane — no model and no conversation of its own, only the machinery that admits bounded units of work, points an installed agent service at each admitted unit, and walks what finishes into shared history. Pi states the first identity as a rule: "Pi is a minimal agent harness. Adapt Pi to your workflows, not the other way around". The YYLO README answers from the tier above in one line — "YYLO orchestrates AI coding agents and structured development workflows." Both products' evidence was checked on 2026-08-28, and the claim-sources panel under the matrix records where every fact came from. One verdict carries no gate this time, either: the row that asks if one product can drive the other scores both, because pi is a documented YYLO service today — the Kiro and OpenCode pages carry a verified-absence resolution on their dispatch rows, and this page has no equivalent to settle.

Treat the matrix as six dated, per-job picks rather than a ranking. Two jobs belong to the harness without argument, three to the control plane, and the sixth is the seam itself. The sections that follow draw the layer line, compare how each product remembers work, bound the keyword evidence behind this decision, and describe the combination that already runs in both directions.

The same shelf, different layers

Stand at the two products' front doors and the difference in altitude is immediate. Pi's documentation introduces the project as "a minimal terminal coding harness", shipped as the npm package @earendil-works/pi-coding-agent — MIT-licensed, at 0.84.3 when this page's evidence was gathered — behind a one-line install of npm install -g --ignore-scripts @earendil-works/pi-coding-agent. The homepage then publishes a section titled "What we didn't build", and the refusals are the product: "No MCP", "No sub-agents", no permission popups, no plan mode, no built-in to-dos, no background bash — each listed with a pointer to an extension, a package, or tmux instead of a bundled feature. This is minimalism as policy. The core stays deliberately small, and everything else is meant to arrive from outside: "Customize Pi with extensions, skills, prompt templates, and themes", bundle them, share them — the extension surface, not the core, is where the product expects to grow.

YYLO's front door sits one tier up. The @yylo/cli package stands at 0.2.0, and its README's dispatch sentence — "Switch between Claude, Codex, Gemini, Pi, or Cursor with one flag" — names the services a run can aim at a task, with pi occupying one row of the documented service table. Around dispatch sits what no harness carries with it: a per-invocation iteration bound, a Git worktree per task through YYLO Ledger, and a merge queue standing between every finish and shared history. The harness boundary guide draws that boundary for every agent product, Pi among them; the short version is that Pi decides how a model touches a repository, and YYLO decides which work exists, where each unit runs, and what may land.

Sessions are trees; records are ledgers

The two products remember work in shapes built for different readers, and the comparison owes each shape its own description. Pi's memory is aimed at one reader — you, later. "Sessions auto-save to ~/.pi/agent/sessions/, organized by working directory", and "Each session is a JSONL file with a tree structure", so every branch of a conversation survives as a position you can return to. The sessions documentation splits its own navigation rules exactly: "Use /tree when you want to keep alternatives together. Use /fork or /clone when you want a separate session file". When a run deserves an audience, "Export to HTML with /export, or upload to a GitHub gist with /share and get a shareable URL that renders it". None of that is accidental; it is a memory built for re-entering conversations, and it is genuinely good at that job.

YYLO remembers for different questioners. The questions arrive from automation and from teammates — what did this unit of work set out to do, what did it answer, which commit carries the result — and a ledger entry answers all three in a form preflight checks and the merge queue can read. Neither memory substitutes for the other, and scoring them separately is more honest than crowning one: a session tree cannot tell the next agent which task is ready or whether anything landed, and a ledger entry cannot show you the branch of a conversation where a design choice was argued out. The matrix gives the conversation row to Pi and the record rows to YYLO for exactly this reason — they are different jobs, not rival implementations of one job.

The demand gap, stated openly

The competitor-keyword exports behind this site's claim sources contain no observed phrase that maps to this decision: zero include rows, a declared dataset gap rather than an oversight. The Pi demand that does exist in the 2026-08-26 corpus already has named owners. "pi agent" (estimated 8,100 monthly searches) and "pi coding agent" (estimated 4,400) route to the published Pi-with-YYLO wiring guide; "pi agent harness" (estimated 590) to the harness definition; "pi skills" (estimated 140) to the skills and project-instructions guide. Harness-versus-harness pairs — "pi vs opencode" at an estimated 390, "pi vs claude code" at an estimated 210 — belong to a planned harness-versus-harness matrix the hub lists as in preparation, and this page deliberately leaves them unlinked. The bare token "pi" (estimated 673,000) is excluded by the corpus rules as math-constant-or-hardware ambiguity, a useful reminder that the word carries meanings far older than the product. For scale: pi.dev holds ranking positions on 702 of the corpus's 8,366 unique keywords, eighth of the thirteen ranking domains — behind z.ai and kiro.dev, ahead of the CodeRabbit tier. Not one keyword in these exports includes "yylo", a fact recomputed for this page rather than inherited. Every number above is a DataForSEO estimate, not a measurement; the paid competition metric reflects advertiser bidding and is never quoted on this page as organic difficulty; and nothing in this section forecasts anything.

The seam that already runs both directions

The dispatch row scores both because documentation meets documentation. On the YYLO side, the service table lists pi alongside claude, codex, gemini, and cursor; yy pi 'your task' runs it headless; ypl is the README's own shorthand — "ypl is shorthand for yy pi --live and forwards all remaining args." — and the documented flag table marks exactly two rows Pi-only: --live for the interactive TUI and --clone for forking a session from the continue scope. On the Pi side, being driven from outside is an intended posture, not a hack: "Four modes: interactive, print/JSON, RPC, and SDK", with the site itself pointing at a real-world integration built on them. A control plane that dispatches Pi is simply one more of the drivers those modes exist for.

Composing the two is a guide of its own, and it is already published: the wiring guide owns session branching against task worktrees, readiness-ledger fan-out, execution envelopes, and the exact commands. What stays on this page is only the decision shape. If you already run Pi and want governance above it, YYLO adds the missing tier without asking Pi to change; if you already run YYLO and want a minimal, extensible harness underneath, pi is one flag away. Leaving remains cheap in the same motion — services swap per the dated matrix in the harness-switching guide, and the conversation trees you leave behind stay readable where they were saved.

Where each verdict lands, and why

• The conversation as a tree: Pi, outright — YYLO holds no transcripts and wants none.
• Model choice and mid-session switching: Pi — "15+ providers, hundreds of models" against a control plane that forwards selection to whatever it dispatches.
• The record of what a unit of work was and where it landed: YYLO — the ledger entry ties intent, response, and landing commit together; session files hold dialogue.
• Landing finished work: YYLO — a serialized queue against no documented arbiter at all.
• Fan-out with per-task blast radius: YYLO — Pi's own "No sub-agents" stance points coordination outward, and exact-base worktrees plus concurrency caps are where it lands.
• Driving one from inside the other: both — documented in both directions, with no gate pending.

Choose the layer you are missing, then the package. A better conversation with your code is a Pi-shaped want, and the tree it keeps is worth having. What a conversation cannot arrange for itself is admission — bounds, isolation, the record that outlives the terminal — and that tier belongs to YYLO. The shortest path to running both is the wiring guide; decisions still gathering evidence wait on the comparison hub.