How it works

Every Foxl Code account has one orchestrator - a per-user agent that turns a conversation into shipped pull requests. It decides whether to just reply, ask you something, file a GitHub Issue, or plan and spawn coding agents, and it keeps an eye on the agents it spawns. At code.foxl.ai it runs in Foxl's cloud using managed Bedrock models and Relay credits. The Foxl desktop app also runs the shared orchestrator locally with your own configured providers (BYOK/BYOA). These are separate model-access paths.

The orchestratorСкопировать ссылку на раздел

The orchestrator is a single reasoning agent per user (not a fixed pipeline). When you chat - whether at code.foxl.ai or inside the Foxl app - it routes your message to one of a few actions:

• Reply - answer a question, no work needed.
• Ask you - put a question in your Needs you queue (and a notification on your phone) before planning. Your answer settles it everywhere it is shown.
• Plan - write a Task Document for multi-step work.
• Spawn - launch one or more coding agents to do the work.

It runs on a model you choose for replies, separate from the model your coding agents use (Claude Opus 5.5 by default), so you can keep orchestration cheap and let the heavy model do the coding. On a device where no chat model was ever picked, Code chat starts on Claude Haiku 5.5; a model you picked stays as it is. On code.foxl.ai, the picker offers Foxl's managed catalog without requiring a desktop connection or personal key. It includes Claude, GPT, GLM, Kimi, Grok, and chat-only Gemma. In the desktop app, the local picker retains your connected providers and subscriptions. See Model access.

Task DocumentsСкопировать ссылку на раздел

A Task Document is the orchestrator's plan, written in markdown. Each top-level checkbox is one unit of work that maps to one pull request:

• The plan carries a title, the checkbox list, an execution status, and an estimated budget.
• Each checkbox can open a GitHub Issue and is tracked as a subtask.
• As agents land PRs, the orchestrator ticks the matching checkboxes.

A Task Document moves through draft -> awaiting_confirmation -> confirmed -> in_progress -> completed (or archived if you drop it).

Confirm once, then fan outСкопировать ссылку на раздел

With the default autonomy level (Work on its own, ask me to merge) a coding request in chat starts agents in the same turn - Foxl tells you what it started instead of asking permission, and still stops to ask when a guess could waste the whole run or the work is hard to reverse. Two things bring the confirmation back:

1. A large request the orchestrator judges worth asking about. Up to your per-turn number (3 by default, "Agents per turn without asking" under Advanced on the Autonomy card) agents always start right away. Above it the orchestrator decides: a larger set of routine, independent changes starts too, while work that is broad, costly or hard to undo gets a Task Document with a cost estimate and one approval button first. You confirm once, and the orchestrator spawns a coding agent for every checkbox in a single step - they run concurrently, each on its own machine, as many at once as your account's model slots allow; with the autonomous loop on, the rest start as earlier ones finish.
2. Asking before every request is one switch under Autonomy's Advanced, Spawn agents without confirming. With it off, each request waits for your Approve, and the question also offers Approve, and don't ask again.

The plan waiting for approval is the one card in Needs you that has no dismiss button, because there is nowhere else in the app to find it.

Watching the agentsСкопировать ссылку на раздел

Once agents are running, the orchestrator can inspect and steer them:

• Read an agent's screen - see exactly what its terminal is showing right now.
• Send input - type into a running agent's terminal.
• Resize - adjust the terminal dimensions.
• Poll active agents - list which agents are still running.
• Resume, retry or cancel an agent - the same controls you have on a task, so it can unblock a paused agent or give a failed one one more go.
• Read GitHub - CI status, the failing build's log, a pull request or issue - confined to the repository you have selected. On your own computer it signs in the way you already do (gh auth login, your git credential helper, or FOXL_CODE_GITHUB_TOKEN).
• Remember the repo - it keeps a short project memory per repository and hands it to the next task there, along with the notes you saved for that repository (see GitHub).
• Build a merge train - combine several open pull requests of a repository into one (see GitHub).

When several of your cloud agents work in one repository at once, each says which files it is about to change and is told which of the others already claimed them. On an overlap the agent is asked to send the other one the change it needs, wait until it is done, or ask you, instead of both editing the same file and colliding when the pull requests merge. Nothing is locked, and an agent's claims end with its task.

This is what lets one orchestrator coordinate several agents at once - checking on each and unblocking it as needed. To have it do this on a schedule without you in the chat, see the autonomous loop.