# Portia: prove the feature first, then let the agents build it

> Portia turns an epic into failing acceptance tests you sign off, runs Claude Code workers in parallel until every one passes on the rebased head, and hands you one pull request with the evidence for each scenario. It never merges to main.

Source: https://www.portia.run/

## Portia, row by row

| | Portia |
|---|---|
| Who proves the work is right, and when | The tests, written first and signed off by a person before any wave; then the gate on each child's rebased head; then you, at the one PR. |
| Where rework shows up | At the gate, per child, before it lands: a failed exit gate retries with the failure in its brief. Siblings never touch the same file, so there is nothing to reconcile at the end. |
| Unit of work | An epic, or a story big enough to split into children. |
| What you get back | One reviewed pull request for the whole feature, with a ledger of every child and the evidence for each scenario in its description. |
| Where the agents run | Your machine, or a build box you open over SSH. One git worktree per child. |
| Which agents | Claude Code, on your own subscription. Workers follow the target repo's CLAUDE.md, skills and settings. |
| Planning | A wave table drawn from the tickets and shown to you first. Written back into the tickets, with each dependency as a blocker link. |
| Tests before features | The spine writes every acceptance scenario as a failing spec. You sign off before any wave starts. |
| Isolation between tasks | A worktree, branch, port and database per child. No two children in a wave touch the same file. |
| Gates before landing | Task gate; exit gate, run again on the rebased head; CI; an optional review of each child; the epic gate. |
| Who merges | You. Children squash-merge into an integration branch, pinned to the commit their gate passed. Portia never merges to main. |
| Tracker | Jira or GitHub Issues. |
| Model choice | Per child, from its tier: a cheaper model for routine children, a stronger one for the hard ones. |
| Spend and capacity | Caps per worker, per wave and per epic. Waves are sized from free memory and the other runs on the machine. |
| Unattended, and resuming | Parks with one question instead of guessing. Detached workers outlive the session, with a stall detector; portia resume picks a run back up. |
| Licence and price | Free. Source on GitHub. |

## Questions

### What is Portia?

Portia turns an epic into failing acceptance tests you sign off, runs Claude Code workers in parallel until every one passes on the rebased head, and hands you one pull request with the evidence for each scenario. It never merges to main. It is a Claude Code skill plus a small CLI, and works with Jira or GitHub Issues.

### Who decides the waves?

The skill drafts the plan. portia check rejects one where two children in a wave touch the same file, or where the spine does not own the acceptance specs. You approve the wave table before anything is written to the tracker.

### What does a run cost?

Tokens, capped per worker, per wave and per epic in the profile. Dispatch refuses past any cap and the run stops to ask you. The run log records every attempt's tokens.

### Where does it run?

On your machine, or better, a machine of its own that you open over SSH and watch with portia view.

### Why not Claude Code's own subagents?

Subagents run tasks. Portia adds what goes around them: the spine and its failing specs first, a worktree, port and database per worker, the gate on the rebased head, and one PR.

## Install

1. **Install Portia.** Install, or update, with: gh api repos/mousedown/portia/contents/scripts/install.sh -H "Accept: application/vnd.github.raw" | bash. You need Bun, git, the GitHub CLI logged in, and Claude Code.
2. **Set up a repository.** Run portia init (or /portia-setup inside Claude Code). It detects the tracker, the checks and the machine, then asks.
3. **Run an epic.** From the root of the repository, in Claude Code, run /portia PROJ-123 for a Jira epic or story, or /portia GH-42 for a GitHub issue. portia resume PROJ-123 picks up a run that was interrupted.

Every profile field, the gates, the CLI and the safety rules: https://github.com/mousedown/portia/blob/main/docs/reference.md

## Portia vs Claude Code on its own

https://www.portia.run/compare/claude-code · the agent Portia drives · facts last checked October 2026

Claude Code already has worktrees and subagents. Portia adds the plan, the tests-first spine, the gates and the single PR for an epic.

Portia is a Claude Code skill. Everything it does, it does by running Claude Code: the same CLAUDE.md files, the same skills, the same subscription. So the honest first comparison is with Claude Code used by hand.

Claude Code can start a session in its own worktree with --worktree, and a subagent can be given its own checkout. What it does not have is anything that spans tickets: no plan written into the tracker, no shared code landed before the rest, no acceptance specs written first and signed off, no exit gate re-run on a rebased head, and no integration branch that collects several children into one PR.

For one change, that is the right amount of machinery. Portia declines a parent that one worker could finish, because the spine, waves and integration branch only cost time there.

