Orca: a workspace for running several coding agents at once

The problem Orca targets: too many agent sessions, no single view

Running one coding agent in one terminal is easy. Running five is not. Each agent wants its own branch, its own working directory and its own terminal, and once they are all going you are alt-tabbing between windows trying to remember which one is waiting on a permission prompt. Orca's answer is to make the worktree the unit of work. The README describes the core feature as fanning one prompt across five agents, each in its own isolated git worktree, then comparing the results and merging the winner. The audience is developers who treat agents as parallel workers rather than as a single assistant. The README's own framing is builders running Codex, ClaudeCode, OpenCode or Pi side by side. If you run one agent at a time, the coordination layer is overhead you will not use.

How Orca works: worktrees, terminals and an Electron shell

The repository layout shows an Electron application: electron.vite.config.ts at the top level, a main entry at ./out/main/index.js, and a React renderer alongside it. The package.json description calls it a next-gen IDE for parallel agentic development. Around that shell sit several distinct pieces: src/ for the app, mobile/ for the companion app, cloud/ and native/ directories, a skills/ tree with skill-guides/ and skill-stubs/, and an examples/plugins/ directory for plugin authors.

The mechanism that matters is the worktree. Orca does not invent a new isolation primitive; it uses git worktrees, so each agent session gets a real checkout on its own branch with a shared object store. That means an agent cannot corrupt another agent's files, and merging the winner is an ordinary git merge. The terminal layer is the second half: the README describes Ghostty-class terminals with WebGL rendering, infinite splits, and scrollback that survives restarts. The third piece is the CLI, which exposes the same operations to scripts: orca worktree create, snapshot, click and fill are the four the README names. That last pair is worth noting. click and fill imply Orca can drive a real browser or desktop UI, which is what the Design Mode and Computer Use features are built on.

Installing Orca and opening your first worktree

Orca is distributed as a desktop download rather than an npm package you add to a project. The README points at https://onorca.dev/download, and the package.json declares a bin entry named orca that resolves to ./out/cli/index.js, so the CLI ships with the app rather than as a separate install. The repository also carries a Casks/ directory, which is the Homebrew cask layout for macOS distribution.

The README does not walk through a terminal install, so the honest starting point is the download page. Once the app is running, the CLI is what you script against. The README names these subcommands:

orca worktree create
orca snapshot
orca click
orca fill

Treat that list as the documented surface, not as a full flag reference. The README gives the subcommand names and links to a CLI overview page at onorca.dev/docs/cli/overview for the rest. The repository also has an orca.yaml at the top level, which is the configuration file a project would carry, though the README does not enumerate its keys. If you want to see what a plugin looks like before writing one, examples/plugins/ is the directory to read. For a first real use, the sequence the README implies is: create a worktree, point an agent CLI at it inside an Orca terminal, and let it run while you open a second worktree for a second agent.

Where Orca gets in the way

The release cadence is the first thing to understand. The version in package.json is 1.4.197, and the recent releases list shows v1.4.192 on 2026-08-29, v1.4.191 the day before, and a separate mobile-android-v0.0.46 tag on 2026-08-27. The README says so itself: we ship daily, so this list is perpetually behind. The last push to the repository was on 2026-08-29. A project moving that fast is not one where you can pin a version and forget it. Documentation will lag the binary, and the README already concedes that its feature list is behind the changelog.

The second constraint is the delivery model. Orca is an Electron desktop app, with a mobile companion for iOS and Android. There is no documented headless server mode in the README, and no documented way to run the orchestration layer in CI. The SSH Worktrees feature runs agents on a remote box, but the README frames it as connecting the desktop app to a remote machine, not as a server daemon. If your workflow is entirely terminal-based and you never want a GUI in the loop, the CLI alone may not cover what the app does.

Third, the README says Orca works with any CLI agent, and the supported list is long: Claude Code, Codex, Grok, Cursor, GitHub Copilot, OpenCode, MiMo Code, Amp, OpenClaude, Antigravity, Pi and more. That is a genuine strength, but it also means Orca is not responsible for agent behaviour. Rate limits, context limits and tool permissions are the agent's problem, not Orca's. The usage-tracking feature shows Claude and Codex usage and rate-limit resets, which is a monitoring convenience, not a fix.

Orca compared with plain git worktrees plus tmux

The obvious alternative is doing this yourself: git worktree add for each agent, a tmux session per window, and a shell script to fan out the prompt. That approach has real advantages. It is scriptable end to end, it runs on a headless server, and it has no GUI dependency. The difference in approach is that tmux gives you panes and Orca gives you state. Orca tracks which agent owns which worktree, notifies you when one finishes, keeps scrollback across restarts, and lets you annotate a diff line and send the comment back to the agent without leaving the window. With tmux you build all of that yourself, or you lose it.

The other alternative is staying inside a single editor and using its agent integration. That keeps you in one window, but it generally assumes one agent per workspace. Orca's bet is that the interesting work happens when several agents run at once and you need to compare their output. If you never compare two agents on the same task, that bet does not apply to you. The README's parallel-worktree example, fanning one prompt across five agents, is the clearest statement of the intended workflow.

Licence, maintenance and what an upgrade costs

Orca is MIT licensed, and the LICENSE file sits at the repository root. MIT is permissive: you can use, modify and redistribute the code, including in closed products, provided the copyright notice and licence text travel with it. That is the standard reading, not legal advice, and if you plan to redistribute a modified Orca you should read the file yourself rather than take this paragraph as a substitute.

The practical licence question is different. Orca orchestrates agents that are themselves proprietary services with their own terms, and the mobile companion is distributed through the App Store and a TestFlight build for iOS and a GitHub-hosted APK for Android. Nothing in the repository suggests Orca imposes terms on top of those, but the agent CLIs you point it at do.

On maintenance, the last push was on 2026-08-29, and releases land on consecutive days. The cost of that cadence is upgrade churn. Because the CLI ships inside the app and the bin entry points into ./out/, upgrading the app upgrades the CLI, which means a script that worked against one build can change behaviour under you. There is no documented rollback procedure in the README, and no documented version pinning for the desktop app. Budget for reading the changelog before you upgrade a machine that runs long-lived agent sessions.

Editorial conclusion

Adopt Orca if you already run CLI agents and want several of them in isolated worktrees with one place to watch them, and if you are comfortable with a project that ships several releases a week. Skip it if you need a documented stable API surface, if your workflow is a single agent in a single branch, or if you cannot run an Electron desktop app. Before committing, verify three things: that your agent CLI of choice launches inside an Orca terminal, that the SSH worktree path works against your remote host, and that the orca.yaml in the repository root matches the configuration keys your install expects.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes