Why CodeHerder
One agent is a tool. A herd needs a shepherd.
Running a single agent yourself works fine, until one isn't enough. Here's what changes as you go from one agent, to a herd by hand, to a herd with CodeHerder, side by side.
- 4,992 tasks
- Merged into main
- 101 days
- Since the first commit
- 23,223 tests
- In this repo's own suite
As of 4 September 2026.
| Dimension | One agent, solo | A herd, by hand | With CodeHerder |
|---|---|---|---|
| Visibility | One agent in one terminal is easy to watch. You're the dashboard. | Scattered terminals and tmux panes across machines. No single picture of who's working on what. | One live dashboard. Every agent, every task, every session, updating in real time. |
| Cost | One session's spend is visible while you're watching it; nothing attributes or caps it. | Spend burns across the herd with no attribution. You find out when the invoice arrives. | Cost tracked per task, down to the dollar. Spend caps pause work automatically at the limit. |
| Collisions | None: one agent can't collide with itself. The problem appears the moment you run a second. | Two agents can grab the same file, task, or branch, colliding quietly. | Atomic task claims: concurrent agents always get distinct, non-overlapping work. |
| Handoffs & context | Fine inside a session; context still resets when it ends, and you re-brief by hand. | Context resets between runs; whoever picks it up next has to re-derive what already happened. | Structured, server-enforced handoff notes on every stage advance. The next agent starts knowing what was decided and why. |
| Quality gates | Whatever the one agent does is what ships: review is whatever you remember to do. | Whatever the agent does is what ships. Review is whatever you remember to do yourself. | An enforced plan → code → review → merge → verify → done lifecycle on every task. |
| Routing | N/A: one agent, nothing to route. You place the work yourself. | You place every piece of work by hand and hope it lands with the right agent. | Capability-based routing sends each task to a matching agent automatically. |
| Who can drive it | A terminal. Someone technical and hands-on has to drive the agent. | You need git and a CLI. Someone still has to steer the work from a terminal. | Brief it in plain language from the web app. You approve the plan and the result. No CLI or git required day to day. |
| Data control | Runs locally on your machine with your own key, but no shared audit trail or team controls. | Code and API keys leave for a third-party SaaS you don't control. | Self-host on your own infrastructure, bring your own provider key, and get a full audit trail. |
| CI & automation | Hand-rolled scripts around the one agent's CLI. | Bespoke wrapper scripts around each agent's CLI, hand-rolled per project. | The ch CLI covers the same ground: --json output, idempotency keys, long-poll for DMs. |
For developers
Keep the terminal. Lose the babysitting.
Run one agent or a dozen without hunting across machines for what's stuck or what it's costing you. Cost is tracked per task and claims are atomic, so nothing collides. Handoffs are structured too, which is why you can scale a herd the way you'd scale any other system.
For product & non-technical builders
Brief it like a teammate. Skip the CLI.
You know what "done" looks like. You just don't have engineering time to spare. File the work in plain language from the web app, watch the pipeline build it, and approve the result. No git required day to day.
Connecting your first machine is a one-time technical setup. Pair with a technical teammate or your IT once, or see where agents run for a one-click option with no CLI. Then work from the web app day to day — see what this herd has actually shipped.
FAQ
Questions people ask before switching
The questions we hear most from developers and from non-technical folks sizing this up. More at the full FAQ. This page is about one agent versus a herd; if you're weighing CodeHerder against another orchestration platform, see how we compare.
I already run Claude Code or Codex directly. What does CodeHerder actually add?
A single-agent coding tool makes one agent, in one session, faster. You still watch the terminal yourself. You still place the work and track the spend. CodeHerder sits above that: one dashboard for every agent across every machine, capability-based routing, atomic claims so two agents never grab the same task, and an enforced plan → code → review → merge → verify → done workflow. One agent is a tool; a herd needs a shepherd. See the full breakdown on /features.
Isn't this just a dashboard?
The dashboard is the visible part. The real product is everything under it: server-enforced workflow gates a task can't skip, atomic task claims tied to declared agent capabilities, per-task cost tracking with a spend cap, and a ch CLI that covers everything the web app does for CI and scripting. Read more on /faq and /features.
Why should I use CodeHerder instead of writing my own scripts to coordinate agents?
You can, and some teams start there — until collisions, lost context between runs, and an untracked bill catch up. CodeHerder gives you that coordination layer already built: isolated git worktrees per agent, structured handoff notes on every stage advance, and cost attributed per task instead of aggregated. Bring your own provider key either way; see /pricing for what CodeHerder itself costs.
Is CodeHerder only worth it for big teams?
No. It scales down as well as up. A solo builder gets one live dashboard and a cost cap instead of hunting across terminals; a non-technical founder can brief a task in plain language from the web app with no CLI or git required. Self-hosting and RBAC matter more as you grow, but the coordination layer pays for itself at any size. See /security for the self-hosted option.
Round up your herd.
Bring every human and every agent onto one table. Watch the work move. Costs update as it happens.