When it goes wrong
Every agent gets a task wrong sometimes. This page says what CodeHerder does then. Two questions come first: will it stop, and what will it cost? Each card says if the check runs by default or if you turn it on.
Nine mechanisms
Some checks run by default. You turn on the others. Each card says what you must set up and which plan it needs.
When it hits a decision
On by default
An agent that reaches a real decision posts a question and stops. The task moves to blocked. Its note reads "Waiting for human answer to agent question". Answer from the Dashboard or from the task. A new session then continues the same stage, with your answer in its brief.
When an agent needs your input →When review sends it back
On by default
The first build attempt runs on the standard model tier. After a send-back, every later attempt runs on the stronger tier. Review and verify can send a task back. So can merge. A plain task has no review or verify stage, so its only send-back comes from merge. Nothing needs setup.
Automatic model escalation on rework →When it keeps failing
On by default
Each stage has a cap on send-backs into it. The built-in workflows set the cap to three rounds. A task that hits the cap moves to blocked. The note names the stage and the round count. It also names the send-back that hit the cap. It also lists the commands to review and unblock the task. A person decides what happens next.
The reject-loop round cap →When cost is the worry
You turn it on · Pro plan
You can set a lifetime limit on one task, on a workspace, or as an account default. Every spend limit needs the Pro plan, and none is on until you set it. The account default counts only for a task with no budget of its own. CodeHerder applies the limit that the task has used most. The owner gets a warning at 80% of a task or workspace budget. A check about every five minutes stops sessions that are over a cap. New sessions do not start. A task can run a little over before the check.
Spend limits →When the change gets big
You turn it on · Starter plan
CodeHerder measures the size of each task's change. A stage gate can limit files changed and lines changed. It can also limit top-level directories. It cannot limit commits. The limit is off by default, and no built-in workflow sets one. You add it when you edit a workflow, which needs the Starter plan. A task over the limit cannot leave the stage. The refusal names the counter. It also shows the value and the limit.
Change shape →Before any work begins
You turn it on · Starter plan
An approval gate holds a task until someone signs off. A manual status change waits too. The approver can be any person, any agent, or one member you name. The person who asked and the task's own session can never approve. Gates need the Starter plan, and no built-in workflow has one. Set one on the entry stage. Agents advance the later stages themselves.
Approvals and staying in control →The blast radius
On by default · isolation needs setup
Every task gets its own sandbox: an isolated git worktree and branch. Parallel tasks do not collide. A stage that is not writable has the push credential removed from its environment. This works on every device with no setup. Device isolation needs setup. Without it, a stage runs as the OS user that started the device server. It has all of that user's access. A dedicated agent user, a docker executor or a microVM shrinks that reach. The docker trusted mode does not stop a hostile agent.
Isolating agent runs on a device →When it stops
On by default
A blocker records who filed it. It also records when and why. The filer can be a person, an agent or CodeHerder itself. A task can have several blockers at once. Some clear on their own: an unmet dependency, a release time you set, or an answered question. Any other blocker waits for a person to resolve it.
Blockers and blocked tasks →What rework costs
On by default
A task that needed rework often spends on two model tiers instead of one. The Costs page has a Model by stage view that splits spend by tier and stage. The ch costs command splits spend by model. Across our own production runs, the mean cost of a shipped story, rework included, is $16.92. Use the calculator to estimate your own workload.
Understanding costs →FAQ
Yes, by default. Review still checks the code before merge. The merge agent is told to fix a red pipeline or a conflict. To require a person, turn on one required human approval on your git host. The merge agent can't give it, so it blocks the task and waits for a person. You can also add an approval gate on any stage.
Each stage has a cap on send-backs into it. The built-in workflows set three rounds. A task that hits the cap stops and moves to blocked. The note names the stage and the round count. It also names the send-back that hit the cap. A person then resumes the task or cancels it.
Not if you set a limit. You can cap one task, a workspace or the account default. Every spend limit needs the Pro plan. About every five minutes, CodeHerder stops sessions that are over a cap, and new sessions do not start. A task can run a little over before that check. A task with no limit 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 you only need to see, it posts a lighter note and keeps working.
Review checks the code before merge. The merge agent is told to fix a pipeline failure that its own change caused. It also resolves an ordinary conflict before it lands the change. Sometimes it meets something it cannot fix safely. Then it sends the task back to code with a comment, or files a blocker for a person.
Bring a real task. Watch what happens when something goes wrong.
