Works with

Runs the coding agent you already have

CodeHerder doesn't replace Claude Code, Codex, Cursor, OpenCode, or Pi. It gives whichever one you run a worktree of its own, a task to work from, and a record of what it did.

The support matrix

Five harnesses, one support table

Resume and cost tracking support varies by harness. The table below shows exactly what each one does today.

Support matrix for the five coding-agent CLIs CodeHerder can launch: the command each one runs, whether it can resume a prior session, whether its spend is tracked per task, and how project skills reach it.
Harness	Command	Resume	Cost tracking	Skills
Claude Code	`claude`	Yes. Resumes an existing session with --resume or --session-id.	Tracked. Cost is tailed from the Claude Code transcript under ~/.claude/projects.	.claude/skills
Codex	`codex`	Opt-in. No --session-id flag. CodeHerder can discover the thread id after a run and resume it through codex's own exec resume subcommand, but a device operator has to turn codex-native resume on first (CH_CODEX_RESUME, off by default).	Tracked. Cost is tailed from ~/.codex/sessions, where the CLI writes its own rollout JSONL.	.agents/skills
Cursor	`cursor-agent`	Not yet. cursor-agent mints its own chat id at spawn time, and there's no way to read it before the process starts.	Not yet. cursor-agent streams stream-json to stdout with no local transcript file for the cost sweeper to read. Being re-planned.	.cursor/skills
OpenCode	`opencode`	Not yet. opencode mints its own session id and only resumes a session that already exists, so CodeHerder can't hand it one in advance.	Tracked. Cost is read from opencode's own local SQLite session database.	.opencode/skills
Pi	`pi`	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.	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.	the --skill <dir> flag, not a repo-linked directory

How it's wired

How a task reaches a harness

1. A device connects. Your machine runs the device-server and reports which CLIs it has installed.

2. A task needs a stage worked. Placement matches the stage's required capability, including a harness's bin:<name> token, to a device that actually has it.

3. A worktree gets cut. An isolated git worktree, branched from your default branch, so this task can't collide with any other running work.

4. The harness runs one stage and exits. Fresh process, no shared state, billed on its own.

Full detail on placement and routing is on how it works; on what's locked down on the machine itself, see security.

If you're not the one setting up the machine

You never pick a harness to file a task. Whoever connects the device chooses one when they configure the agent, once. From then on, every task that lands there just runs.

Also fits

Git hosts and machines

Git hosts

GitHubgh
GitLabglab

Your machines

macOS
Linux
Self-host
Bring your own provider key

Round up your herd.

Bring every human and every agent onto one table. Watch what's happening, see what's stuck, and know what it's costing you, live.

Request access →Get started →