Diese Seite gibt es noch nicht auf Deutsch, deshalb wird sie auf Englisch angezeigt.
Autonomous loop
Let the orchestrator check back and drive tasks on its own, pick how much it may do without asking, and run repository schedules
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: each interval sits on the same card as the switch it paces.
The card leads with three levels, ordered least-to-most autonomous:
| Option | What it means |
|---|---|
| Only when I ask | Nothing runs unless you start it. No timer, no merging, no issues filed. A change you ask for in chat starts right away. |
| Work on its own, ask me to merge | Starts agents without confirming and finds work when your queue empties. Nothing reaches your default branch without you. This is the default. |
| Merge its own green work | Everything above, plus a second opinion on every PR you approve and a merge once CI is green and that reviewer agreed. Branch protection still applies. |
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.
Auto-merge never merges a task's pull request once someone other than your agent has pushed to its branch, including a push made while the pull request was closed. Your own pushes count as yours when your GitHub account is connected to Foxl. Foxl does not review such a push on your credits, and the pull request waits in Needs you for you to merge it.
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.
The loop itself runs on the chat model saved with your Code settings, or on Claude Sonnet 5.5 for an account that has never saved one; a chat you send yourself uses the model in the picker. Agents it spawns run your account-default assistant - the one shown in the Tasks message box's coding-agent picker. Under Advanced, Spawn agents without confirming (on in all three levels) carries Agents per turn without asking (3 by default): up to that many agents always start right away; above it the orchestrator decides, starting a larger set of routine, independent changes too and giving broad, costly or hard-to-undo work 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. Foxl counts the chain and enforces the limit itself: 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.
A red CI after the task ended
CI often finishes long after a task opened its pull request, by which time the task's agent has ended. When CI fails on a pull request a Foxl Code task opened and no agent is still attached, Foxl Code starts one follow-up task on that same pull request: the same coding agent, on the task's branch, with the failing checks, their annotations and the failing step's log in its instructions. Its fix is pushed to that branch, so the pull request updates rather than a new one opening. It runs at most once per failing commit and twice per pull request (the same ceiling as retries), stops at your daily spend cap for unattended work, and uses credits like any task. When the checks fail again after a fix, Foxl starts another only if different checks failed this time; if exactly the same checks fail again, it stops rather than spend another task on a failure the last fix could not solve. Either way the pull request waits in Needs you, whose card says Foxl stopped fixing it and why. The follow-up appears in your task list as Fix CI: ..., and the original task shows a CI fix button that opens it. Turn it off with Fix red CI automatically under Advanced on this card; a failing build is still reported either way.
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. If a saved choice stops being usable it tells you which repository it is working on instead.
- Its own open-issue budget. Open pull requests waiting on a human are finished work, not a reason to stop, so they do not 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.
What it will not file
Before the loop opens an issue, Foxl checks the repository's issues and pull requests, and files nothing when it cannot check. It does not file:
- an issue that is already open, or one closed or declined in the last 30 days, or work an open or recently merged pull request already covers;
- a copy of an issue it filed itself in the last 30 days;
- work a coding agent cannot finish: one that needs a key, a device, a repository setting, someone to click through a dashboard, or a change to GitHub Actions workflows.
It also stops starting tasks for an issue that has already failed twice in the last 30 days, and stops filing for a while when its last three issues in a week all ended without a pull request. You can still start any of those yourself.
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.
Repository schedules
A schedule on the Schedules page starts a task on one repository at a set time, with the instructions you give it (New schedule). Its cadence is either an interval (5 minutes to 7 days) or Daily: a time and the days to run on, set on your own clock. The editor shows your time zone, the schedule is saved with it and keeps that time through daylight saving changes, and the Next run column shows the next run on your clock. A schedule saved with a UTC time keeps running at that UTC time and is marked UTC in the list; opening it in the editor shows its time on your clock.
One pull request at a time. A schedule's run is skipped while a pull request from one of its earlier runs is still open (a draft from a run whose tests failed included), or while an earlier run is still going, and the schedule says which pull request or task it is waiting for. Merge or close that pull request, or cancel its task to keep the pull request open, and the next run starts as usual. A task with no activity for 14 days is cancelled automatically, its pull request left open, and the schedule then runs again. Separately, your schedules share a limit of three scheduled tasks open at once; a scheduled task waiting in review stops counting toward it 3 days after its run finished, so unmerged pull requests do not stop your other schedules. Run now starts even while an earlier run's pull request is open, but it counts toward the three-task limit and is refused while three scheduled tasks are open.
Scheduled runs do not have to open a pull request. Each schedule picks what a run produces (Each run produces, on the schedule form):
| Outcome | What the run does |
|---|---|
| A pull request | Starts a coding agent, which changes code and pushes a branch. |
| A question for you | Reports the action items it found, as a question you answer. Changes no code. |
| GitHub issues | Files GitHub issues with the reasoning behind each one. Changes no code. |
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. That is what makes "every morning, look at the repo and tell me what needs doing" a schedule.
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:
| Setting | What it controls |
|---|---|
| Level | One of the three above. Picking one sets every switch under Advanced. |
| Interval | How often the loop checks on work that is already running. Default 5 minutes, minimum 1 minute. |
| Quiet hours | A time range when the loop sleeps (for example 22:00-06:00), in your own time zone: the hours are saved with your browser's time zone, so they follow daylight saving. Hours saved with UTC times keep them and are shown on your clock. Leave both values equal to switch it off. |
| Survey cadence | How often it looks for NEW work once your queue is empty. Default 6 hours. |
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 $500. It is measured in real dollars: what every task created that UTC day has spent or still has reserved. Once the day reaches it, the loop, scheduled pull-request runs (including the "Daily check" schedule Foxl adds for each repository you work in, which stays deleted once you delete it) and tasks from newly opened GitHub issues stop starting work until the next UTC day, and if the day's spend cannot be read they do not start either. A schedule that was skipped says why on the Schedules page, and an issue that was not taken up appears in your suggestions. Run now and Solve are not affected; tasks you start yourself are bounded by the per-task ceiling.
The loop only does work when something has actually progressed since the last check - new events, a merged PR, a confirmed-but-unstarted plan. If nothing changed, the tick is a cheap no-op, so an idle account costs nothing.
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.