When it goes wrong
Every agent takes a wrong turn eventually. What matters is what happens next: whether it asks, whether it stops, or shows you the cost. Here is exactly what CodeHerder does, and where the limits actually sit.
Nine mechanisms, already shipped
None of this is a promise. Each one is a real mechanism, live in the product today.
When it hits a decision
An agent that reaches a real decision point does not guess its way past it. It posts a question and waits. The task's status turns to blocked, with a note that reads "Waiting for human answer to agent question." Answer from the Dashboard or from the task itself, and the agent picks up right where it stopped.
When an agent needs your input →When review sends it back
The first build attempt runs on the standard model tier. A send-back from review, from verify, or from the merge stage changes that: every attempt after the first rejection runs on the more capable tier instead. This is the shipped default whether the task is a feature, a bug, a story, or a lightweight task. There is nothing to turn on.
Automatic model escalation on rework →When it keeps failing
A send-back into the build stage carries its own round cap, whether it comes from review, from verify, or from the merge stage, each counted on its own. The built-in workflow types cap every edge at three rounds. A task that hits a cap stops there: CodeHerder moves it to blocked and files a note naming how many rounds it ran and which stage to resume from. A person decides what happens next.
The reject-loop round cap →When cost is the worry
Set a lifetime limit on one task, on a whole workspace, or as an account-wide default; CodeHerder applies whichever one the task is closest to hitting. Before a cap binds, the task owner gets an early warning, and a running session gets its own notice at 50%, 80%, and 100%. The account-wide cap and the workspace budget need the Pro plan, and a task with none set shows "no budget set," not a hidden default.
Spend limits →When the change gets big
CodeHerder measures a task's own change: how many files it touches, how many lines it adds and removes, how many top-level directories it reaches, and how many commits it has made. A workflow stage can require that shape to stay under a limit you set. A task that trips it is refused when it tries to leave the stage, and the refusal names the exact counter and the threshold it crossed.
Change shape →Before any work begins
An approval gate holds CodeHerder's own automatic advance in a pending state until a member signs off. Set one on a task's entry stage. For any of the built-in feature, bug, or story types, that is the only point CodeHerder ever advances a task on its own. A gate holds only that automatic advance. An explicit task-status command still moves the task straight through, gate or no gate.
Approvals and staying in control →The blast radius
Every task gets its own sandbox: an isolated git worktree and branch, so parallel tasks never collide. A stage without its Writable switch on has the push credential stripped from its own environment, on every device, with no setup required. Device isolation itself does need setup: without a dedicated agent user or a container, a stage runs as the same OS user that started the device server, reaching whatever that account can reach. Three documented options shrink that boundary further.
Isolating agent runs on a device →When it stops
A blocker records who filed it, whether a person, an agent, or CodeHerder itself. It also records when, and the reason. A task can carry more than one at a time. Some clear on their own: an unmet dependency, a release time you set, an answered question. Any other blocker waits for a person to resolve it by hand.
Blockers and blocked tasks →What rework costs
A task that needed rework usually spends across two model tiers instead of one, and the task's own cost breakdown shows both, stage by stage, so the extra cost is never buried in a single total. Across our own production runs, the blended mean cost of a shipped story, rework included, is $11.93. Estimate your own workload with the calculator.
Understanding costs →FAQ
Yes, by default. Review still checks the code before merge, and the merge stage itself fixes a red pipeline or a conflict on its own. Add an approval gate on the task's entry stage if you want a person to approve before an agent starts the task at all.
Each send-back into the build stage has its own round cap, three rounds by default. A task that hits the cap stops and moves to blocked, with a note naming the stage to resume from. A person then resumes it or cancels it.
Not on its own, if you set a limit. Cap one task, a whole workspace, or the account-wide default, and CodeHerder stops active sessions the moment a cap is reached. The account-wide cap and the workspace budget need the Pro plan; a task with none set shows "no budget set."
Not on its own. Each task works inside an isolated git worktree of the repository you attached to it. What else that process can reach depends on your own device setup, so lock that down if you want a harder boundary.
Yes, when it hits a real decision point. It posts a structured question, and the task waits at blocked until you answer. For something it just wants you to see, it posts a lighter heads-up note instead and keeps working.
It tries hard not to. The merge stage fixes a pipeline failure its own change caused, and resolves an ordinary conflict itself before landing. If it meets something it cannot fix safely, it hands the task back to code with a comment, or files a blocker for a person.
Bring a real task, and watch what happens the first time something doesn't go to plan.
