ADE Workspace Showdown: ADE vs Superset vs Herdr vs Orca

🌏 中文版

The previous post framed Omnigent as a control plane above harnesses — unifying access, governance and cross-device Sessions. This one stays on the workspace layer. Four projects that all call themselves an ADE — arul28/ADE, superset-sh/superset, herdrdev/herdr and Kadro ADE/Orca — solve the same local problem (run many agents in the same repo in parallel, keep them visible, merge cleanly), but with very different abstractions. Pick the right workspace and you won't need to fight worktree conflicts with Policies.

Why ADE deserves its own category: workspace vs control plane

Borrowing the four-layer split from the previous post, a control plane solves "you ↔ a fleet of harnesses", a workspace solves "you ↔ a fleet of worktrees + agent processes in the same repo".

• Omnigent: Runner + Server + Omnibox + Policy, value in portability, governance and collaboration across harnesses.
• ADE family: Brain/daemon + Lane/worktree + PR/diff + sync, value in parallelism, visibility and mergeability of the local dev loop.

Simple boundary: if you need to swap Claude/Codex across vendors in one shareable Session with auditable cost and credential brokering, reach for the Omnigent control plane. If you just need several Claude Code / Codex / OpenCode sessions working in the same repo at once, each on its own branch with isolated ports, a workspace gets you there faster.

arul28/ADE: the canonical Brain + Lane

arul28/ADE (ade-app.dev) is the clearest statement of what a "workspace" means. It is local-first with an always-on Brain: the Brain is a per-machine daemon that owns the project catalog, the sync websocket, and the authority to actually execute things. Four clients attach to it — Desktop (Electron), Web, Terminal (ade code), and iOS — plus the same ade CLI.

The unit of work is a Lane, ADE's name for a git worktree: one isolated branch and working copy per task, each with its own files, chat/terminal sessions, process pool, diff and PR. Three commands tell the story:

curl -fsSL https://ade-app.dev/install.sh | sh  # install Brain, optionally Desktop
ade lanes create --name fix-checkout-flow        # one Lane = one worktree
ade lanes list --text

Lanes support stacking: branch from main or from another Lane to form child lanes (dependency chains), import an existing branch, or attach an external git worktree. Sync is LAN → Tailscale → relay, with the account only for discovery — LAN/SSH pairing works without one. Best as the first stop once you need 3-5 agents in parallel but haven't decided on a control plane yet.

Limits: Linux gets Brain only (no desktop app); the richest experience is macOS. Compared with control planes, there is no Policy engine / spend kernel / credential proxy — governance comes from Lane isolation and approval gates.

superset-sh/superset: an IDE for 100 agents

Superset (superset.sh, docs.superset.sh) turns the workspace into a full agentic IDE. The pitch is "Run 100+ coding agents in parallel", each task again an isolated git worktree with its own terminal, but the workspace itself is the IDE: built-in terminals, diff viewer, in-app browser, automations, and one-click handoff to Cursor / VS Code.

Three differences from ADE:

1. Scale narrative: stable at 5-7 parallel agents today, aiming for 100 by end of 2026 (roadmap).
2. Many surfaces: Desktop plus superset CLI, TypeScript SDK (@superset_sh/sdk), and an MCP server so other agents can drive the workspace.
3. License: source-available under Elastic License 2.0, not OSI open source.

Coverage is broad: Claude Code, Codex, Cursor Agent, Pi, OpenCode, Grok and any CLI agent that runs a command. Good fit when you want parallel review and automations as IDE features.

herdrdev/herdr: a single Rust binary as runtime

Herdr (herdr.dev, ~32k stars, Apache 2.0) calls itself the runtime your coding agents live on. No IDE, no Electron — just one Rust binary: a background server that owns every terminal. Clients are whatever terminal you already use, attached via the herdr CLI or herdr --remote over SSH.

Philosophy in contrast: ADE and Superset make the workspace thick, Herdr makes the runtime durable.

• Always running: terminals live inside the server; close the lid, drop the network, even reboot — agents keep running and the layout comes back.
• Blocked / working / idle: reads every pane (plus optional integrations) and marks the one agent stuck waiting for you, so you don't poll pane by pane.
• Agent-native API: CLI + socket API that agents can drive — spawn panes, prompt each other, wait until blocked instead of blind keystrokes.

Herdr doesn't wrap your agent CLIs — Claude Code, Codex, Cursor, OpenCode keep running as before, just with their terminals owned by a persistent multiplexer. Ideal if you already live in a terminal/tmux world and want "a multiplexer that never dies + agent state".

Kadro ADE and Orca: pane and Fleet extensions

Kadro ADE (kadrotools.ai) bets on panes: a workspace is a color-coded tab holding a grid of up to 16 panes, each a real terminal (xterm.js + WebGL, Tauri 2 + React 19). 20+ launchers, everything behind ⌘K. Worktrees are optional; workspace/pane is the protagonist. Suited to IDE users who want a visual tiling of many agents.

Orca (onorca.dev, YC-backed) extends to Fleet: still one isolated worktree per task, but natively wired to GitHub and Linear — browse PRs/issues in-app, open a worktree from any task, review PRs, with desktop + mobile + VPS coverage and "any CLI agent" support. Best when Linear/GitHub is already your task source and you want the workspace tightly coupled to collaboration.

Both sit at the same ADE layer as ADE/Herdr/Superset; choice comes down to whether you value "pane control" or "task → worktree wiring" more.

Side-by-side

Underneath, all four are git worktree isolation — commit / push / PR semantics don't change. The workspace just glues worktrees, terminals and review together and handles port/env conflicts.

When to pick a workspace vs a control plane

Two questions form the decision tree:

1. Does governance need to be centralized across harnesses? If you need one-line Claude/Codex swapping, cross-vendor reviewer routing, and auditable cost/credential brokering — pick an Omnigent-style control plane. If you just need several agents in the same repo at once, a workspace is enough.
2. Is the collaboration unit a "shareable live Session" or a "mergeable PR"? The former (share a Session URL, teammates watch/comment/take over) is the control plane's strength; the latter (each Lane opens its own PR, review and merge inside the workspace) is the workspace's strength.

Our recommended stacking: validate the parallel dev rhythm with ADE or Herdr first, then promote proven Lane patterns onto a shared host via Omnigent's Runner, letting Policy and cross-device Sessions take over. Superset's and Orca's SDK/MCP surfaces are natural bridges for a control plane driving a workspace.

Overall

The division is settling: control planes govern "how a fleet of harnesses is swapped and governed", workspaces handle "how many worktrees and agents run in parallel inside one repo and get merged". If you're still in the single-machine, single-repo exploration phase, pick a workspace, cut work by Lane/Workspace, and wire mobile or remote sync. When the pain shifts to "cost and permissions must be audited outside prompts", fold the workspace into Omnigent's unified Session and Policy.

Next in the series: persistent design for background agents and session collaboration (order 6).

References

• arul28/ADE · ADE Docs — ade-app.dev · Lanes overview · Quickstart
• superset-sh/superset · Superset · Superset Docs · Roadmap to 100 Agents
• herdrdev/herdr · herdr.dev · Herdr Docs: Concepts · Supported Agents
• Kadro ADE · Kadro Docs: Workspaces & Panes
• stablyai/orca · onorca.dev
• omnigent-ai/omnigent · Omnibox / Shared Server docs
• What Is a Meta-Harness? A 2026 Buyer's Guide — codepick.dev