| | Portia | Claude Code on its own |
|---|---|---|
| Who proves the work is right, and when | The tests, written first and signed off by a person before any wave; then the gate on each child's rebased head; then you, at the one PR. | You, reading the diff after the session; tests if you asked for them. |
| Where rework shows up | At the gate, per child, before it lands: a failed exit gate retries with the failure in its brief. Siblings never touch the same file, so there is nothing to reconcile at the end. | In review, after the fact; between branches you ran in parallel, when they meet. |
| Unit of work | An epic, or a story big enough to split into children. | A prompt, or a ticket you paste in. --worktree starts a session on its own branch. |
| What you get back | One reviewed pull request for the whole feature, with a ledger of every child and the evidence for each scenario in its description. | Commits on a branch. You open the PR. |
| Where the agents run | Your machine, or a build box you open over SSH. One git worktree per child. | Your machine, or Claude Code on the web. |
| Which agents | Claude Code, on your own subscription. Workers follow the target repo's CLAUDE.md, skills and settings. | Claude Code. |
| Planning | A wave table drawn from the tickets and shown to you first. Written back into the tickets, with each dependency as a blocker link. | Plan mode for one task. Nothing spans tickets or writes a plan back to a tracker. |
| Tests before features | The spine writes every acceptance scenario as a failing spec. You sign off before any wave starts. | If you ask for them. |
| Isolation between tasks | A worktree, branch, port and database per child. No two children in a wave touch the same file. | A worktree per --worktree session. Ports and databases are yours to arrange. |
| Gates before landing | Task gate; exit gate, run again on the rebased head; CI; an optional review of each child; the epic gate. | Hooks you write. Nothing re-runs checks on a rebased head before a merge. |
| Who merges | You. Children squash-merge into an integration branch, pinned to the commit their gate passed. Portia never merges to main. | You, branch by branch. |
| Tracker | Jira or GitHub Issues. | Through MCP servers or the gh CLI, when you ask. |
| Model choice | Per child, from its tier: a cheaper model for routine children, a stronger one for the hard ones. | One model per session, switchable. |
| Spend and capacity | Caps per worker, per wave and per epic. Waves are sized from free memory and the other runs on the machine. | Your plan's limits. |
| Unattended, and resuming | Parks with one question instead of guessing. Detached workers outlive the session, with a stall detector; portia resume picks a run back up. | A session ends when you close it, unless you run it headless yourself. |
| Licence and price | Free. Source on GitHub. | Included in Claude subscriptions and API use. |

### What Claude Code on its own does that Portia doesn't

- Nothing to install or learn beyond Claude Code itself.
- Right for a single change, which Portia will decline.
- Interactive: you steer every step as it happens.

**Choose Claude Code on its own when** The work is one ticket, or you want to steer every step.

**Choose Portia when** The work is an epic with shared code and several children, and you want it planned, tested and gated to one PR without sitting in each session.

### Does Portia replace Claude Code?

No. It runs Claude Code. Portia is the orchestration around it: the plan, the spine, the waves, the gates and the landing.

### Can I use Portia with Codex or Gemini CLI?

Not today. Workers are Claude Code sessions, and the skill that plans and lands runs inside Claude Code too.

