Autonomous loop

By default you drive Foxl Code from the chat. Turn on the autonomous loop and the orchestrator checks back on its own - advancing plans, spawning the next agent, and retrying failures without you in the conversation.

One card, on Schedules

Everything the loop may do unattended, and how often it does it, is a single Autonomy card on the Schedules page - beside the schedules that start a task on a repo at a set time. There is no Autonomy pane in Settings: an interval is meaningless without the switch it paces, so the two used to be one screen apart with each side carrying a paragraph pointing at the other.

The card leads with three levels, ordered least-to-most autonomous:

The middle option is where the split matters: starting work you asked for is a confirmation removed, whereas merging is the one action that changes what ships. Those deserve different answers.

The six individual switches behind the levels are all still there under Advanced, and picking a level sets every one of them. Setting them by hand into a combination that is not one of the three simply reads as Custom.

Each timer sits under the switch it paces rather than being a number with no subject - the tick interval and quiet hours under "wake up on a timer", the survey cadence under "find work when the queue is empty" - and the whole card saves once.

What it does

On a schedule, the loop wakes the orchestrator with the current state of your active Task Documents and lets it:

• Tick checkboxes as their pull requests land.
• Spawn missing agents for any confirmed plan that hasn't fanned out yet.
• Retry a failed subtask.
• Complete a Task Document when every subtask reaches a terminal state.

This is what makes a multi-PR plan run start to finish after a single confirmation, instead of dead-ending until your next message.

Agents it spawns run your account-default assistant - the one shown in the Tasks header. Under Advanced, Spawn agents without confirming (on in the two upper levels) carries Agents per turn without asking (3 by default): a request that would split into more pull requests than that gets a plan with a cost estimate and one approval button first.

Retries have a ceiling

A retry is a new task with a fresh budget, so a loop that keeps deciding to try again could spend one budget after another on a single issue with nothing counting the chain. The limit is now real rather than an instruction in the prompt: one automatic retry, and one manual one after that. Once it is reached, the loop is told the refusal is final rather than something to wait and re-attempt.

Finding work when your queue is empty

With the middle or top preset on, the loop looks for work once nothing is running. Two things bound it:

• It only looks at repositories you have actually run a task in. You pick the repository from a list of exactly those, and the page says "Working on owner/name" underneath - it used to be a free-text box over a rule you could not see, so a typo, or a repository you have access to but never used, was silently refused and it went and worked somewhere else. If a saved choice stops being usable it tells you, rather than pretending.
• Its own open-issue budget. Open pull requests waiting on a human are finished work, not a reason to stop, so they no longer park the loop.

Consecutive empty surveys are counted and, after two, the Autonomy card says so in its status line. At that point the loop must either act or say plainly what it is blocked on - it used to be able to report success while filing nothing for days.

It learns from a No

When you dismiss or decline something with a reason, the next time the loop goes looking for work it is told what you turned down and why, and does not propose it again. Declining an issue is also what frees it to look again, since it stops surveying while its own filed issues are unread.

When a task fails, Foxl writes down one line about why and hands that to the next task in the same repository.

Scheduled runs do not have to open a pull request

A repository schedule picks what each run produces (Each run produces, on the schedule form):

The two report-only outcomes are enforced by where they run rather than by asking nicely in the prompt: they never get a checkout, so there is nothing to push. A question arrives the same way every other Foxl Code question does, so it reaches a locked phone and can be answered from there. Issues count against the same open-issue budget above, so two features cannot quietly fill your tracker together.

This is what makes "every morning, look at the repo and tell me what needs doing" expressible - before, every schedule ended with an agent pushing a branch at 09:00.

Answering the loop

A question from the loop is an ordinary chat turn - the ask on the left, your answer in a bubble on the right, notices in the same column. Your reply lands in the conversation you answered in and appears while you are looking at it.

A reply does not wait for the loop's next scheduled beat, and it is not discarded when the loop is switched off: turning the loop off means "stop deciding work for me", not "ignore what I typed".

Watching it

The Autonomy card answers whether the loop is alive in one line: when it last checked in, when it last did work, and how much of today's daily cap it has spent. It turns amber when the loop is waking up but doing nothing - a spent daily cap, quiet hours covering now, or nothing left to advance all look like that - and it says so when the last two or more surveys filed nothing. What the loop actually produces - issues it filed, questions it asked, pull requests it moved - shows up on Work, in Needs you and in the Activity tab.

Timing and cost control

The three timers are on the same Autonomy card, each under the switch it paces:

The Daily cap for unattended work is the one setting that is not on this card: it lives in Settings > Code > Defaults & budget, beside the per-task ceiling, because that is the other spend limit. Default $0.50. Only the loop's own wake-ups count against it, at a fixed rate per wake-up, so it is a ceiling on unattended activity rather than a reading of real spend; tasks you start yourself are bounded by the per-task ceiling.

Every other guardrail still applies: each agent it spawns has its own per-task budget, and a task will not start at all for an account that has run out of credits.

Related

• Work - the queue where the loop's questions and proposals arrive.
• Coding agents - the container the loop's agents run in.
• Review on approval - the second opinion the top preset turns on.