The run stopped and why

How to read why a run is not moving. The statuses AutoDev uses, the reason it records each time it pauses or stops, and what continues each one.

Read the reason #

A run that stopped records its own reason. autodev status prints the state, autodev report prints the reason next to it, and the panel says the same thing in Needs you and in the status bar. autodev status prints these lines:

autodev status

Project: <name>
Status: <status>
Daemon: pid <n> (alive)
Current task: <task>
Iteration: <n>
Est. cost: $<n>
Heartbeat: <n>s ago
Next resume: <time>
Web: not serving
Waiting: <reason> (<n>m elapsed)

Status is one of idle, running, rate_limited, waiting, paused, gated, awaiting_user, completed or error. Daemon is pid <n> (alive) or stopped. Next resume is the time a limit lifts, or None. Waiting appears only while the status is waiting. A heartbeat gets (stalled?) appended only when the daemon is alive, the run is active and the last heartbeat is 40 minutes old or more.

running, rate_limited and waiting claim that the loop is executing. Seen with no daemon alive, they are the leftovers of a killed run: the status bar shows (stopped) beside them and autodev report shows (stale).

autodev report opens with one line for the reason. A run you paused reads paused by you · daemon stopped. Any other stopped run reads <status> · daemon stopped · <the last reason>, where the reason is the last event that ended something, and a live run reads <status> · alive. In the panel, a run that is paused or in error with no daemon adds a Needs you item that says it will not resume on its own. A run you paused yourself does not, because ending that pause is yours to do. The feed ends with stopped or completed at the time it ended.

You stopped or paused it #

autodev stop and the Stop control end the run at the current iteration, with the status idle and the event Stop requested. autodev pause and the Pause control leave the status paused with Pause requested, and AutoDev remembers that the pause was yours. Neither is a fault, and neither resumes by itself.

AutoDev keeps the two kinds of pause apart: a pause of yours is not reported as something that needs you, and one a guardrail caused is, as the next section shows.

It finished #

The status is completed, and the log has All tasks resolved. The daemon has exited. To give a finished project more work, send a message: the composer in the panel, or autodev send "<message>", which prints Message sent; run started. To start over with an empty thread, autodev new-run archives this one first.

It hit a ceiling #

A guardrail pauses the run, and the status is paused. The reason is an event in the log, with one of these messages:

Message	Cause	What raises it
`Budget reached: spend cap reached (...); pausing`	The estimated spend reached the cap.	`maxSpendUsd`
`Budget reached: runtime budget reached (...); pausing`	The wall-clock budget ran out. Time spent waiting for a limit or a condition does not count.	`maxRuntimeMin`
`Reached max iterations (N); pausing`	The loop hit its iteration cap.	`maxIterations`
`No progress for N iterations; pausing`	No post was verified as work for 10 iterations.	no config key: the default is 10
`Waited ... and gave up`	A wait outlasted its cap.	`maxWaitMin`
`Completion audit still finds gaps; run paused for review — send a message to resume`	The audit reopened the run too many times.	`maxAcceptChecks`
`The thread is producing no work; run paused for review — send a message to resume`	Too many consecutive posts that were not work.	`maxTalkTurns`
`No participants; run paused until a team is set up`	There is no team.	set up the team

A run that starts again pauses again for as long as the limit is still reached, so raise the limit first, with autodev config set or the Config destination, and then continue. Every config key lists the settings.

It gave up on a failing call #

A turn that fails without a usage limit is an infrastructure failure: the CLI would not start, could not be reached, or died. AutoDev tries again on a widening schedule, starting at one second and then waiting 1, 2, 4, 8, 15 and 30 minutes, and then an hour. Each failed turn logs Turn failed (infra); will retry: followed by what the CLI said, and each retry logs Attempt N of 12 failed (...); trying again at <time>. After 12 failures in a row, about five hours, the run pauses with Gave up after 12 failed attempts in a row, over five hours (...); run paused — resume to try again. A turn that works resets the count.

Two cases differ. When the provider's API cannot be reached at all, AutoDev treats the provider as out for everyone on it, like a limit. The event is <provider> could not be reached; trying it again at <time>, the wait is 1, 2, 4 and 8 minutes and then every 15 minutes, there is no deadline, and a participant on another provider carries on meanwhile. Providers and failover tells them apart from a usage limit.

The other case is a participant that keeps ending its turn without posting. Each such turn logs Turn ended without a post, and it names the likely cause when it can: the CLI refused permission for AutoDev's tools, the command line arrived broken on Windows, or the CLI has no thread tools. On the third turn in a row the run pauses with @<participant> ended 3 turns without posting; pausing instead of spending more quota — send a message to resume. Fix the participant's CLI first, since it will end every turn the same way. No agent CLI found and CLI not authenticated cover the two usual causes.

It is waiting, not stopped #

Two statuses look like a stop and are not. The daemon is alive, the heartbeat keeps moving, and the run continues on its own.

rate_limited: every participant is at a usage limit. Next resume is the time the first one returns, and the run continues then. Providers and failover says how the turn moves in the meantime.
waiting: a participant declined to start, for a reason Waiting prints, such as a person working in the same folder. AutoDev checks again, at intervals that grow to 30 minutes, and pauses the run with Waited ... and gave up when the wait passes maxWaitMin, which is 240 minutes by default.

It is waiting on you #

Two statuses are deliberate halts. AutoDev does not restart them, and nothing resumes them on its own.

gated: an irreversible action is waiting. Approve or Deny it in the panel, or run autodev approve or autodev deny. With the default gateMode, auto, AutoDev approves the gates it is shown, so this happens when you set gateMode to gated. An action that was approved and then failed is not tried again: the run stops with Approved action failed; run halted: <action> and the status error.
awaiting_user: the thread handed the turn to you, with @<participant> is waiting for you. The daemon exits, and your next message starts it again. autodev answer is for notices, not for this.

It died #

error means the run paused after 5 consecutive step errors, with the message Pausing after 5 consecutive step errors, or that the process kept dying: Supervised process died N times within 300s; giving up, after 5 restarts inside 5 minutes. The step errors are in the log with their messages.

An active status with Daemon: stopped means the process is gone, killed or with the machine off. autodev with no command relaunches a run left in running, waiting or rate_limited, and autodev start relaunches the daemon whatever the status. What survives a restart says what the new daemon starts from.

Continue it #

Every stop above ends the same way, in one of these:

Send a message. In the panel, the composer starts the run again once a team is set up and trusted. From a terminal, autodev send "<message>".
Run autodev start. It relaunches the daemon and clears a pause. autodev resume on its own only writes the request, so it does not relaunch a daemon that exited.
Approve or Deny a gate.
Run autodev restore to rewind the code to a checkpoint, after autodev stop, when the run went wrong rather than stopped. Checkpoints and restore covers it.
Run autodev new-run to archive the thread and start over.

The panel has no Resume or Retry button. Reading the logs shows where the reasons are written.

This page does not know why a single CLI call failed. The step error, or the CLI's own output in the log, carries that message.