Today I want to introduce an AI coding tool I use: Orca.
I rarely write about tools. I've always felt the tool itself matters less than the user problem we're actually solving. I'm making an exception today because, in my experience so far, very few products on the market understand and solve AI builders' pain points the way Orca does.
If this sounds like you:
- You work on 5 or more projects at the same time
- Within one project, you keep switching between branches because you're building several features at once
- You have 5 or more Claude Code / Codex / Pi sessions open at once
- Jumping between those projects, you struggle to keep track of context, and sometimes your mind goes blank ("wait, what did I just ask Claude Code to do?")
- You want to see what all your agents are doing, and their status, at a glance
- You feel that every cmd+tab costs you your focus
then you really need to try Orca.
Below I'll go through what it is and why it has suddenly taken off in the industry.
Most of this comes from a Chinese-language interview with Orca founder 津晶 (Jinjing) (video), plus Orca's official documentation. At the time of recording, the Orca team was four people and the GitHub repo stablyai/orca was close to 50,000 stars. Downloads are reportedly far higher than the star count.
What Orca is
Orca calls itself an ADE. In the founder's words:
"ADE is a very new concept. You can think of it as an Agent IDE, a new kind of workspace where people and agents work together really well."
Orca is not a new coding agent, and it doesn't build one. Users keep running Claude Code, Codex, OpenCode and other existing tools inside Orca's built-in terminal, and Orca organises them:
"We focus on integrating the tools and making them work together, so we don't have our own harness. Users find they can pick up Orca in a minute, because they can use Claude Code and Codex directly in Orca's built-in terminal."
The name reflects the positioning: Orca comes from "orchestration for agent". It's also the word for killer whale.
Main features:
- GitHub issues or Linear tickets become parallel work threads, and progress syncs back to Linear automatically
- One view that shows the status of every agent
- Management of the full git worktree and PR lifecycle
- A built-in browser and mobile emulator for QA, plus annotation directly on HTML pages
- A CLI with orchestration built in, so agents can manage other agents
- Automations that can run on a remote host
What problem it solves
1. You lose track once there are too many agents.
"When you get to about five Claude Codes in the terminal, you may already have no idea who is doing what."
Orca's heavy users run far more than that. The founder says users "typically run hundreds of agents at the same time": 10 to 20 features in progress, with four or five agents working together on each. The founder personally has more than 400 worktrees, meaning more than 400 features in progress at once.
Orca pulls the status of every agent, across every worktree and every tool, into one place and tells you what to deal with first:
"This one is working. This one is blocked and needs your answer right now. This one is done and needs you to review the result right now."
2. Switching between five or six apps.
Getting a feature from start to finish usually means going through a task tracker, a terminal, code review, testing and a PR. Orca puts all of that in one app:
"All of these tools are integrated in Orca, so you don't have to keep switching between five or six different apps. You can get all the way through in one path."
Many users have written a fixed recipe: start from a Linear ticket, gather requirements, write a design doc, review it several times, implement, run QA in Orca's built-in browser, and return a PR plus an HTML report. As the host put it, the human only checks "the first step and the last step."
3. Hitting usage limits and being tied to one vendor.
When Claude Code hits its limit, Orca can hand the current work to another agent in one click:
"We even have a handoff feature. One click sends the Claude Code session to Codex, and Codex just carries on working as if nothing happened."
For companies, this is about cost. The founder says that at many companies, "the Anthropic bill has become their biggest expense, bigger than what they spend on engineers," so they are seriously looking at Codex and open-weight models.
4. Updating the terminal wipes every session.
The founder's team used to run agents in split panes in Ghostty and iTerm. But any update to those terminals kills every session:
"You might have 50 agents running, and after one update… which ones are still running and which have finished, you have to figure that out yourself every time. So basically nobody dares to update."
Orca snapshots every terminal session (PTY) to a local database and restores it after an update. Running agents and dev servers keep going.
Deep dive: how worktrees and agent orchestration save time
Running hundreds of agents at once really comes down to two things: a worktree for each task, and agents coordinating other agents. That's what lets many agents work at the same time without getting in each other's way, and lets the human show up only at the steps that need a decision.
Part 1: What a worktree is, and why agents need one
In the traditional way of writing code, a normal git repository usually has one working folder, and it can have only one branch checked out at a time. To work on two features you either switch branches back and forth, or clone the whole repo again.
A git worktree is a second (or third, or fortieth) working folder attached to the same repository. Each one has its own branch and its own files, while all of them share one git history. You can have feature-login open in one folder and fix-billing in another, and a commit in either shows up in the same repo.
That doesn't matter much when one person edits one thing at a time. But once you start using several agents to build several features at once, the traditional workflow becomes the bottleneck. Put two agents in the same folder and they overwrite each other's files, one agent's test run picks up the other's half-finished changes, and a branch switch pulls the files out from under both of them. So agents in a single folder end up taking turns.
Orca describes itself as "worktree-native": every task gets its own worktree, so agents "never interfere with each other's files." Ten agents on ten tasks means ten folders and ten branches. None of them touches another's files, and none waits for another. It also supports child worktrees.
repo (shared git history, base: origin/main)
├── worktree: login-redesign → branch login-redesign → Claude Code
├── worktree: billing-bug → branch billing-bug → Codex
├── worktree: docs-refresh → branch docs-refresh → Claude Code
└── worktree: pr-reviews (parent)
├── child: review-PR-101 → Codex
└── child: review-PR-102 → Claude Code
Part 2: Nested worktrees, one parent task with many children
Worktrees can be nested in the sidebar: a parent workspace with child worktrees underneath. The nesting isn't written into git history.
This is the setup behind the Cloudflare example from the interview. The engineer has a master agent in a top-level worktree that opens about 20 child worktrees, one for each PR review that day, and follows all 20 at once. The parent keeps the day's work in one group, and each child keeps one review separate from the rest.
Part 3: Removing the hassle of setting up worktrees
Raw git worktrees have always been available. Most people don't use them because of the setup: every new folder needs dependencies installed, .env files copied in, and the branch named and cleaned up afterwards. Orca's docs describe how each of those steps is handled:
- Creation runs in the background. Once you submit the Create Worktree dialog it closes, and the
git fetchandgit worktree addkeep running in the background. You can keep working while the new worktree is prepared. - Dependencies are shared, not reinstalled. A
worktree.sharedDirectorieslist inorca.yamllinks big folders that can be rebuilt, such asnode_modulesor.cache, into every new worktree, so you don't reinstall them for each task. - Secrets and local config are copied in. A
.worktreeincludefile lists gitignored files, such as.envand.vscode/settings.json, to copy into each worktree, so an agent can run the app straight away. - Branches are named from the ticket. Paste a GitHub, Linear, Jira or GitLab link, and Orca names the branch from that item. For Linear it uses Linear's own branch name.
- The lifecycle is one flow: create → work (terminals, editor, browser scoped to that worktree) → review (diff against where it branched from, annotate the AI's changes) → ship (commit, push, open a PR, watch checks) → archive or delete in one click. If a branch has unmerged commits, Orca keeps the branch when you delete the worktree and asks you to review it first.
Starting a parallel task used to take several minutes of manual setup. With Orca it takes about as long as filling in a dialog. It's essentially a whole new way of working.
Part 4: Status, so your attention goes to the right place
With parallel worktrees, running many agents is easy. The hard part is knowing which one needs you. Orca reads each agent's state from signals that Claude Code, Codex and other agents already emit (terminal title sequences and agent hooks), and shows it as a glyph:
- spinner: working
- amber question mark: waiting on you (permission or input)
- green: done
- red: blocked or failed
- gray: idle
An experimental Agent Dashboard puts every session on a kanban board: Needs You, Working, Done, Idle. When an agent goes idle, Orca sends an "agent-finished" notification.
Once you run more than a handful of agents, the limit on how much gets done is how often you respond to them. Without a status view, you have to open each tab to find out which agent has been waiting on a yes/no question for 40 minutes. With one, you work through the Needs You column and ignore everything else.
Part 5: Orchestration, agents managing agents
Worktrees let agents work in parallel. Orchestration adds structure to that. Orca's CLI has a coordinator/worker system built from five parts:
| Part | What it is |
|---|---|
| Run | The overall job, and the inbox where results come back |
| Task | One unit of work, with a spec, dependencies and a state (pending, ready, dispatched, completed, failed, blocked) |
| Dispatch | One attempt at a task, by one agent, in one terminal |
| Message | Status updates, completions, questions and escalations sent to the coordinator |
| Decision gate | A question that blocks a task until someone answers it |
A typical flow from the docs looks like this. First, create the run and a task:
orca orchestration run-create --objective "Split checkout QA and summarize blockers" --json
orca orchestration task-create --spec "Audit billing settings for mobile layout" --task-title "Billing audit" --json
Then start a worker in its own child worktree, choosing the agent (codex, claude, cursor or antigravity) and optionally the model and effort level:
orca orchestration worker-start --task <taskId> --worktree new-child --name billing-audit --agent codex --json
When the worker finishes, it reports back with the outcome and which files it changed:
orca orchestration send --type worker_done --subject "Completed mobile audit" \
--body "Fixed footer overlap; no follow-ups." --task-id <taskId> --dispatch-id <dispatchId> \
--outcome succeeded --files-modified "src/app/settings/Billing.tsx" --json
Meanwhile the coordinator waits on its inbox:
orca orchestration check --wait --types worker_done,escalation,question --timeout-ms 900000 --json
If a worker hits a judgement call, it doesn't guess. It asks a structured question with fixed options:
orca orchestration ask --to <coordinatorHandle> \
--question "Update shared component or only this page?" --options "shared,page-only" --json
The coordinator can also set a decision gate on a task, such as "Merge the shared button change into the task branch? yes/no", and the task doesn't go further until someone resolves it. Failed tasks are retried explicitly with --retry-of <dispatchId>, and finished workers are released so their terminals don't pile up.
Why this saves time:
- The coordinator is an agent, not you. It splits the job, starts the workers, reads their reports and retries failures. You set the objective and answer gate questions.
- You only see questions that need a decision, as multiple choice. A worker asks "shared or page-only?" rather than writing a paragraph you have to read. That's the "give me something easy to review" pattern the founder describes, built into the protocol.
- You can use the best agent for each task. One run can send a refactor to Claude Code and a test sweep to Codex, and give a simple task a cheaper model or a lower effort level. That's how the founder's multi-vendor setup works in practice.
- Reports are structured. Because each
worker_donemessage lists the files it changed and the outcome, the coordinator can check for overlapping changes before anything is merged. - It's the same pattern as the interview's recipes. The founder's "Linear ticket → requirements → design doc → review → implement → QA → PR + HTML report" pipeline is a set of tasks in one run, with gates where a human needs to decide.
Part 6: Limits to keep in mind
- Review is the new bottleneck. Parallel agents produce more pull requests than one person can read closely. As the founder says, the human checks "the first step and the last step," so those checks need to be real.
- Separate folders don't prevent merge conflicts. Two agents can change the same shared component in two worktrees. The conflict shows up when you merge, not while they work. This is what the decision gates and file-level reports are there to catch.
- A worktree is not a security sandbox. Orca turns on full-autonomy flags for supported agents by default, on the view that "the worktree itself is the sandbox." A worktree keeps agents' files apart. It doesn't stop an agent running shell commands elsewhere on your machine or using credentials copied in through
.worktreeinclude. - It uses a lot of resources. Every worktree is a folder on disk and every agent terminal uses memory. The founder mentioned the caching and storage work needed to keep hundreds of sessions responsive.
How it differs from Claude Code and OpenCode
Compared with harnesses like Claude Code and Codex
The founder separates two ideas. A harness is the "loop" that turns a model into an agent:
"You give the AI an input and it gives you an output. A harness turns that agent into a loop, and the loop can also call lots of tools, like reading your bash or searching the web."
Claude Code, Codex, OpenCode, Pi and Devin are all harnesses. An ADE sits on top of them:
"It doesn't connect to the model directly and it doesn't build the loop itself. It leaves that to existing harnesses and focuses on the workflow of people managing agents."
The specific differences:
| Claude Code / Codex | Orca | |
|---|---|---|
| What it is | A harness: model, agent loop and tools | An ADE: management and collaboration on top of other harnesses |
| Vendor | Only its own models and subscriptions | Neutral. Claude Code, Codex, OpenCode and others run side by side and hand off to each other |
| Scale | Hard to follow past five sessions | Built for hundreds of agents across hundreds of worktrees |
| Status view | Claude Code has an agent view, but only for its own sessions | One status view across every harness and every worktree |
| Hitting the limit | You wait | Hand off to another vendor's agent |
Claude Code's own orchestration is "much better than Codex's," and it has an agent view. Orca's edge is pulling everything together across tools:
"Even if my features were exactly the same as Claude Code's, not everyone uses Claude Code."
On why Anthropic and OpenAI don't build this themselves, the founder gives two reasons. First, they work in different conditions:
"The Claude Code and Codex teams have unlimited tokens. They would never think about how to manage different subscriptions, like which one is about to run out."
Second, the incentives don't line up: "Their incentive is to get everyone locked into their own tool."
Compared with OpenCode and Pi
OpenCode and Pi also present themselves as open, but only the model choice is open:
"OpenCode is open in that you can plug in all kinds of models. But how the loop runs and how you interact with the agent isn't open. You have to use the harness it gives you."
With Pi you can call Anthropic's models, but you can't use Claude Code as the harness. Orca doesn't make users pick:
"Whatever Claude Code has, we have. Whatever Codex has, we have. And we have things they don't."
Why it took off so fast
1. It doesn't ask users to change their habits.
Positioning against Claude Code would mean spending heavily on marketing to change how people work. Orca chose to make the tools people already use work better:
"They don't need to change how they work to use you, and they're happy to share it with colleagues: I know we just bought Claude Code, but I'm not asking you to use a new tool. This makes Claude Code better to use."
That's also why Orca defaults to the terminal interface. The founder's reasoning is that Claude Code and Codex CLI users "far outnumber" their desktop app users, and running the official terminal interface means new features show up in Orca the day they ship.
2. It ships fast.
"There's a stable release every day, and each stable release has basically hundreds of PRs."
Because updates don't wipe sessions, most users are willing to update daily and always have the latest features. The team are heavy users of their own product, and even the release process is run by an agent that checks in every hour.
3. High retention, so users recommend it.
The founder says getting traffic isn't hard for tool products, since people like trying new tools. What the team watches is retention:
"They've basically tried every tool… whatever order they tried them in, they end up choosing Orca."
High retention is what makes one user pass it on to the next.
4. Leverage marketing: turning big-vendor launches into Orca content.
Similar products tend to treat Claude Code and Codex as rivals. Orca does the opposite:
"When Claude Code ships a new feature, we like it, then say here's how you can use it in Orca. Same when Codex ships something."
The founder says the team spends 95% of its time on product, and these posts take "maybe five minutes each" but usually get a few hundred likes, because people already want to learn new Claude Code and Codex tricks.
5. Timing and platform traffic.
Orca arrived just as individuals and companies were looking for ways to manage agents. The team also deliberately coined a new term:
"We were the only ones labelling ourselves as an ADE at the time… I said forget it, we're going to make up a new word, ADE."
More and more people now search for ADE and "agentic development", and a large share of Orca's traffic comes from GitHub search.
If you also work on several projects at once, switch between features all the time, and want to protect your attention for the decisions that matter most, I sincerely recommend Orca. See you next time.