Orca ADE vs Cloud agent orchestrator

Orca ADE vs Cloud agent orchestrator

One-liner

Orca (onorca.dev) is an MIT-licensed agent development environment (ADE) — a desktop/mobile IDE that fans out BYO CLI agents (Claude Code, Codex, Pi, …) into one git worktree each, with terminals, diffs, browser, and an orca CLI. It is a human-in-the-loop multi-agent workspace, not a proved run state machine or durable project control plane. Overlap with Cloud agent orchestrator is worktree+PR parallelism; the gap is Bend policy, SQLite event ledger, hermetic flake PATH, and OpenAPI/MCP core.

Related: Cloud agent orchestrator · 2026-09-28 Worktree and PR by design orchestrators · 2026-09-28 Persistent project coordinator model · 2026-09-28 Pi SDK sessions worktrees and TS coordinator

Primary sources (checked 2026-09-28): Product · Docs: What is Orca? · Ways to run · Agents & sessions · Worktrees · CLI overview · Skills & MCP · Enterprise · GitHub stablyai/orca

---

1. What it is / who it’s for

Claim: “Ship 100x with the agent IDE” / ADE built for you and your agents — worktrees, terminals, browser, CLI in one app (landing).

Product: Desktop app (macOS / Windows / Linux) plus mobile companion (iOS / Android). Orchestrates agents you already pay for; Orca is not a model and does not proxy prompts through their cloud (docs).

Audience: Engineers who already write code, read diffs, and keep worktrees tidy — leverage AI, not no-code. Explicit non-goals: not a git replacement; not a hosted VPS product (docs).

Builder: Stably / stablyai; repo copyright notes also mention Lovecast Inc. in secondary write-ups. Ships frequently; changelog = GitHub releases.

---

2. Architecture / model

Human (desktop / mobile / browser client)
        │
        ▼
Orca runtime (local app or `orca serve` / Remote Orca Server)
  worktrees · terminals · browser · editor · agent dashboard
        │
        ├─ spawn CLI agent in worktree (BYO: Claude, Codex, Pi, …)
        ├─ optional SSH host or per-workspace Cloud VM (`orca.yaml`)
        └─ `orca` CLI + skills so agents can drive Orca itself

Concept	Orca model
Unit of isolation	Real git worktree (+ branch); shared dirs via orca.yaml / .worktreeinclude (worktrees)
Agent session	One CLI process in one terminal in one worktree; lifecycle via OSC titles / hooks (working → idle → exit → Restart) (agents & sessions)
Sandbox philosophy	Worktree = sandbox; default launch flags skip per-tool approvals (--dangerously-skip-permissions, Codex bypass, Gemini --yolo, …)
IDE vs orchestrator	ADE / IDE first — review diffs, design mode (Chromium), GitHub/Linear in-app, annotate AI diffs back to agent. Orchestration = fan-out + dashboard + CLI automations, not a formal SM
Compute	Local · SSH worktrees · Remote Orca Server (orca serve) · BYO Cloud VM recipes (ways to run)
State / proof	No proved state machine. Durability = git + PR + workspace UI state on the Orca host. Enterprise copy cites git/PR as audit trail (enterprise) — not an append-only orchestration ledger
Agent → env	orca CLI (worktree, terminal, browser snapshot/click/fill, automations, Linear helpers) + hybrid skills (npx skills add …) (CLI, skills)
MCP	Register MCP servers under Settings → Integrations; tools appear inside compatible agent CLIs — Orca hosts MCP for agents, it is not itself an OpenAPI/MCP control-plane API for a separate coordinator (skills page)

Supported agents: large BYO list including Pi / oh-my-pi (README).

---

3. Overlap and gaps vs Cloud agent orchestrator

Coordy product locks (from Cloud agent orchestrator): Bend-proved run SM · TS executor · worktree+PR Pi runs · SQLite event ledger · CLI/OpenAPI/MCP surface · hermetic flake devShell / spawnHook PATH.

