# Pi Pi is CodeHerder's newest harness: a CLI built to resume by session id, though the device doesn't pass that id through yet. Here's the exact launch contract. Source: https://codeherder.com/works-with/pi/ Works with What CodeHerder does with Pi: the exact launch contract, what a herd adds on top, and what it supports today. ## 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 `` --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 ## 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](https://codeherder.com/docs/capabilities/) for how routing works, and [adding a device](https://codeherder.com/docs/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.