Task Machine vs Orchestrator
Orchestrator coordinates coding agents through worktrees, pull requests and reviews. Task Machine organizes work around Tasks, Goals, Workflows and an Inbox for decisions.
Visit Orchestrator Switching from Orchestrator? Read the migration guideTask Machine and Orchestrator, point by point
Built from each company's public pages. Every answer links to its source and shows when we last checked it. The oldest check on this page was November 13, 2026.
| What you compare | Task Machine | Orchestrator |
|---|---|---|
| Goals |
Task Machine
Yes
Give a Goal an agent lead and link Metrics, such as weekly signups or open pipeline value. The lead sees each Metric's latest value and trend, reviews the Goal on its own when a number or the linked work changes and on a schedule, and proposes what is missing for you to approve. |
Orchestrator
Partly
A project's main agent plans the requested outcome and delegates work to workers. Its docs do not describe measurable goal targets that an owner tracks and reviews. |
| Leads |
Task Machine
Yes
Goals, Projects and Teams each have a lead, a person or an agent. A Goal lead checks that the work can still reach the outcome. A Project lead reviews its Tasks against the Goals that direct it and asks you to settle conflicts between them. A Team lead triages the queue. Every gap becomes a proposal you approve. |
Orchestrator
Yes
An orchestrator supervises a project, monitors sessions and delegates implementation to workers. Workers report progress, blockers and completed work to that orchestrator. |
| Tasks |
Task Machine
Yes
Every job is a Task that a person or an agent owns. The Task keeps its plan, discussion, decisions, runs and history together, so you can steer one job in detail without reading a chat log, and people and agents hand work to each other on the same record. |
Orchestrator
Partly
Each coding task gets an agent, branch and worktree, with conversation history and pull-request feedback. Its docs do not describe people owning tasks on the same records as agents. |
| Recurring work |
Task Machine
Yes
Start a Task or Workflow once, on a schedule in your timezone, or when a service event arrives, such as a paid invoice or a pull request review. A recurring job keeps one stable root Task and gives each occurrence its own status and history, so repeated work does not flood your board. |
Orchestrator
Yes
Automations run prompts on cron or calendar schedules with run history. Outside events, including failing checks and review comments, send work back to the owning session, and matching tracker issues can start workers. |
| Workflows |
Task Machine
Yes
A Workflow repeats your steps in the same order every time, with branches, human questions and approvals, and verifier checks that judge each result against its requirements and send weak work back with feedback. Every run keeps a step-by-step history you can read afterwards. |
Orchestrator
Partly
Workspace setup scripts run ordered steps, and Automations repeat saved prompts. Its docs do not describe a configurable multi-step agent process with branches or conditions. |
| Autonomy |
Task Machine
Yes
Consequential decisions land in your Inbox with their context. You set what each agent may do on its own: every action is either Ask first or Automatic, per agent, and you can change that whenever the work or the stakes change. |
Orchestrator
Yes
You choose provider-supported permission modes for workers and orchestrators. Chat displays approval requests, blocked sessions pause automated input, and the notification center collects requests for human attention. |
| Learned autonomy |
Task Machine
Yes
Task Machine studies the approvals and corrections you already make. When an agent does well it proposes giving it more freedom, and when it needs closer supervision it proposes tighter review, each with the evidence. A short lucky streak is not enough, and nothing changes until you accept. |
Orchestrator
Not published
Its docs describe chosen permission modes and saved project defaults, but no product-proposed changes to agent permissions based on approval history. |
| Memory |
Task Machine
Yes
Agents keep lessons from your corrections, such as an accepted example or a mistake to avoid, and carry the relevant notes into later work. Memory is kept per agent, project, goal, team and workspace, and you can read, correct and restore any note. |
Orchestrator
Not published
Its docs describe saved conversations and standing project instructions, but no inspectable, editable agent memory that learns from work and improves later runs. |
| Planning |
Task Machine
Yes
Plan in Chat with your agents, and the plan becomes Tasks or Library documents instead of staying in a chat log. Before an agent starts, you review its plan and the acceptance criteria its work will be judged against. |
Orchestrator
Yes
The project's main agent plans work and starts workers for its pieces. Chat shows plans, and you can approve a plan from the companion phone app. |
| Intake |
Task Machine
Yes
Send work in over HTTP with a project token. It lands in the project as a Task, or in your Inbox as a proposal first. A team lead agent triages it to the right owner and asks you only when the decision is yours. |
Orchestrator
Yes
Opt-in GitHub or GitLab issue intake filters by assignee and starts worker sessions for matching issues. Intake reads the tracker without posting comments or changing issues. |
| Connectors |
Task Machine
Yes
Install services from a catalog as MCP servers, APIs or command-line tools, or add your own custom Connector for any of the three. Events Connectors receive webhooks from a service, such as a paid invoice, and start Workflows or wake a waiting Task. |
Orchestrator
Partly
Chat exposes provider-supported Model Context Protocol tools, and built-in GitHub/GitLab integrations react to checks and reviews. Its docs do not describe custom API connectors alongside configurable event triggers. |
| Models |
Task Machine
Yes
Auto is the default. For each stage of the work it chooses a model from the task, current model capabilities, pricing and your applicable budgets, and you can fix a specific model on an agent when you want to. |
Orchestrator
Partly
You pick the coding agent and model per task, with separate defaults for project roles. Its docs do not describe automatic model selection for each task or step. |
| Cloud or your own computer |
Task Machine
Yes
Run agents in Managed Cloud with nothing to install, or connect a Local Worker, a computer you control, for local files, tools and accounts. You choose where each agent runs. |
Orchestrator
Yes
Agents can run on your computer or in hosted Cloud sandboxes. The Cloud guide says availability depends on the desktop build and account access, while local projects work without Cloud. |
| Your own subscription |
Task Machine
Yes
Sign in to your ChatGPT (Codex), Claude or GitHub Copilot subscription on a Local Worker, and the agents there use it instead of Task Machine's models. |
Orchestrator
Yes
Local projects reuse installed coding agents' existing API keys or provider subscriptions. Orchestrator does not proxy their API calls, and the provider bills that model usage. |
| Pricing |
Task Machine
Yes
Usage based. From $29 a month before tax, the whole payment becomes usage that your workspace shares across people and agents, with no base fee and no trial. Larger monthly amounts lower the AI and Cloud rates. |
Orchestrator
Partly
Local use is free. Cloud Starter is $20/month for 15 concurrent agents and 5 projects, and Pro is $40/month for 50 agents and 20 projects. These are capacity-limited plans, not published usage credits. Local model usage is billed separately by providers. |
| Correctness |
Task Machine
Yes
Every Task carries acceptance requirements, and each one gets a Pass, Fail or Uncertain check against the delivered work before a person reviews it. Workflow steps can add a verifier check that sends failed work back with feedback. You review the plan first, so the criteria exist before work starts. |
Orchestrator
Yes
Orchestrator observes CI checks, returns failing check names and links to the owning worker, and can run a separate reviewer against the pull request. Approval and passing checks contribute to merge readiness. |
For software work
| What you compare | Task Machine | Orchestrator |
|---|---|---|
| Code review rules |
Task Machine
Yes
Internal code review checks completed changes against the enabled rules of your repository. Rule discovery reads the repository and proposes rules, each screened against violating and valid examples first, and Task Machine suggests turning off a rule that agents keep dismissing. |
Orchestrator
Partly
Project rules provide standing worker instructions, and separate reviewer agents check pull requests. Its docs do not establish that reviewers check code against those configured rules. |
| Adversarial review |
Task Machine
Yes
When an approved plan has high sensitivity or a Critical review level, the change also gets an adversarial review. Two independent reviewers examine the changed files together for defects such as a broken caller or a duplicate charge on retry. Findings keep their reproduction steps, and a skipped or failed review never counts as a pass. |
Orchestrator
Partly
A reviewer runs separately from the worker and does not own its branch. Its docs do not describe an additional adversarial review specifically for risky changes. |
| Risk rating |
Task Machine
Yes
Before final review, Merge risk rates the exact revision Low, Moderate or High, with notes on alignment, impact, verification, rollback cost and error detection, plus file references. It informs your decision and never merges for you. |
Orchestrator
Partly
The pull-request inspector shows checks, unresolved reviews, mergeability and reasons a change is not ready. Its docs do not describe a risk rating of the change before merge. |
| Pull requests |
Task Machine
Yes
Agents deliver against the exact reported revision, address review feedback and update the branch under your repository rules. Task Machine records its own approval of the exact commit before an agent may merge. |
Orchestrator
Yes
Workers own linked pull requests and receive unresolved review comments, failing checks and merge conflicts. Reviewer findings can return to the same worker for fixes, with feedback deduplicated between polls. |
A fact we cannot find or cannot check is left out, and prices can change after the date shown. Task Machine publishes this comparison and is an interested party. Orchestrator is named only to identify it, and there is no relationship between the two companies. Has something changed? Tell us.
Who each one suits
Orchestrator suits you if you want a project's main coding agent to divide work among workers, keep their branches separate and route pull-request feedback to the worker responsible. You can use your existing coding-agent subscriptions locally.
Task Machine suits you if you want people and agents to own Tasks, pursue Goals with linked Metrics and bring decisions into an Inbox. You review the plan and acceptance criteria before execution.
You may stay with Orchestrator if your work centers on repositories and its free local app already gives you the supervision you need. Separate reviewer agents, CI feedback and a companion phone app let you follow and steer those sessions.
How work reaches a reviewer
Orchestrator organizes coding work into project sessions. An orchestrator supervises the project and delegates implementation to workers, each with an isolated worktree. Its board reflects agent activity, checks and review feedback. Unresolved comments return to the worker that owns the pull request, and you can run a separate reviewer before merging.
Task Machine keeps a job's plan, discussion, decisions and run history in a Task that a person or an agent owns. A Goal adds an outcome with linked Metrics and a lead that reviews progress and proposes missing work for approval.
What repeats and where it runs
Orchestrator Automations run saved prompts on schedules and keep run history. Built-in event rules send failing checks, review comments and merge conflicts to sessions. Local scheduled work requires the computer to stay awake and Orchestrator to remain running.
Task Machine Workflows define repeated steps with branches, questions and approvals. A verifier can check a step against requirements and send failed work back for revision. Agents can run in Managed Cloud or on a Local Worker that you control.
Orchestrator also offers hosted Cloud sandboxes. Its website advertises Cloud plans, while its Cloud guide says access depends on the build and account. Check that access before relying on hosted execution.
What the prices cover
Orchestrator's local app is free. Its website lists Cloud Starter at $20 a month for 15 concurrent agents and 5 cloud projects, and Pro at $40 a month for 50 concurrent agents and 20 cloud projects. Local agents use their existing provider accounts, and providers bill that usage separately. The Cloud guide does not publish account entitlements or model-credit allowances, so confirm what your Cloud account includes.
Task Machine is usage based, from $29 a month before tax, with the whole payment available as shared workspace usage and no base fee. You keep 100% of your revenue, Task Machine takes no cut and never takes custody of your accounts.
Common questions
Is this the former Agent Orchestrator?
Yes. Orchestrator.inc is the new name for Agent Orchestrator. Its website identifies the same open-source app and ao command-line tool.
Can Orchestrator address pull-request review feedback?
Yes. It sends unresolved comments to the owning worker and can send findings from a separate reviewer back to that worker. It also routes failing checks and merge conflicts.
Can both run work locally and in the cloud?
Yes. Orchestrator offers local execution and hosted sandboxes, subject to Cloud access. Task Machine offers Managed Cloud and Local Workers.
Does Orchestrator choose the model automatically?
Its docs describe choosing an agent and model per task and configuring project-role defaults. Task Machine defaults to Auto, which selects a model for each stage of work.