Orca — An Agent Development Environment for Running Agents in Parallel

Working with a single Claude Code session in a terminal eventually settles into a pattern. Hand it a task, wait, switch branches, hand it the next one. The agent could work in parallel; my workspace is what makes it sequential.

Orca goes after that. It calls itself an ADE — Agent Development Environment. If an editor is an IDE for people, this is an IDE for agents.

It shipped in March 2026 under the MIT license. Everything below is as of September 2026, and this project moves fast, so details like config formats may shift.

It is not a model

First thing to get straight: Orca is not an AI.

It has no model of its own. It runs the CLI agents you already use — Claude Code, Codex, Cursor CLI, OpenCode, GLM-5.2 and others. The docs claim 30+. Broadly, if it runs in a terminal, it attaches.

So you need your own subscriptions or API keys. Orca itself is free, and that is all it is.

One concept — the worktree

Understanding this tool really comes down to one line:

one task = one git worktree = one agent

What Orca creates is a real git worktree — not a virtual layer of its own. An actual directory appears on disk with a branch checked out. You can cd into it and use plain git whenever you want. It also means your work survives if you uninstall Orca.

That is why agents never touch each other’s files. Each has its own directory. No branch switching, no stashing.

Install

1
2
3
4
5

# macOS
brew install --cask stablyai/orca/orca

# Arch
yay -S stably-orca-bin

Windows uses the installer from GitHub releases; Linux has an AppImage plus .deb / .rpm. The macOS build is signed and notarized.

On Linux the CLI is named orca-ide, not orca — it would otherwise collide with the GNOME screen reader.

On first launch it asks for home directory access to manage repositories, and offers to import existing ~/.claude, ~/.codex and Ghostty settings. It auto-updates on the stable channel by default.

The basic loop

The docs compress it to one line:

1

add → worktree → agent → split → diff → ship

1. Add a repo

Add Repo in the sidebar, pointed at a local checkout. Orca reads the git state and takes your default branch as the base ref.

2. Create a worktree

The + next to the repo name. Whatever name you type becomes the branch name; leave it blank and Orca names it after a marine creature.

Then pick a start-from ref. Usually the base ref (origin/main), but any local branch, remote branch or commit SHA works.

On submit the dialog closes immediately while git fetch and git worktree add continue in the background. The worktree appears in the sidebar with a progress row.

3. Attach an agent

A terminal opens with an agent combobox at the top. Pick one and Orca launches that CLI with the right directory context and credentials forwarded.

4. Race them

Repeat steps 2–3 so that the same prompt goes to three different agents. This is the use case Orca leads with.

5. Split the panes

Drag a worktree tab to the right or bottom edge of another pane and it splits. Three agents running at once, on one screen.

6. Pick one and ship

Open each worktree’s diff viewer. Annotate AI Diff lets you comment directly on diff lines and send those comments back to the agent. This is the genuinely good part — review and revision instructions happen in one place.

Pick the best one and commit/push from inside Orca. Delete the rest in one click; the directory and the branch both go (with a confirmation).

If git refuses to delete a branch because of unmerged commits, Orca keeps it and gives you a step to force-delete or retain specific branches.

The first real obstacle

A fresh worktree has no node_modules, no .env, no build cache. Re-running npm install every time defeats the point of parallelism. This is the actual barrier.

Orca solves it two ways, and the split between sharing and copying is the whole idea.

orca.yaml — share (symlink / clone-copy)

This one gets committed to the repo.

1
2
3
4

worktree:
  sharedDirectories:
    - node_modules
    - .cache

These are symlinked or APFS clone-copied, not copied outright, which saves disk and time. npm install still runs, but finishes far faster because the tree is already materialized from the primary checkout.

Two conditions apply:

• the path must exist as a directory in the primary checkout
• it must be gitignored

Tracked or missing paths are simply skipped. They fail silently, so suspect this first when sharing does not take effect.

.worktreeinclude — copy

A file at the repo root. These are copied, not symlinked — for things each worktree needs its own version of.

1
2
3

# local environment
.env
.vscode/settings.json

Blank lines and # comments are allowed. No globs — literal paths only.

The rule of thumb:

The Orca CLI is the interesting part

Judged by the UI alone this looks like a pretty terminal wrapper. This side is more interesting to me.

The orca command scripts a running Orca editor from any shell. Register it under Settings → General → Orca CLI.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# worktrees
orca worktree ps                 # list
orca worktree create             # create (repo, name, issue link)
orca worktree current
orca worktree rm

