Compare · last checked October 2026
Portia vs Bernstein
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.
Questions
- 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's column comes from the pages below, read in October 2026. Portia's comes from its README and reference. If a cell is wrong, open an issue.