Orca puts five coding agents in five git worktrees and shows you all of them at once

One prompt fanned across five agents, each in its own git worktree

The organising idea is parallel worktrees. You write a prompt, choose several agents, and each one gets the same request inside an isolated git worktree of its own. When they finish you compare the results side by side and merge the one you want.

The worktree is doing the real work here. Git worktrees let several checkouts of the same repository exist at once, each with its own working directory, so two agents editing the same file do not collide and neither sees the other's half-finished changes. That is what makes running five at once safe rather than merely possible.

The same model extends to remote machines. SSH worktrees run agents on a beefy remote box with full file editing, git and terminals, with reconnection and port forwarding handled for you. The isolation is the same mechanism, only the machine changes.

The cost is that you are now managing five branches. Merging the winner means resolving whatever the other four left half-done, and the worktree isolation that makes the parallel run safe does nothing to make the merge easy.

The terminal is WebGL-rendered and the scrollback survives a restart

The embedded terminal is described as Ghostty-class with WebGL rendering, infinite splits, and scrollback that survives restarts.

WebGL rendering is the part with a visible consequence. Here the terminal surface is rendered with WebGL.

Scrollback surviving restarts is the feature that changes daily use. A terminal that forgets what you scrolled past when Orca restarts forces you to re-derive state after every crash or update, and an agent workspace restarts more often than a plain terminal because the app is the supervisor of several long-running processes.

Design Mode reads a real Chromium window, not a screenshot you upload

Design Mode lets you click any UI element in a live Chromium window and send that element's HTML, its CSS, and a cropped screenshot straight into the agent's prompt.

The mechanism is what makes it useful. The window is real, so the HTML and CSS come from the page you are actually looking at. The crop is scoped to the element you clicked, so the image the model sees is the thing you pointed at and not a full-page capture it has to guess about.

The limitation is that it depends on a browser being open and being pointed at the right page. If the page you want to talk about is not rendering in a Chromium window in front of you, the feature has nothing to read, and the alternative is going back to pasting markup by hand.

Any CLI agent runs in Orca, which cuts both ways

The compatibility claim is that Orca works with any CLI agent, on the reasoning that if it runs in a terminal, it runs in Orca. The list of named agents is long and includes Claude Code, Codex, Grok, Cursor, GitHub Copilot, Muse, DeepSeek Harness, ZCode, OpenCode, MiMo Code and Amp.

The strength of that design is that it cannot fall behind. Orca does not wrap any agent, it hosts one, so a new agent CLI works the day it ships rather than after an integration is written.

The weakness is the same fact seen from the other side. Anything that requires knowing which agent is running is a special case, and you can see where those special cases live. The usage tracking feature reports Claude and Codex usage and rate-limit resets, and it is named after those two products rather than being generic. The account switcher hot-swaps accounts for the same reason.

For a user on a third agent, the parallel worktrees, the terminals, the diff annotation and the design mode all work, and the usage panel is the part that has nothing to show.

Sixteen lint gates run before anything lands, and husky runs them on commit

The lint script is a chain of sixteen steps rather than a single command. It starts with oxlint, then runs an anti-slop audit, two code-quality audits that differ in whether they are type-aware, and a series of named checks: reliability gates, dead classes, a max-lines ratchet, a ts-nocheck ratchet, a runtime-electron ratchet, and a check that the README's local links resolve.

Then come the verification steps, which are about the repository's own consistency: a catalog of RPC parameters, the bundled skill guides, a skill bundle manifest, and four separate localization checks covering catalogs, extraction and coverage.

Installing dependencies for a release build takes one command, with a CPU filter:

pnpm install --frozen-lockfile --cpu=current,x64,arm64

Formatting is oxfmt with a write flag, and two of the audits fetch their tools at run time with pinned versions, react-doctor at 0.9.1 and knip at 5.88.1. The repository uses husky for commit hooks and keeps its oxlint and oxfmt configuration in dotfiles at the root.

The two ratchets are the interesting part. A max-lines ratchet and a ts-nocheck ratchet both enforce a ceiling that can only move in one direction, which is how a codebase stops growing the problems it already has.

package.json reads 1.4.214 while the newest release is 1.4.217

The version fields do not agree, and the pattern is the point. package.json declares 1.4.214. The newest releases listed are v1.4.247 on 3 November 2026 and v1.4.246 on 2 November, and the last push to main is 2 November 2026.

Releases on consecutive days match what the project says plainly: it ships daily and its own feature list is perpetually behind, with the changelog named as the real feature list.

For a user, daily shipping means the feature grid in the README is a lagging indicator. It is not wrong, it is incomplete, and the project says which document to read instead. That is a better failure mode than a README that claims completeness.

For anyone pinning a version, the gap between the declared version and the released tags is a reason to pin the tag rather than the manifest. Reading 1.4.214 out of package.json tells you about a commit, not about what is installable.

The mobile companion is on its own version line at 0.0.50

The mobile app is distributed separately from the desktop build. It is on the iOS App Store, and the Android side is an APK, at version 0.0.62 in the latest releases, downloaded from the project's website rather than from a store.

The feature is narrow by design. You get notified when an agent finishes and you can send follow-ups from the phone. It monitors and steers, and that is the scope.

The version gap is the detail worth planning around. A desktop app at 1.4.247 and an Android APK at 0.0.62 are not the same product at different points, they are two products with independent lines. Nothing in the announcement of a desktop feature tells you whether the phone app can show you the result, and an Android user sideloading an APK from a download page is doing something different from an iOS user on the App Store.

For a team that wants to check on a long agent run from a phone, this is useful. For anyone who needs the phone app to be a full second seat, the version numbers suggest it is not there yet.

Editorial conclusion

Orca earns its place if you already run more than one coding agent at a time and lose track of which one is editing what, because the worktree isolation is the feature everything else hangs off. It does not earn its place if you run a single agent, since the parallelism adds a workspace to learn for no benefit. Before you commit, read the changelog rather than the feature list, because the project says outright that its own list is behind, and check whether the mobile companion matters to you at all: it ships on a separate version line at 0.0.62 while the desktop app is past 1.4.247.

Frequently asked questions

Official sources

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