Every config key

The 25 settings AutoDev reads from config.json, on the project and on the machine, with each default, its environment variable where it has one, and what it does.

How a value is chosen #

Settings persist to a config.json, which autodev config set <key> <value> writes and autodev config unset <key> edits. Which of the two files a key lives in is below. The project's file is in your repository, so a setting travels with the project and is reviewed in a pull request.

An environment variable wins over the file when it is set. A value that does not fit its key, such as a negative number or a provider that does not exist, is ignored in the environment, and the file's value stands. A config.json that does not parse, or that fails validation, is read as an empty config. Only the flat keys have an environment variable: the nested keys, notify and capability, are read from the file alone.

Numbers must be positive. Booleans take true, false, 1, 0, on or off in autodev config set, and the environment also takes yes and no. A key with no default has nothing set until you set it.

autodev config set maxSpendUsd 25
autodev config set notify.url https://ntfy.sh/<topic>
autodev config unset maxSpendUsd

The project and the machine #

Two files hold settings.

autodev config set writes each key to its own file, and autodev config shows the value in force and where it came from.

suspendOnCompletion is the machine's because suspending stops every run on the box. With two projects working at once, a setting per project would let them disagree about whether the machine may sleep, and the first to finish would put the other to sleep in the middle of its work.

notify is the machine's for two reasons. The phone it reaches is yours and not the project's, so a fresh clone or worktree would otherwise notify nobody. And the topic in notify.url works like a password, which must not sit in a file that travels with a repository.

A value an older AutoDev wrote for one of these keys into a project's config.json is still read when the machine has none of its own, and autodev config unset clears both, so it cannot come back.

Run #

Each participant answers for its own provider, model and effort, in its file: autodev team pin sets the model and the effort, and the provider is the one the participant was added with. The three run-level keys above are what is left of a time when a project had one agent. The panel's Config screen leaves them out, and autodev config still lists them.

model and effort are free-form strings. There is deliberately no fixed list: model aliases drift, and a list AutoDev kept would be wrong the morning a new model ships. In a participant's file, the suggested values for effort are low, medium, high, xhigh and max.

autocompact is a free-form string, like model and effort: AutoDev does not check it, and claude rejects a value it does not accept.

The three Args keys are split on whitespace, so an argument that contains a space cannot be written in them.

Guardrails #

These settings pause the loop cleanly when they are reached.

The spend cap is soft. AutoDev checks it between tasks, so a run can overshoot by roughly one task's cost before it pauses.

maxAcceptChecks counts the audit. When a participant says the objective is met, an independent audit reads the claim against the objective, and a gap it finds goes back to the team as a post. The run pauses once the audit has found gaps more times than this key allows, and a message from you resumes it.

When a run waits or gives up #

A run can wait for three reasons, and they are bounded in three ways.

• A usage limit. A participant's engine, which is a provider with its model and effort, reports a limit. The turn moves to the next engine in the participant's failover chain. When every engine is limited, the run waits for whichever comes back first. No key bounds this wait, since it ends by itself, and it does not count as an iteration or as run time.
• A wait a participant asked for. A participant that has to hold, for example while another session finishes, posts a wait. The run checks again at growing intervals, and maxWaitMin and waitRecheckMaxMin bound it. When maxWaitMin is spent the run pauses, and a message from you or autodev start continues it.
• An infrastructure failure. The CLI crashed or timed out, or it reported a limit before AutoDev could read its reset. The first retry is at once. The next ones wait 1, 2, 4, 8, 15 and 30 minutes, and then an hour each. After the twelfth failure in a row the run gives up, having waited about five hours, and pauses. It never waits past the moment a limited engine comes back, because the next attempt then goes to it. autodev start tries again. No key changes this schedule.

Two fixed limits stop a run that is going nowhere, and they have no key either: 5 steps in a row that fail on AutoDev's own side pause the run as an error, and 10 iterations in a row with no verified work pause it as stuck.

Gates #

A pending gate waits for autodev approve or autodev deny.

Checkpoints #

Computer use #

The keys of the capability.computerUse block let participants see and operate web pages, in a browser AutoDev keeps for the run. They live in the project's file and have no environment variable.

With the default profile, you log in to a site once and every later run has that login: autodev browser login <url> opens the page, and the panel has the same action. autodev browser login has the details.

autodev config set capability.computerUse.enabled true
autodev config set capability.computerUse.headless false

Notifications #

The keys of the notify block send a message to your phone when a run finishes, stops on its own or needs you. They live in the machine's file, and they have no environment variable.

The message is sent once for each thing that needs you, in any project on the machine, and it is one of three:

The title is AutoDev · <project>. A run you stop or pause yourself sends nothing. The POST has a 5-second timeout and is tried once more if it fails, and the log records notify.sent, notify.failed or notify.off, never the address. The editor applies the same rule to its own notification, so an event that one of them announced is not announced again by the other.

autodev config set notify.url https://ntfy.sh/<topic>
autodev config set notify.format json

Suspending the machine #

With suspendOnCompletion on, AutoDev puts the machine to sleep when a run no longer needs it, so a night's run does not leave the machine awake until morning. It is off by default, it only acts on Windows, and it sleeps rather than hibernates.

It suspends only when all of these hold:

• The run ended because it completed, with no gate or proposal pending, or because it stopped and waits for you: paused by the system, halted on a gate or a proposal, asking you something, or in error.
• You did not stop or pause the run yourself.
• No other project on the machine has a run alive, since suspending stops all of them.
• No phone can answer through the server. A running server with a phone paired or pairing prevents it, and so does a server that cannot say. A server with no phone does not.
• The machine has been idle for 20 minutes, meaning no keyboard or mouse.

When they hold, AutoDev shows a message on screen that says the machine will suspend, waits 60 seconds, and checks every condition again. Touching the mouse or the keyboard in that minute cancels it. The log records the reason for each refusal.

An example #

{
  "suspendOnCompletion": true,
  "notify": { "url": "https://ntfy.sh/<topic>", "format": "ntfy" }
}

{
  "maxIterations": 500,
  "maxSpendUsd": 25,
  "gateMode": "gated",
  "checkpoints": true,
  "capability": { "computerUse": { "enabled": true, "headless": false } }
}