A multi-file feature asks an AI coding assistant to hold many details at once: product requirements, project conventions, dependencies, tests, and the files that need changes. Orchestrate Mode separates that work. A strong model explores the project and creates a plan, then lower-cost subagents implement focused tasks.
That split can cut token spend by 40 to 60 percent on multi-file features, depending on the task and the model aliases you configure. It also gives you a visible checklist of the work as the feature moves from exploration to implementation.
Why Orchestrate Mode matters
A single agent can plan and build a feature in one long context. That approach makes every implementation detail part of the same conversation, even when the agent only needs one small piece of information for a particular edit.
Orchestrate Mode assigns different jobs to different agents. The orchestrator handles project-level reasoning. Builders handle focused changes such as updating a component, adding a test, or changing an API call. Each builder receives a scoped task and the tools it needs to complete the implementation.
The model split gives you two practical benefits:
- A capable model spends its time on decomposition, dependencies, and review.
- A configured Cheap model handles routine implementation work at a lower cost.
The savings depend on the work. A small one-file edit may not need orchestration. A feature that touches a data layer, UI, tests, and documentation gives the workflow more room to pay off.
How Orchestrate Mode works
Select Orchestrate in the chat mode selector, or enter /orchestrate. Describe the feature you want to build with enough detail for the planner to identify the outcome and boundaries.
Tarsk then follows this workflow:
- The orchestrator explores the project. It reads relevant files, checks project conventions, and identifies dependencies.
- The orchestrator creates a checklist. It divides the request into small subtasks with clear acceptance criteria.
- Builders implement the subtasks. Each builder receives one focused assignment and the full Build tool set.
- The orchestrator reviews the results. It checks returned work, identifies gaps, and delegates follow-up tasks when needed.
- You review the workspace. The completed changes, todos, and subagent activity remain visible in the current thread.
The orchestrator stays read-only in this mode. It can inspect files and coordinate work, but it must delegate file changes to builders. That boundary keeps the planner focused on decisions and prevents it from making an unplanned edit while it investigates the project.
Configure the model aliases
Orchestrate Mode needs a Cheap model alias. Open Project Settings → Advanced → Model Aliases and assign a lower-cost model to Cheap before you start.
If you configure a Smart alias, Tarsk uses it for orchestration. Without Smart, Tarsk uses your current chat model for the planning work. Every Orchestrate builder uses the configured Cheap alias.
Choose the aliases around the work you expect to delegate. The Smart model should handle repository exploration, task boundaries, and review. The Cheap model should handle focused edits and checks with clear instructions.
A concrete example
Suppose you want to add password visibility toggles to a login form and cover the change with component tests. A useful Orchestrate request might be:
Add a password visibility toggle to the login form. Match the existing button and icon patterns, preserve keyboard access, and add component tests for the hidden and visible states.The orchestrator may divide the work into tasks such as:
- Inspect the login form and existing icon-button patterns.
- Add the visibility state and accessible toggle.
- Add tests for both password states and keyboard interaction.
- Run the relevant checks and review the final diff.
The builders can work from those focused prompts. The first builder might report the existing conventions. Another can implement the control. A test-focused builder can verify the behavior against the project’s current testing patterns. The orchestrator uses those results to decide whether the feature is complete or needs another pass.
The same pattern fits an API pagination change. One task can update the client, another can update the list view after the client change, and a final task can cover loading and empty states. Explicit dependencies help the orchestrator assign work in a safe order.
Context scoping keeps tasks focused
Context includes the instructions, files, conversation details, and requirements an AI can see for its current job. Orchestrate Mode gives each builder the context for its assigned subtask instead of expecting every builder to carry the entire feature history.
A strong builder prompt names the exact goal, relevant code area, expected behavior, constraints, acceptance criteria, and checks to run. The orchestrator supplies that information when it delegates the task.
Context scoping reduces repeated explanation and makes a task easier to verify. It also creates a responsibility for the planner: unstated assumptions do not automatically travel to every builder. If a builder needs a specific design rule or dependency, the orchestrator must include it in the assignment.
Context scoping describes a workflow boundary. It does not create a security boundary or guarantee a separate project copy. Normal project permissions and command approvals still apply.
Common mistakes
Choosing Orchestrate for a tiny edit
A one-line label change usually needs one direct implementation request. Orchestration adds planning and review steps, so use it when the task has enough moving parts to benefit from delegation.
Giving the planner a vague goal
“Make the app better” leaves too many product decisions open. Describe the user outcome, affected area, constraints, and success criteria. Use a request such as “Add loading, empty, and error states to the settings page while matching the existing card layout.”
Treating Cheap as a universal fallback
The Cheap alias handles delegated implementation. It may need more precise instructions for ambiguous requirements or broad architectural decisions. Give builders small tasks that end with a checkable result.
Assuming delegation guarantees correctness
Orchestrate Mode coordinates work. It does not guarantee complete tests, conflict-free edits, or production readiness. Review the final diff and run the checks that matter for the feature.
Forgetting the Cheap alias
Tarsk cannot send builders to a model until you configure Cheap. Set the alias before selecting Orchestrate. If the mode selector asks for configuration, open the project’s Model Aliases settings and assign a model.
When to use Orchestrate Mode
Choose Orchestrate when a feature crosses several files, needs a clear dependency order, or benefits from separate implementation and review tasks. It works well for UI changes with tests, API updates that affect views, and settings work that touches shared behavior.
Use Build for a focused change that one agent can understand and complete directly. Use Plan when you want a checklist without edits. Orchestrate combines a read-only planning phase with delegated implementation when the request needs both.
Summary
Orchestrate Mode gives one capable model the planning job and configured Cheap-model subagents the implementation work. The orchestrator explores the project, creates focused tasks, reviews builder results, and keeps the thread’s progress visible. Builders receive scoped context and the full Build tool set, while the planner remains read-only.
Configure a Cheap alias under Project Settings → Advanced → Model Aliases, add a Smart alias when you want a dedicated planning model, then start Orchestrate with a concrete multi-file request. Review the resulting changes and checks before you ship them.