# agent terminals
orca terminal list
orca terminal send  ...          # push input in
orca terminal read  ...          # read output
orca terminal wait  ...          # block until a given state
orca terminal split ...          # directional split

# files / diffs
orca file open
orca file diff
orca file open-changed

The browser is scriptable too.

1
2
3
4
5
6

orca goto <url>
orca snapshot          # interactive DOM state
orca click / orca fill
orca screenshot
orca set device        # device profile for responsive testing
orca tab profile       # isolated browser session

There is iOS Simulator control (orca emulator attach/tap/type/gesture/rotate), orca automations for scheduled work, orca artifacts for shareable links, and orca skills install for registering agent capabilities.

Most commands take --json output and --worktree <selector> targeting.

Which means you can have an agent drive Orca itself. Push an instruction with terminal send, block on terminal wait, read the result with file diff — that loop is a shell script.

You also choose where it runs

Tailscale is the recommended networking for the remote server mode. For long-running agent sessions, or just checking status from a phone, that is the combination.

When it is worth it

The split is fairly clear.

Good fit

• Problems where you do not know the approach — race three, pick one. The original use case
• Comparing agents — settling Claude Code vs Codex on actual code rather than vibes
• Several independent tasks — three bugs in three different files genuinely parallelize
• Review-heavy teams — the diff-comment-back-to-agent loop
• Remote development — run on an SSH host, watch from a phone

Bad fit

• Sequentially dependent work — if B depends on the outcome of A, parallelism buys nothing. Diagnose → fix → measure is usually this shape
• Work that converges on one answer — writing, config edits. Three candidates just make the choosing slower
• Tight token budgets
• Production workflows that need stability — it is too early

What honestly bothers me

It would be dishonest to only list the good parts.

Cost multiplies

Racing three means three times the tokens, and two get thrown away.

The sharper point is this. One independent review notes that parallel sessions “multiply cost and review debt” — the reviewing burden scales too. Choosing between three means reading three diffs. Choosing without reading them is just rolling dice.

Security findings, half of them resolved

Four issues were raised on the Windows side. Checking the repository as of September 16, 2026:

The ACL one was substantial. powershell.exe -Command does not populate $args, so the hardening script ran with no target and protected nothing — while the tests passed. The fix moved to icacls.exe, removing the injection surface along the way.

The two still open worry me more.

The listener issue: any device that had paired once was enough, by history alone, to make the runtime bind to 0.0.0.0. From the PR:

An operator who never said “expose this to my network” should not have the runtime bind to every interface just because some device connected once.

The fix adds networkExposureConsent, defaulting to false, so nothing goes past loopback without explicit consent. Not merged yet.

The credential one is nastier. When Orca decides an agent is ready it types the task prompt into that pane. If that verdict is wrong and a credential prompt is on screen instead, the prompt gets submitted to an auth provider as a credential attempt. It is a draft, and the reviewers’ notes about false positives and non-English prompt detection are still open.

Worth trying in an isolated environment before pointing it at company machines or sensitive repositories.

Telemetry is on by default

Anonymous, and opt-out rather than absent. You have to turn it off yourself.

It is young

Six months old. Workflow and configuration stability are not proven.

Summary

• It is a shell, not a model. Bring your own agent subscriptions
• Worktrees are the core. Real git worktrees, so the work outlives Orca
• Dependencies are the first hurdle. orca.yaml to share, .worktreeinclude to copy
• The CLI is where it gets interesting. An agent can drive Orca itself
• Sequential work gains nothing. This is a tool for problems with divergent approaches
• Cost multiplies, and so does review burden
• Two of four security findings merged, two still open. Isolate it first

If you want to try it, the Your first 3-agent session tutorial is enough to get the feel. The docs flag it as their single most important page.

On a Hugo static site like this blog, where there is no node_modules at all, creating a worktree costs nearly nothing — and the parallel gain is proportionally small. Looked it up out of curiosity anyway If I use it, it will be on a work codebase.

References

• Docs — https://www.onorca.dev/docs
• Your first 3-agent session — https://www.onorca.dev/docs/first-session
• Worktree model — https://www.onorca.dev/docs/model/worktrees
• Orca CLI — https://www.onorca.dev/docs/cli/overview
• Ways to run — https://www.onorca.dev/docs/ways-to-run
• GitHub — https://github.com/stablyai/orca
• Independent review (limits, security) — https://vibecodinghub.org/tools/orca