Task Machine vs win.sh
How Task Machine compares to win.sh: shared Tasks and explicit workflows versus one company operator and adaptive loops.
Visit win.sh Switching from win.sh? Read the migration guideTask Machine and win.sh, 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 | win.sh |
|---|---|---|
| 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. |
win.sh
Yes
win.sh monitors business metrics, takes a goal and creates a plan with projects, deadlines and priorities. Its company operator routes the work under your authority rules. |
| 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. |
win.sh
Yes
The company operator reviews metrics, routes work and creates projects from goals. Its pages do not describe distinct goal, project and team leads with their own coordination responsibilities. |
| 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. |
win.sh
Partly
win.sh lists task delegation, and the local harness records briefs, approvals and outcomes. Its public pages do not describe a shared task record with named human or agent ownership and complete history. |
| 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. |
win.sh
Yes
Schedules, events and signals can start a run, and local loops choose their next useful run time. The documentation does not describe a stable root task with a separate task for every occurrence. |
| 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. |
win.sh
Yes
Editable loop contracts specify triggers, authority and verification, and the bug-fix loop defines ordered executor steps, conditions and follow-up. The documentation does not describe independent verifiers for individual steps. |
| 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. |
win.sh
Yes
An authority matrix sets what each type of work can do alone or send for approval, and the company operator follows those rules. Current pages do not establish separate action settings for each agent. |
| 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. |
win.sh
Partly
Approvals, edits and rejections become operating rules, and Bug Autofix can propose more authority after at least 10 successful fixes and other checks. The documented upgrade proposal is not tied to 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. |
win.sh
Yes
win.sh saves decisions, rules and learnings as editable company knowledge, and local loops keep journals. Its pages do not document restoring notes or separate agent, project, goal, team and workspace memory scopes. |
| 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. |
win.sh
Yes
Conversational onboarding analyzes a website and creates a 30-day plan, and a goal becomes projects. The pages do not describe reviewing acceptance criteria before each agent task starts. |
| 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. |
win.sh
Partly
win.sh describes support issue triage, and its hosted API documents snapshot reads. The API says hosted write endpoints are not public yet, and the cited pages do not establish routing incoming requests to an owner or agent. |
| 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. |
win.sh
Partly
The catalog marks Stripe, Plausible and Google Search Console live, but marks GitHub, custom API and custom MCP soon. Other win.sh pages say GitHub is available and enterprise customers can add custom integrations, so availability is unclear. |
| 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. |
win.sh
Partly
The public model router recommends a model and fallback using task, quality, speed and price. Its documentation does not establish that hosted workflows automatically choose a model at each 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. |
win.sh
Yes
win.sh offers hosted managed execution or an open-source local harness that runs Codex or Claude Code in your own repository. |
| 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. |
win.sh
Yes
win.sh's local harness lets you run loops with your own agent subscription using Codex or Claude Code. |
| 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. |
win.sh
Yes
Self-serve monthly budgets range from $50 to $10,000, with a hard limit, optional top-ups and a seven-day money-back guarantee. |
| 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. |
win.sh
Yes
Bug Autofix asks for regression tests and checks the error rate against defined success and failure criteria after deployment. It does not document independent pass, fail or uncertain checks for every task requirement. |
For software work
| What you compare | Task Machine | win.sh |
|---|---|---|
| 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. |
win.sh
Not published
Bug Autofix directs the agent to add a regression test and run checks. The public pages do not describe reviewing changes against discovered repository rules or screening proposed rules against examples. |
| 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. |
win.sh
Not published
Bug Autofix asks for risk notes and tests. The public docs describe no independent two-reviewer adversarial review for high-risk 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. |
win.sh
Partly
The bug-fix executor reports remaining risk and test output with a pull request or patch. It does not document a merge-risk rating for the exact revision. |
| 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. |
win.sh
Partly
Bug Autofix instructs its local executor to open a pull request or provide a patch, and requires approval before merge. Its public contract does not describe exact-commit approval or addressing review feedback. |
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. win.sh is named only to identify it, and there is no relationship between the two companies. Has something changed? Tell us.
Who each one suits
win.sh suits you if you want one company operator to monitor business signals, turn goals into projects and send a daily brief. Its local harness also lets you run editable business loops with Codex or Claude Code in your own repository.
Task Machine suits you if you want people and agents to share Tasks, develop work in Chat and review decisions in the Inbox. You can also define workflows with explicit steps and review boundaries.
You may stay with win.sh if its company memory, adaptive loops and budget controls fit your work. Its integration catalog marks Stripe, Plausible and Google Search Console live. It marks GitHub as coming soon, although the GitHub page says it is available now.
How work moves
win.sh takes a goal, reviews metrics and creates projects with deadlines and priorities. One operator routes the work under authority rules you configure and asks before significant actions. Its loop contracts can select the next useful run time instead of following a fixed interval. The Bug Autofix loop can hand a scoped fix to a coding agent, ask for regression tests and check the error rate after deployment.
Task Machine lets you discuss an outcome in Chat and create Tasks or Library documents from the plan. A Workflow can put a human approval before publication, route through a branch and use a separate verifier to check an agent's output. The Task keeps the run history and later questions together.
Both products describe approval controls and memory. win.sh says approvals, edits and rejections become operating rules, and its bug-fix loop can propose more authority after specified checks. Task Machine keeps memories at several scopes, and proposes changes to an agent's autonomy for you to accept or reject.
What the prices cover
win.sh offers a monthly budget from $50 to $10,000, a hard limit and optional one-time top-ups. Task Machine starts at $29 per month before tax, with the payment shared as usage across people and agents. You keep 100% of your revenue. Task Machine takes no cut and never takes custody of your accounts.
Common questions
Can both products handle recurring work?
Yes. win.sh describes adaptive loops and scheduled company checks. Task Machine can schedule Tasks and Workflows or start Workflows from service events.
Can both products work on code?
Yes. win.sh's local Bug Autofix loop instructs a coding agent to add a regression test and open a pull request or provide a patch. Task Machine agents can work on pull requests and address review feedback.
Can both products ask before risky actions?
Yes. win.sh describes authority rules and approval requests. Task Machine offers per-agent action controls and human approval steps in workflows.