Dimension	Orca ADE	Cloud agent orchestrator (coordy)
Primary artifact	Desktop ADE + mobile	Small Hono core + panels/MCP consumers
Worktree + branch	First-class; parallel agents	First-class run contract
PR as integrate gate	Native GitHub review UX; Enterprise: “every change lands in worktree and PR”	Mandatory in run contract (gh / API)
Worker agent	Any CLI (multi-harness)	Pi session per run (cwd = worktree)
Coordinator	Human + optional agent-driven orca / automations	Persisted BYO MCP PM/lead pattern
Policy / legality	Soft conventions + UI	Bend LAWS/PROOF; illegal transitions unrepresentable
History	Git + workspace activity	SQLite append-only transitions + effect receipts + projections
Env hermeticity	Host PATH / SSH host / orca.yaml Cloud VM recipes	Nix flake devShell; Pi bash PATH from nix print-dev-env
API surface	orca CLI to running IDE; skills stubs	OpenAPI + MCP + SSE + CLI as product exports
Proof / formal	None public	Bend2 in flake; optional Lean later
UI	Rich ADE (editor, browser, design mode)	Panels as consumers; UI not the control plane

Overlap (peer territory): parallel worktrees, PR-shaped shipping, remote always-on runtime, agents driving the environment via CLI/skills, BYO model spend.

Gaps (why it’s not a drop-in): no Bend-equivalent legality layer; no durable orchestration event log separate from git; no flake-first hermetic worker env; multi-CLI ADE vs single Pi worker contract; product is IDE-shaped, not “core stays small, panels swap.”

---

4. Pricing / open source / self-host

Item	Public status (2026-09-28)
License	MIT (repo LICENSE, README)
Desktop / CLI	Free download (dmg / exe / AppImage; Homebrew / AUR)
Model cost	BYO Claude / Codex / etc. subscriptions — Orca not in the middle
Self-host	Yes: local app, Remote Orca Server, orca serve, SSH, BYO Cloud VM providers
Enterprise	onorca.dev/enterprise — SOC 2 readiness messaging, contact sales; no published seat price
Telemetry	Anonymous usage by default; opt-out documented

---

5. Steal vs deliberately not copy

Worth stealing (or studying)

1. Worktree as the sandbox + default full-autonomy agent flags — matches our “isolation = worktree, not approval spam” instinct; document the security tradeoff.
2. orca CLI as agent-facing control surface (worktree create, terminal wait-for-idle, browser snapshot loop) — analogous to exposing MCP/CLI so a coordinator agent drives the plane without owning git internals.
3. Hybrid skills (thin stub → orca skills get version-matched guide) — keep skill text from drifting from the binary; relevant to pstack / domestic Skills packs.
4. Remote Orca Server / orca serve — always-on host so laptop sleep ≠ kill runs; compare to our durable coordinator + worker host story.
5. orca.yaml environment recipes (create/suspend/destroy) — peer to flake-backed envs, but recipe/script based; useful contrast when arguing why Nix stays the lock for coordy.
6. Dual delivery UX for review (annotate diffs → agent; design mode) — panel inspiration, not core policy.

Deliberately not copy

1. ADE-as-product — we stay control-plane + thin consumers; don’t absorb Monaco/Chromium/mobile into packages/core.
2. Multi-harness free-for-all as the default worker — Pi + flake PATH is the v0 contract; BYO CLIs can stay panel/MCP-side experiments.
3. OSC-title session state as policy — fine for UI; not a substitute for Bend transitions + SQLite receipts.
4. Skip-permissions by default without a proved drop-on-fail SM — Orca trusts the worktree; we want illegal lifecycles unrepresentable before I/O.
5. Git history as the only audit trail — keep append-only orchestration events; git/PR remain effect evidence, not the SM.

---

Bottom line for Coordy

Treat Orca as a strong ADE peer and UX reference for worktree fleets, not as the architecture to clone. Fold crumbs that sharpen CLI/MCP agent-drives-plane, always-on remote runtime, and worktree sandbox messaging; keep Bend + ledger + flake as the differentiators vs “another parallel-agent IDE.”