Sources:
- [Claude Code documentation](https://docs.claude.com/claude-code)

## Portia vs Conductor

https://www.portia.run/compare/conductor · Mac app, one workspace per task · facts last checked October 2026

Conductor gives each task a workspace with its own worktree, terminal, diff and PR, and lets you run Claude Code, Codex, Cursor and OpenCode side by side. You plan, review and merge each one.

Conductor is a Mac app for running several coding agents at once. Each task gets a workspace: a git worktree and branch, with the agent's chat, a terminal, the diff, checks and a pull-request step attached. Conductor Cloud, on its paid plans, runs workspaces in microVMs so they can carry on after you close the laptop. There is an iOS app for those.

The unit is the task, and the person is the orchestrator: you decide what to start, you review each workspace, you merge each branch. Conductor's own guides suggest giving every session a narrow prompt with the expected outcome, constraints and a validation command.

Portia starts one level up. It takes the epic, decides the order from the tickets' dependencies, lands the shared code first, writes the acceptance specs before any feature work, and gates every child onto one integration branch. You review one PR at the end, and the parked questions along the way.

| | Portia | Conductor |
|---|---|---|
| Who proves the work is right, and when | The tests, written first and signed off by a person before any wave; then the gate on each child's rebased head; then you, at the one PR. | You, per workspace, in its diff view after the agent is done. |
| Where rework shows up | At the gate, per child, before it lands: a failed exit gate retries with the failure in its brief. Siblings never touch the same file, so there is nothing to reconcile at the end. | In your review of each workspace, and when two workspaces' branches meet on main. |
| Unit of work | An epic, or a story big enough to split into children. | A task you type. One workspace per task. |
| What you get back | One reviewed pull request for the whole feature, with a ledger of every child and the evidence for each scenario in its description. | A branch, diff and PR per workspace, reviewed one workspace at a time. |
| Where the agents run | Your machine, or a build box you open over SSH. One git worktree per child. | Your Mac, or Conductor Cloud microVMs on paid plans. |
| Which agents | Claude Code, on your own subscription. Workers follow the target repo's CLAUDE.md, skills and settings. | Claude Code, Codex, Cursor and OpenCode, bundled. |
| Planning | A wave table drawn from the tickets and shown to you first. Written back into the tickets, with each dependency as a blocker link. | Yours: what to start, and in what order. |
| Tests before features | The spine writes every acceptance scenario as a failing spec. You sign off before any wave starts. | If you ask for them. |
| Isolation between tasks | A worktree, branch, port and database per child. No two children in a wave touch the same file. | A worktree and branch per workspace; CONDUCTOR_PORT gives each a port range. |
| Gates before landing | Task gate; exit gate, run again on the rebased head; CI; an optional review of each child; the epic gate. | Checks you configure per workspace. |
| Who merges | You. Children squash-merge into an integration branch, pinned to the commit their gate passed. Portia never merges to main. | You, per workspace. |
| Tracker | Jira or GitHub Issues. | None required. |
| Model choice | Per child, from its tier: a cheaper model for routine children, a stronger one for the hard ones. | Whatever the agent you pick supports. |
| Spend and capacity | Caps per worker, per wave and per epic. Waves are sized from free memory and the other runs on the machine. | Your agent subscriptions. Conductor does not resell model usage. |
| Unattended, and resuming | Parks with one question instead of guessing. Detached workers outlive the session, with a stall detector; portia resume picks a run back up. | Cloud workspaces keep running; local ones need your Mac awake. |
| Licence and price | Free. Source on GitHub. | Proprietary Mac app. A free tier, then Pro and Teams plans. |

### What Conductor does that Portia doesn't

- A finished app: terminal, diff, checks and PR in one window.
- Four agents, not one.
- Cloud sandboxes, an iOS app and team features.

**Choose Conductor when** You want to run and watch several agents on separate tasks and review each by hand, on a Mac.

**Choose Portia when** The tasks belong to one feature. Portia plans the order, lands the shared code first, writes the acceptance tests, and gates every child onto one branch.

### Could I run Portia's workers inside Conductor?

Not usefully. Portia creates and tears down its own worktrees, ports and databases per child, and lands each one itself. Conductor expects to own the workspace.

### Is Conductor local-only?

No. Its docs describe both local Mac workspaces and cloud sandboxes on paid plans.

Sources:
- [Conductor](https://www.conductor.build/)
- [Conductor docs: parallel agents](https://docs.conductor.build/core/parallel-agents)
- [Conductor docs: run multiple Claude Code sessions](https://www.conductor.build/docs/guides/parallel-agents/run-multiple-claude-code-sessions)

## Portia vs Superset

https://www.portia.run/compare/superset · desktop workspace for any CLI agent · facts last checked October 2026

Superset runs any CLI agent in parallel worktrees on machines you own, with diff review, PRs, a browser and remote access. It is a desk to run agents from; the plan and the merge are yours.

Superset is a source-available desktop app (Elastic License 2.0) for running many coding agents at once, each in its own git worktree, on your Mac, on hosts you add, or in cloud workspaces. It has presets for more than twenty CLI agents, a diff reviewer, pull requests, a built-in browser, automations and an iOS app for answering an agent while it runs on your own machine.

Like Conductor, it is organised around the task and the person. Superset decides nothing about order or dependencies, runs no gates of its own, and merges nothing: it is where you watch and review.

Portia is the opposite shape: no desktop app, one agent family, and the orchestration is the product. The plan comes from the tracker, the spine lands first, every child is gated on its rebased head, and the result is one PR.

| | Portia | Superset |
|---|---|---|
| Who proves the work is right, and when | The tests, written first and signed off by a person before any wave; then the gate on each child's rebased head; then you, at the one PR. | You, per workspace, in the diff reviewer after the agent is done. |
| Where rework shows up | At the gate, per child, before it lands: a failed exit gate retries with the failure in its brief. Siblings never touch the same file, so there is nothing to reconcile at the end. | In your review of each workspace, and at merge time between workspaces. |
| Unit of work | An epic, or a story big enough to split into children. | A task per workspace. |
| What you get back | One reviewed pull request for the whole feature, with a ledger of every child and the evidence for each scenario in its description. | A branch and PR per workspace, reviewed in the app. |
| Where the agents run | Your machine, or a build box you open over SSH. One git worktree per child. | Your Mac (Linux experimental), hosts you add, or cloud workspaces. |
| Which agents | Claude Code, on your own subscription. Workers follow the target repo's CLAUDE.md, skills and settings. | Any CLI agent; presets for more than twenty. |
| Planning | A wave table drawn from the tickets and shown to you first. Written back into the tickets, with each dependency as a blocker link. | Yours. |
| Tests before features | The spine writes every acceptance scenario as a failing spec. You sign off before any wave starts. | If you ask for them. |
| Isolation between tasks | A worktree, branch, port and database per child. No two children in a wave touch the same file. | A worktree per workspace. |
| Gates before landing | Task gate; exit gate, run again on the rebased head; CI; an optional review of each child; the epic gate. | None built in; your agent runs what you tell it to. |
| Who merges | You. Children squash-merge into an integration branch, pinned to the commit their gate passed. Portia never merges to main. | You. |
| Tracker | Jira or GitHub Issues. | None required. |
| Model choice | Per child, from its tier: a cheaper model for routine children, a stronger one for the hard ones. | Whatever each agent supports. |
| Spend and capacity | Caps per worker, per wave and per epic. Waves are sized from free memory and the other runs on the machine. | You pay each provider directly, with no markup. |
| Unattended, and resuming | Parks with one question instead of guessing. Detached workers outlive the session, with a stall detector; portia resume picks a run back up. | Remote access and an iOS app to a running host; automations. |
| Licence and price | Free. Source on GitHub. | Source-available (ELv2). A free tier; Pro at $20 per user per month. |

### What Superset does that Portia doesn't

- Agent-agnostic: Claude Code, Codex and anything else side by side.
- A browser, remote access, automations and a phone app.
- Source you can read.

**Choose Superset when** You run agents from several vendors and want one desktop to watch and review them.

**Choose Portia when** You want the orchestration itself to be the product: order, tests, gates and one PR, not a desk to run agents from.

### Does Superset run tests before merging?

Not on its own. The agent runs what you ask it to; the merge is yours. Portia's exit gate runs on every child's rebased head before it lands, and the epic gate runs every acceptance spec before the PR is marked ready.

Sources:
- [Superset vs Conductor (Superset's page)](https://superset.sh/compare/superset-vs-conductor)
- [Superset vs Claude Code (Superset's page)](https://superset.sh/compare/superset-vs-claude-code)

## Portia vs Claude Squad

https://www.portia.run/compare/claude-squad · terminal multiplexer for agent sessions · facts last checked October 2026

Claude Squad keeps several agent sessions apart with a tmux session and a worktree each, behind one TUI. It is the lightest tool in this list, and it does nothing else on purpose.

Claude Squad is an open-source TUI (AGPL-3.0). Each agent gets a tmux session and a git worktree; the interface lists them and switches between them. It works with Claude Code, Codex, Aider, OpenCode and Amp, on macOS and Linux.

That is the whole product, by design. Planning, testing, gating and merging are yours.

Portia also lives in the terminal and also uses a worktree per worker, but it is the orchestrator rather than the multiplexer: it decides what runs when, gates each child, and lands them. portia view is read-only; it shows the run rather than driving the sessions.

| | Portia | Claude Squad |
|---|---|---|
| Who proves the work is right, and when | The tests, written first and signed off by a person before any wave; then the gate on each child's rebased head; then you, at the one PR. | You, after each session, by reading the branch. |
| Where rework shows up | At the gate, per child, before it lands: a failed exit gate retries with the failure in its brief. Siblings never touch the same file, so there is nothing to reconcile at the end. | In review, and when parallel branches conflict at merge. |
| Unit of work | An epic, or a story big enough to split into children. | A session per task. |
| What you get back | One reviewed pull request for the whole feature, with a ledger of every child and the evidence for each scenario in its description. | A branch per session. You open the PRs. |
| Where the agents run | Your machine, or a build box you open over SSH. One git worktree per child. | Your machine, in tmux. |
| Which agents | Claude Code, on your own subscription. Workers follow the target repo's CLAUDE.md, skills and settings. | Claude Code, Codex, Aider, OpenCode, Amp. |
| Planning | A wave table drawn from the tickets and shown to you first. Written back into the tickets, with each dependency as a blocker link. | Yours. |
| Tests before features | The spine writes every acceptance scenario as a failing spec. You sign off before any wave starts. | If you ask for them. |
| Isolation between tasks | A worktree, branch, port and database per child. No two children in a wave touch the same file. | A tmux session and a worktree per agent. |
| Gates before landing | Task gate; exit gate, run again on the rebased head; CI; an optional review of each child; the epic gate. | None. |
| Who merges | You. Children squash-merge into an integration branch, pinned to the commit their gate passed. Portia never merges to main. | You. |
| Tracker | Jira or GitHub Issues. | None. |
| Model choice | Per child, from its tier: a cheaper model for routine children, a stronger one for the hard ones. | Per agent. |
| Spend and capacity | Caps per worker, per wave and per epic. Waves are sized from free memory and the other runs on the machine. | Your subscriptions. |
| Unattended, and resuming | Parks with one question instead of guessing. Detached workers outlive the session, with a stall detector; portia resume picks a run back up. | Sessions live as long as tmux does. |
| Licence and price | Free. Source on GitHub. | Open source, AGPL-3.0. Free. |

### What Claude Squad does that Portia doesn't

- Minimal: a TUI over tmux and worktrees, nothing to configure.
- Several agent families.
- Stays in the terminal.

**Choose Claude Squad when** You want a light way to keep several agent sessions apart in the terminal and do everything else yourself.

**Choose Portia when** You want the sessions planned, gated and landed for you, and the run visible in portia view.

### Is portia view the same kind of tool?

No. portia view is a read-only browser of runs: what is running, what waits on you, what landed, and each worker's transcript. It does not drive sessions; the orchestrator does.

Sources:
- [Best multi-agent coding tools (agentsroom.dev)](https://agentsroom.dev/blog/best-multi-agent-coding-tools)
- [Superset vs Claude Squad (Superset's page)](https://superset.sh/compare/superset-vs-claude-squad)

## Portia vs Vibe Kanban

https://www.portia.run/compare/vibe-kanban · kanban board for coding agents · facts last checked October 2026

Vibe Kanban is an open-source board where each card runs an agent in its own worktree and merges back with one click. The company behind it closed in April 2026; the project continues in the community.

Vibe Kanban starts with npx vibe-kanban and gives you a board. Each card is a task; an agent runs it in its own worktree, and when it is done you merge it back (rebase onto main, merge, clean up) or open a PR. It supports Claude Code, Codex, Copilot, Gemini CLI, Amp, Cursor's agent, OpenCode and others, and has an MCP server so other tools can create cards.

The pitch is that planning and review by people is now the bottleneck, and a board with many cards in flight removes the dead time of waiting on one agent.

That is a good fit for a backlog of unrelated tasks. Portia is for the other case, one feature whose tickets depend on each other: it keeps them on an integration branch, orders them by dependency, writes the acceptance specs first, and leaves the merge to main to a person.

| | Portia | Vibe Kanban |
|---|---|---|
| Who proves the work is right, and when | The tests, written first and signed off by a person before any wave; then the gate on each child's rebased head; then you, at the one PR. | You, per card, before its one-click merge. |
| Where rework shows up | At the gate, per child, before it lands: a failed exit gate retries with the failure in its brief. Siblings never touch the same file, so there is nothing to reconcile at the end. | At each card's merge: it rebases onto main, so conflicts and breakage surface then, after the work. |
| Unit of work | An epic, or a story big enough to split into children. | A card. One task per card, one worktree per task. |
| What you get back | One reviewed pull request for the whole feature, with a ledger of every child and the evidence for each scenario in its description. | A one-click merge (rebase onto main, merge, clean up) or a PR per card. |
| Where the agents run | Your machine, or a build box you open over SSH. One git worktree per child. | Your machine, from npx vibe-kanban. |
| Which agents | Claude Code, on your own subscription. Workers follow the target repo's CLAUDE.md, skills and settings. | Claude Code, Codex, Copilot, Gemini CLI, Amp, Cursor Agent, OpenCode and more. |
| Planning | A wave table drawn from the tickets and shown to you first. Written back into the tickets, with each dependency as a blocker link. | A board you fill. |
| Tests before features | The spine writes every acceptance scenario as a failing spec. You sign off before any wave starts. | If you ask for them. |
| Isolation between tasks | A worktree, branch, port and database per child. No two children in a wave touch the same file. | A worktree per card. |
| Gates before landing | Task gate; exit gate, run again on the rebased head; CI; an optional review of each child; the epic gate. | None built in. |
| Who merges | You. Children squash-merge into an integration branch, pinned to the commit their gate passed. Portia never merges to main. | You, per card; its merge rebases onto main. |
| Tracker | Jira or GitHub Issues. | Its own board, plus an MCP server for other clients. |
| Model choice | Per child, from its tier: a cheaper model for routine children, a stronger one for the hard ones. | Per agent. |
| Spend and capacity | Caps per worker, per wave and per epic. Waves are sized from free memory and the other runs on the machine. | Your subscriptions. |
| Unattended, and resuming | Parks with one question instead of guessing. Detached workers outlive the session, with a stall detector; portia resume picks a run back up. | Remote access, per its blog. |
| Licence and price | Free. Source on GitHub. | Open source, Apache-2.0. The company closed in April 2026; community-maintained since. |

### What Vibe Kanban does that Portia doesn't

- A board is a familiar way to see many small tasks at once.
- Many agent families.
- Nothing to install: npx.

**Choose Vibe Kanban when** You have a backlog of unrelated small tasks and want to hand them out and merge them one by one.

**Choose Portia when** The tasks make one feature. Portia keeps them on one integration branch, orders them by dependency, and never merges to main itself.

### Is Vibe Kanban still maintained?

Its blog says the company shut down and the project continues as open source, community-maintained. Check the repository for current activity before relying on it.

Sources:
- [Vibe Kanban](https://www.vibekanban.com/)
- [Goodbye bloop (Vibe Kanban blog)](https://www.vibekanban.com/blog/shutdown)

## Portia vs Bernstein

https://www.portia.run/compare/bernstein · deterministic orchestrator · facts last checked October 2026

Bernstein is the closest in spirit: a goal decomposed into tasks, a worktree each, lint, type and test gates, and a merge queue. It merges to main itself; Portia leaves that to you, and keeps the plan in your tracker.

Bernstein is an open-source orchestrator (Apache-2.0, Python) for Claude Code, Codex and Gemini CLI. One LLM call decomposes a goal into tasks; after that the scheduler is plain Python with no model in the loop. Each task runs in its own worktree, a Janitor runs lint, type checks and tests on the output, and a merge queue serialises landings into main. A failed task is retried or routed to a different model, and an audit log with HMAC-chained receipts records every run.

Of everything on this list it shares the most with Portia: worktrees, gates before landing, serialised merges, retries. The differences are about where the plan lives and who merges.

Portia's plan is written into the tickets in Jira or GitHub, shown to you before anything starts, and the acceptance specs are signed off before the waves. Children land on an integration branch, and the merge to main is a person's. Bernstein's goal lives in the tool and its merges go to main.

| | Portia | Bernstein |
|---|---|---|
| Who proves the work is right, and when | The tests, written first and signed off by a person before any wave; then the gate on each child's rebased head; then you, at the one PR. | The Janitor's lint, type and test gates on each task's output; then its merge queue. |
| Where rework shows up | At the gate, per child, before it lands: a failed exit gate retries with the failure in its brief. Siblings never touch the same file, so there is nothing to reconcile at the end. | At the gate, per task, before merge: a failed task retries or goes to another model. Close to Portia; the tests are not written first or signed off. |
| Unit of work | An epic, or a story big enough to split into children. | A goal, decomposed into tasks by one LLM call. |
| What you get back | One reviewed pull request for the whole feature, with a ledger of every child and the evidence for each scenario in its description. | Verified tasks merged into main through a merge queue. |
| Where the agents run | Your machine, or a build box you open over SSH. One git worktree per child. | Your machine. Python. |
| Which agents | Claude Code, on your own subscription. Workers follow the target repo's CLAUDE.md, skills and settings. | Claude Code, Codex, Gemini CLI. |
| Planning | A wave table drawn from the tickets and shown to you first. Written back into the tickets, with each dependency as a blocker link. | Decomposed by the model, then scheduled deterministically; no LLM in the coordination loop. |
| Tests before features | The spine writes every acceptance scenario as a failing spec. You sign off before any wave starts. | Lint, type and test gates on each task's output. |
| Isolation between tasks | A worktree, branch, port and database per child. No two children in a wave touch the same file. | A worktree per task. |
| Gates before landing | Task gate; exit gate, run again on the rebased head; CI; an optional review of each child; the epic gate. | Lint, type checks and tests before merge. |
| Who merges | You. Children squash-merge into an integration branch, pinned to the commit their gate passed. Portia never merges to main. | Bernstein, into main, through a serialised merge queue. |
| Tracker | Jira or GitHub Issues. | None; the goal is the input. |
| Model choice | Per child, from its tier: a cheaper model for routine children, a stronger one for the hard ones. | Routes a failed task to a different model. |
| Spend and capacity | Caps per worker, per wave and per epic. Waves are sized from free memory and the other runs on the machine. | An audit log of every run; HMAC-chained receipts with --audit. |
| Unattended, and resuming | Parks with one question instead of guessing. Detached workers outlive the session, with a stall detector; portia resume picks a run back up. | A replayable journal of each run. |
| Licence and price | Free. Source on GitHub. | Open source, Apache-2.0. Solo-maintained. |

### What Bernstein does that Portia doesn't

- Deterministic coordination you can replay end to end.
- Three agent families.
- Audit receipts you can verify offline.

**Choose Bernstein when** You want a goal turned into tasks and merged to main by a scheduler you can replay, with the plan living in the tool.

**Choose Portia when** You want the plan in your tracker, acceptance tests signed off before the waves, and a person merging to main.

### Does Portia use an LLM to coordinate?

The plan is drafted by Claude Code and approved by you; dispatch, gates, landing and decisions are the CLI's own code, with rules for retries, touches outside a child's paths and sensitive globs. Ambiguous decisions can be posted to an optional service; otherwise the safe default applies.

Sources:
- [Bernstein architecture](https://bernstein.readthedocs.io/en/latest/architecture/ARCHITECTURE/)
- [Bernstein on PyPI](https://pypi.org/project/bernstein/)

## Portia vs GitHub Copilot coding agent

https://www.portia.run/compare/github-copilot-coding-agent · hosted, one issue to one PR · facts last checked October 2026

Assign an issue to Copilot and it returns a PR from an Actions environment. GitHub's own guidance says it suits low-to-medium complexity tasks in well-tested codebases, one at a time.

Copilot coding agent takes one issue, assigned to Copilot like any other assignee, from github.com, GitHub Mobile, the CLI, Raycast, or Jira in public preview since March 2026. It plans, works in an ephemeral GitHub Actions environment, runs your tests and linters, opens a PR on a copilot/ branch and asks for your review.

Nothing to install and nothing to run: it lives where the code and CI already are. GitHub's own description of its sweet spot is low-to-medium complexity tasks in well-tested codebases.

Portia is for the feature, not the issue: several tickets with shared code, planned in dependency order, with the shared contracts landed first and the acceptance specs written before any child starts. It runs on your machine on your Claude subscription, and the children collect into one PR rather than one PR per issue.

| | Portia | GitHub Copilot coding agent |
|---|---|---|
| Who proves the work is right, and when | The tests, written first and signed off by a person before any wave; then the gate on each child's rebased head; then you, at the one PR. | Your tests and linters in Actions, after it writes; then you, in the PR. |
| Where rework shows up | At the gate, per child, before it lands: a failed exit gate retries with the failure in its brief. Siblings never touch the same file, so there is nothing to reconcile at the end. | In PR review, after the fact, one issue at a time; parallel issues meet on your default branch. |
| Unit of work | An epic, or a story big enough to split into children. | One issue, assigned to Copilot. |
| What you get back | One reviewed pull request for the whole feature, with a ledger of every child and the evidence for each scenario in its description. | A PR on a copilot/ branch that requests your review. |
| Where the agents run | Your machine, or a build box you open over SSH. One git worktree per child. | An ephemeral GitHub Actions environment. |
| Which agents | Claude Code, on your own subscription. Workers follow the target repo's CLAUDE.md, skills and settings. | Copilot. |
| Planning | A wave table drawn from the tickets and shown to you first. Written back into the tickets, with each dependency as a blocker link. | Its own, per issue. |
| Tests before features | The spine writes every acceptance scenario as a failing spec. You sign off before any wave starts. | Runs your tests and linters in Actions. |
| Isolation between tasks | A worktree, branch, port and database per child. No two children in a wave touch the same file. | A fresh environment per issue. |
| Gates before landing | Task gate; exit gate, run again on the rebased head; CI; an optional review of each child; the epic gate. | Your Actions workflows on the PR. |
| Who merges | You. Children squash-merge into an integration branch, pinned to the commit their gate passed. Portia never merges to main. | You. |
| Tracker | Jira or GitHub Issues. | GitHub Issues; Jira in public preview (March 2026); Raycast. |
| Model choice | Per child, from its tier: a cheaper model for routine children, a stronger one for the hard ones. | Copilot's. |
| Spend and capacity | Caps per worker, per wave and per epic. Waves are sized from free memory and the other runs on the machine. | Premium requests on Copilot plans, plus Actions minutes. |
| Unattended, and resuming | Parks with one question instead of guessing. Detached workers outlive the session, with a stall detector; portia resume picks a run back up. | Fully: it runs in GitHub's cloud. |
| Licence and price | Free. Source on GitHub. | A Copilot subscription (Pro+ or Enterprise at launch; check current plans). |

### What GitHub Copilot coding agent does that Portia doesn't

- Nothing to install: assign an issue and walk away.
- Lives where the code and CI already are.
- Any contributor with a seat can use it.

**Choose GitHub Copilot coding agent when** Low-to-medium complexity issues in a well-tested codebase, one at a time.

**Choose Portia when** An epic: shared code first, children in dependency order, one integration branch, one PR, on your own Claude subscription.

### Can Copilot take an epic?

It takes an issue. You could assign each child issue separately, but nothing orders them, lands shared code first, or collects them into one branch; each returns its own PR against your default branch.

Sources:
- [GitHub changelog: Copilot coding agent in public preview](https://github.blog/changelog/2025-05-19-github-copilot-coding-agent-in-public-preview/)
- [GitHub changelog: Copilot coding agent for Jira (public preview)](https://github.blog/changelog/2026-03-06-github-copilot-coding-agent-for-jira-is-now-in-public-preview/)

## Portia vs Devin

https://www.portia.run/compare/devin · hosted AI software engineer · facts last checked October 2026

Devin takes tickets from Linear, Jira, GitHub or Slack into a cloud sandbox and returns a PR. MultiDevin fans one task across up to ten workers. It is hosted end to end and billed in compute units.

Devin, from Cognition, is a hosted agent. Give it a ticket from Linear, Jira, GitHub or Slack and it spins up a sandboxed environment, reads the codebase, plans, runs tests and opens a PR for review. MultiDevin puts a manager Devin over up to ten workers and merges the successful ones into one branch or PR. There is a CLI and a desktop app, and plans run from free through Pro, Max, Teams and Enterprise, billed in Agent Compute Units.

It is a different kind of product: a vendor's agent on a vendor's machines, with enterprise administration and a usage guarantee. The comparison is still worth making because the question is the same, how does a ticket become a reviewed PR, and the answers differ at every row.

Portia runs Claude Code on hardware you control, plans from the tracker with your approval, writes the acceptance specs before any feature work, and gates every child on its rebased head before it lands on the integration branch. The merge to main is yours.

| | Portia | Devin |
|---|---|---|
| Who proves the work is right, and when | The tests, written first and signed off by a person before any wave; then the gate on each child's rebased head; then you, at the one PR. | Its own tests in its sandbox; then you, in the PR. MultiDevin's manager merges the workers that passed. |
| Where rework shows up | At the gate, per child, before it lands: a failed exit gate retries with the failure in its brief. Siblings never touch the same file, so there is nothing to reconcile at the end. | In PR review, after the fact; MultiDevin reconciles its workers before you see them. |
| Unit of work | An epic, or a story big enough to split into children. | A task or ticket per Devin; MultiDevin fans one task across up to ten workers. |
| What you get back | One reviewed pull request for the whole feature, with a ledger of every child and the evidence for each scenario in its description. | A PR per Devin; MultiDevin merges its workers into one branch or PR. |
| Where the agents run | Your machine, or a build box you open over SSH. One git worktree per child. | Cognition's cloud sandboxes. |
| Which agents | Claude Code, on your own subscription. Workers follow the target repo's CLAUDE.md, skills and settings. | Devin. |
| Planning | A wave table drawn from the tickets and shown to you first. Written back into the tickets, with each dependency as a blocker link. | Its own; a manager Devin splits the work in MultiDevin. |
| Tests before features | The spine writes every acceptance scenario as a failing spec. You sign off before any wave starts. | Runs tests in its sandbox. |
| Isolation between tasks | A worktree, branch, port and database per child. No two children in a wave touch the same file. | A sandbox per Devin. |
| Gates before landing | Task gate; exit gate, run again on the rebased head; CI; an optional review of each child; the epic gate. | Your CI on the PR. |
| Who merges | You. Children squash-merge into an integration branch, pinned to the commit their gate passed. Portia never merges to main. | You. |
| Tracker | Jira or GitHub Issues. | Linear, Jira, GitHub, Slack. |
| Model choice | Per child, from its tier: a cheaper model for routine children, a stronger one for the hard ones. | Cognition's. |
| Spend and capacity | Caps per worker, per wave and per epic. Waves are sized from free memory and the other runs on the machine. | Agent Compute Units. Free, Pro ($20), Max ($200), Teams and Enterprise. |
| Unattended, and resuming | Parks with one question instead of guessing. Detached workers outlive the session, with a stall detector; portia resume picks a run back up. | Fully hosted. |
| Licence and price | Free. Source on GitHub. | Proprietary, hosted. |

### What Devin does that Portia doesn't

- Hosted end to end: no machine of yours involved.
- Slack and ticket integrations across several trackers.
- Enterprise administration and a usage guarantee.

**Choose Devin when** You want a hosted agent that takes tickets from a queue, and your team has budget for compute units.

**Choose Portia when** You want the feature planned as one unit, tested first, with every child gated and the plan in your tickets, on hardware you control.

### Is MultiDevin the same as Portia's waves?

It fans one task across workers and merges the survivors. Portia's waves are the ready children of a planned epic, each with its own ticket, worktree, port and database, landed one by one on an integration branch after their gates pass.

Sources:
- [Cognition product update (MultiDevin)](https://cognition.ai/blog/sept-24-product-update)
- [Devin pricing](https://devin.ai/pricing)
- [Devin docs](https://docs.devin.ai/get-started/devin-intro)

## Portia vs OpenAI Codex

https://www.portia.run/compare/openai-codex · hosted cloud agent, many tasks in parallel · facts last checked October 2026

Codex runs each task in its own cloud environment, many at once, and proposes a PR for each. It needs nothing of yours to run; Portia runs on your machine and lands one feature as one PR.

Codex is OpenAI's software engineering agent. In the cloud, each task gets an isolated environment with your repository preloaded; you can run many at once, and each one proposes a pull request. It is also a CLI and an IDE extension, reachable from the web and a phone, with automatic review of PRs on GitHub.

Like Copilot's agent and Devin, it is hosted and task-shaped: one task, one environment, one PR. Parallelism is unlimited by your hardware because there is none of yours involved.

Portia is epic-shaped and local: Claude Code on your machine, a plan drawn from your tickets and approved by you, the shared code landed first, acceptance specs signed off, each child gated on its rebased head, and one PR at the end that a person merges.

| | Portia | OpenAI Codex |
|---|---|---|
| Who proves the work is right, and when | The tests, written first and signed off by a person before any wave; then the gate on each child's rebased head; then you, at the one PR. | Its own tests in its environment; then you, in the PR. |
| Where rework shows up | At the gate, per child, before it lands: a failed exit gate retries with the failure in its brief. Siblings never touch the same file, so there is nothing to reconcile at the end. | In PR review, after the fact; parallel tasks are independent PRs that meet on your branch. |
| Unit of work | An epic, or a story big enough to split into children. | A task; many at once. |
| What you get back | One reviewed pull request for the whole feature, with a ledger of every child and the evidence for each scenario in its description. | A proposed PR per task. |
| Where the agents run | Your machine, or a build box you open over SSH. One git worktree per child. | OpenAI's cloud, an isolated environment per task; also a CLI and IDE extension. |
| Which agents | Claude Code, on your own subscription. Workers follow the target repo's CLAUDE.md, skills and settings. | Codex. |
| Planning | A wave table drawn from the tickets and shown to you first. Written back into the tickets, with each dependency as a blocker link. | Its own, per task. |
| Tests before features | The spine writes every acceptance scenario as a failing spec. You sign off before any wave starts. | Runs tests in its environment. |
| Isolation between tasks | A worktree, branch, port and database per child. No two children in a wave touch the same file. | A cloud environment per task. |
| Gates before landing | Task gate; exit gate, run again on the rebased head; CI; an optional review of each child; the epic gate. | Your CI on the PR; automatic PR review. |
| Who merges | You. Children squash-merge into an integration branch, pinned to the commit their gate passed. Portia never merges to main. | You. |
| Tracker | Jira or GitHub Issues. | GitHub. |
| Model choice | Per child, from its tier: a cheaper model for routine children, a stronger one for the hard ones. | OpenAI's. |
| Spend and capacity | Caps per worker, per wave and per epic. Waves are sized from free memory and the other runs on the machine. | ChatGPT plans and credits. |
| Unattended, and resuming | Parks with one question instead of guessing. Detached workers outlive the session, with a stall detector; portia resume picks a run back up. | Fully hosted. |
| Licence and price | Free. Source on GitHub. | A ChatGPT subscription, or the API. |

### What OpenAI Codex does that Portia doesn't

- Nothing to run locally.
- Many tasks at once with no machine limit.
- Web, terminal, IDE and phone.

**Choose OpenAI Codex when** Independent tasks, each its own PR, in OpenAI's cloud.

**Choose Portia when** One feature with shared code, Claude Code, your machine, and a single PR that a person merges.

### Can Portia use Codex as a worker?

No. Workers are Claude Code sessions.

Sources:
- [Introducing Codex (OpenAI)](https://openai.com/index/introducing-codex/)

## Portia vs Cursor cloud agents

https://www.portia.run/compare/cursor-cloud-agents · hosted agents from the Cursor editor · facts last checked October 2026

Cursor's cloud agents each run in their own VM and come back with a PR, screenshots and video. They start from the editor, the web, Slack, Linear or a phone. Portia is the planned, gated, one-PR counterpart on your own machine.

Cursor's cloud agents (formerly background agents) run in isolated Ubuntu VMs with your repository, dependencies and secrets, and finish with a pull request that carries screenshots, video and logs of what they did. They can be started from the Cursor app, cursor.com, the iOS app, Slack, GitHub, Linear or an API, and automations run them on schedules and events. Enterprises have been able to self-host the VMs since March 2026.

Again task-shaped and hosted. Cursor's own blog describes up to eight agents in parallel on one prompt; whatever the number, each is an independent VM and PR.

Portia is one epic, planned from the tracker and approved by you, run as Claude Code workers on your machine, gated on each child's rebased head, and landed on one integration branch for one PR.

| | Portia | Cursor cloud agents |
|---|---|---|
| Who proves the work is right, and when | The tests, written first and signed off by a person before any wave; then the gate on each child's rebased head; then you, at the one PR. | Its own tests in the VM, with screenshots and video on the PR; then you. |
| Where rework shows up | At the gate, per child, before it lands: a failed exit gate retries with the failure in its brief. Siblings never touch the same file, so there is nothing to reconcile at the end. | In PR review, after the fact; parallel agents are independent PRs. |
| Unit of work | An epic, or a story big enough to split into children. | A task per agent; up to eight in parallel on a prompt, per Cursor's blog. |
| What you get back | One reviewed pull request for the whole feature, with a ledger of every child and the evidence for each scenario in its description. | A PR per agent, with screenshots, video and logs attached. |
| Where the agents run | Your machine, or a build box you open over SSH. One git worktree per child. | Isolated Ubuntu VMs in Cursor's cloud; self-hosted for enterprise since March 2026. |
| Which agents | Claude Code, on your own subscription. Workers follow the target repo's CLAUDE.md, skills and settings. | Cursor's agent. |
| Planning | A wave table drawn from the tickets and shown to you first. Written back into the tickets, with each dependency as a blocker link. | Its own. |
| Tests before features | The spine writes every acceptance scenario as a failing spec. You sign off before any wave starts. | Runs tests in the VM; has a desktop and browser to check UIs. |
| Isolation between tasks | A worktree, branch, port and database per child. No two children in a wave touch the same file. | A VM per agent. |
| Gates before landing | Task gate; exit gate, run again on the rebased head; CI; an optional review of each child; the epic gate. | Your CI. |
| Who merges | You. Children squash-merge into an integration branch, pinned to the commit their gate passed. Portia never merges to main. | You. |
| Tracker | Jira or GitHub Issues. | GitHub, Linear, Slack, API; automations on events. |
| Model choice | Per child, from its tier: a cheaper model for routine children, a stronger one for the hard ones. | Cursor's model menu. |
| Spend and capacity | Caps per worker, per wave and per epic. Waves are sized from free memory and the other runs on the machine. | Cursor plans and usage. |
| Unattended, and resuming | Parks with one question instead of guessing. Detached workers outlive the session, with a stall detector; portia resume picks a run back up. | Fully: close the laptop. |
| Licence and price | Free. Source on GitHub. | A Cursor subscription. |

### What Cursor cloud agents does that Portia doesn't

- Proof of work on the PR: screenshots and video.
- Automations on schedules and events.
- Start from the app, the web, Slack, Linear or a phone.

**Choose Cursor cloud agents when** You live in Cursor and want tasks to run in its cloud while you do something else.

**Choose Portia when** You want an epic planned and landed as one PR on your own machine with Claude Code, with gates you define.

### Does Portia check UIs?

When a child's plan block names a design, Portia renders the route in headless Chromium in the exit gate and compares it with the Figma frame or canvas, pixel-wise and element-wise. The design check is optional and set per child.

Sources:
- [Cursor docs: cloud agents](https://cursor.com/docs/cloud-agent)
- [Cursor docs: security overview](https://prod.cursor.com/docs/cloud-agent/security)