Pi

What you have on its own

Pi is the newest and least well-known harness on this page. It earns a spot here on its own merits: a non-interactive print mode, a CLI built to resume a session by id, and its own way of loading skills.

Two things aren't wired up yet: resume and cost tracking, covered below. It isn't a gap in pi itself: Pi's CLI already takes a caller-supplied session id, something Codex and OpenCode can't do, and CodeHerder already reserves one for it before the process starts. The device just doesn't pass that id through yet.

What changes when a herd runs it

Pi alone doesn't do any of this either. Add it to a herd, and:

• One dashboard for every agent, on every machine, instead of a terminal per machine.
• Atomic task claims, so two agents can never grab the same piece of work.
• An enforced plan, code, review, merge, verify, done workflow on every task.
• Cost tracked per task, not just a total bill you see once a month.

How CodeHerder launches it

CodeHerder execs pi in print mode with the task brief as a trailing argument. Set it up once with ch agent config set <agent-id> --harness pi --cap model:sonnet. Pi's own --session-id flag is exactly the hook resume needs, and CodeHerder already sets a session id aside for it before the process starts; the device just doesn't hand that id to the pi process yet, so a paused stage restarts from the beginning instead of picking the conversation back up.

Cost tracking depends on the same missing piece. The sweeper finds a session by reading --session-id off the running process, the same trick it uses for Claude. With that flag absent there's no id to find, so a pi run isn't cost-tracked today. Once the device passes the flag through, cost comes from the same kind of JSONL transcript, under ~/.pi/agent/sessions, that already backs Claude and Codex.

Skills don't reach pi through a repo-linked folder the way they do for the other four harnesses. Pi only loads project skills when it considers the project trusted, and that check never resolves true under a non-interactive spawn. Handing it a skills directory directly through its own --skill flag sidesteps that, without changing anything about the repo's trust state for a human who later runs pi there interactively.

What works today, and what doesn't

Resume

Not yet. pi's CLI takes a caller-supplied --session-id, something Codex and OpenCode can't do, and CodeHerder already reserves a session id for it before the process starts. The device just doesn't pass that id to pi yet, so a paused stage restarts from the beginning instead of picking the conversation back up.

Cost tracking

Not yet. The cost sweeper looks for pi's session id in its own --session-id flag, the same trick it uses for Claude. That flag isn't in pi's argv yet, so there's nothing to look up and a pi run isn't cost-tracked today. Once it is, the transcript is already sitting there: a JSONL file under ~/.pi/agent/sessions.

Skills

Delivered via the --skill <dir> flag, not a repo-linked directory.

Sign-in check

Not yet. There's no dedicated sign-in probe for pi. The device confirms the binary is on PATH, not whether it's signed in.

Getting it onto a device

Routing is gated on the bin:pi capability token, the same mechanism as Codex, Cursor, and OpenCode. See the sign-in row above for what's not verified yet.

See capabilities for how routing works, and adding a device for the connection walkthrough.

Mixed herds

An agent can carry an ordered list of launch configs, each with its own harness. Give one config in the ordered list to Pi, and a fallback to a harness that already has an auth check, so a stage still runs even before Pi has one of its own. Reorder or disable any config in that list without touching the workflow itself.