The orchestrator

One input box for the whole workspace. What you type there is split into tasks, and each task is sent to a project and run in a terminal.

Where it is

Press Terminals on the top bar. The view holds every open project side by side, and the input box sits across the bottom, under the columns. A paired phone has the same input box. See The phone’s sections.

The strip at the top of this view carries Back to Main Editor, Add a Project, Build, Reviews, Git and the settings gear.

What it does with a request

The request goes to the orchestrator model, together with a description of your workspace.

• Every project the app has ever opened and still finds on disk, with the feature areas of its WorkMap.
• The open terminals of each project, whether each one is running, the last prompt it ran and how many prompts wait behind it.
• The closed worktrees you can reopen.
• The models you can use and their reasoning levels.
• The names of the files you staged.

The model has no tools and runs in an empty folder, so it never opens a project. Nothing about a project reaches it beyond that description.

A task it is sure of starts the moment the plan lands. Only a task in real doubt becomes a row for you to confirm.

How work is placed

• A follow up on what a terminal is doing, or did last, is queued into that terminal instead of opening a new one.
• A terminal that has never run anything is used before a new one is opened beside it.
• Work that is already running or queued is not started twice.
• Each task gets its own terminal, so two pieces of work in one request run side by side.
• A task asks for between one and six terminals. A project without git always gets one, because only a repository can give each terminal its own worktree.

The prompt each terminal receives is your own request for that task, with the spelling and grammar fixed and nothing added. Names, numbers, paths and file names are kept. If the plan drops one of them, the model is asked again, and a single task that still loses it gets your words exactly as you typed them.

A model you name in the request is the one the task runs on, even when the task joins a terminal that was on another model. Anything you do not name uses the default for new terminals.

Confirmation rows

A row sits above the input and spans its width. It carries these parts.

• The project, as a dropdown over every project the app knows.
• The exact prompt the terminal will receive, cut to two lines. Click it to read the rest.
• A line with the number of terminals, the model and the files and skills sent with the task.
• A tick that starts the task and an x that drops it.

The model on the row is a control. Click it for the model list, or right-click it to step through the reasoning levels. What the row shows is what its terminals run on.

A task whose project could not be worked out is flagged, and its tick stays off until you pick the project.

When the files you staged would go to tasks in more than one project, none of those tasks starts by itself. Each one becomes a row, so you see which file goes where before anything runs.

Rows pile up across requests, and each one starts or is dropped on its own.

The model selector

To the right of the + is a small square showing the mark of the orchestrator model's provider. Click it for the model list, which opens upward.

• Click a model to pick it.
• Right-click a model to step that model to its next reasoning level. Right-click the square to do it for the selected model. Each model keeps its own level.
• Only Claude and Codex models are offered, because planning runs through their command line tools. Models on a custom endpoint are not.

The default is the Fallback model from Settings > AI Providers, and your pick is kept across launches.

Accounts in the lists

Every model row in these lists, in the selector and on a confirmation row, ends with the account that model would run on, shown as its plan and a shortened address. Hover it for the account in full, with every usage window and when it resets. Click it to step to the provider's next account. The row itself still picks the model.

The account only shows when the provider has a linked account. While the usage autopilot is on it reads Usage Pooled and is not a control, because the autopilot picks the account for each run. See Usage autopilot.

Conversations

Not every request is work. A question about the app's own state, such as which projects it can work on or what a terminal is doing, or a greeting, is answered instead of queued.

Answers land in the Conversations panel, opened with the button beside Prompts. An answer opens the panel by itself. Work does not, because the rows and the terminals already show it.

The panel records what came of every request. That is the answer, a line for each task of a plan, or the reason a plan failed. A session is one calendar day, so there is one tab per day. The current one is Today's Session, and the three most recent days are kept. Sending a request while an older day is open brings the panel back to today.

The panel closes with its button, a click outside it or Escape.

It never answers for a terminal

A question about a project, or one addressed to a terminal, is work for that terminal, not something the orchestrator answers. It becomes a task with your question as its prompt, in the terminal or the project you named.

Asking for terminals

A request that names no work, like asking for four terminals in a project, opens that many terminals, empty and ready. Nothing is queued into them and no run starts.

Goals and stopping work

You can ask for a task as a goal, something a terminal keeps working at until a condition holds. The task's prompt is then written as /goal followed by the condition, so the row shows exactly what the terminal receives. See Goals.

A request can also end work. A stop ends the run and drops what was queued behind it. A close does that and also closes the terminal, which retires its worktree.

• A stop the model is sure of happens at once, because you already said stop.
• A close always waits for your tick, because a worktree may hold work that is not merged yet.
• A stop that could mean more than one terminal also waits. It shows as a row with one button per terminal, each naming its project, its title and its last prompt.

Work only ends when you clearly ask to stop, cancel, kill or close something you named.

Where unrelated work starts

A terminal that finished its work and sits idle still holds that work, meaning its conversation, its branch and its commits. New work that has nothing to do with it can start there or in a new terminal.

Settings > Terminal > Terminal for unrelated work decides. The choices are Ask, New terminal and Existing terminal. On Ask, the row offers both places by name, and the one you pick is saved to the setting, so the next such task follows it without asking. Set it back to Ask in Settings to be asked again.

Closed worktrees

The orchestrator also sees the worktrees of terminals you closed, named after the last thing committed in them. A follow up on that work can go back into one. Starting the task reopens the worktree under its own terminal, with the conversation it had. If that worktree was deleted after the plan was made, the task gets a new terminal instead.

Edges worth knowing

• An empty request does nothing.
• With no known projects, the plan stops before spending a run and says there are no projects to send work to.
• Sending again while a plan is being made is ignored until the plan lands. A shimmering Working sits in the field meanwhile and gives way as soon as you type.
• A plan that takes too long is stopped and reported as timed out.
• A task for a project that is known but closed is placed as usual, and starting it opens that project again.
• A follow up whose terminal was closed before you pressed the tick opens a terminal of its own.
• Two tasks for one project become two rows, and each tick opens its own terminals in that project.