Move the Work Without Moving the Responsibility
Orca’s run modes decide where a worktree, agent, credentials, and runtime state live. This chapter compares local desktop work, SSH targets, a peer Remote Orca Server, and recipe-defined per-workspace environments so you can choose a boundary by scenario rather than by convenience alone. The key judgment is simple but easy to lose: moving the interface does not move responsibility away from the host that owns execution.
Four places an Orca workspace can run
Local mode is the least surprising arrangement. The desktop application, Git checkout, agent process, terminal daemon, browser, and review surface are on the same machine. It is the natural choice for short tasks, fast iteration, and repositories whose dependencies already fit the laptop. A normal application close can detach the interface from local PTYs while the terminal daemon keeps them alive, but the host still determines whether those processes survive a reboot, a hard shutdown, or a service boundary.
An SSH target changes only part of the arrangement. The Orca interface remains on the laptop, while Git, files, setup hooks, terminals, and agent CLIs for the selected worktree run on the SSH host. This is useful when the remote machine has more memory, a GPU, faster builds, or an always-on environment that the laptop should not have to maintain. The remote host must already have the repository or be able to receive it, the required tools, and the credentials used by the agent. A login on the laptop does not automatically become a login on the remote machine.
A Remote Orca Server moves more than the worktree. The remote machine runs the Orca runtime and owns projects, worktrees, terminal sessions, provider accounts, and agent state. The laptop, a browser client, a phone, or automation becomes a client of that runtime. This is the better fit when work should continue while a laptop sleeps, when several devices need to see the same sessions, or when a stable host should accept automation. The server is not merely a faster SSH target; it is the peer that owns the control plane.
A per-workspace environment is the most disposable shape. A recipe can create a sandbox, virtual machine, container, or other provider-backed environment for one workspace and later suspend, resume, or destroy it. Orca supplies the lifecycle and connection contract; the user supplies the provider, image, account, scripts, and billing. The current recipe doctor treats recipe execution as local in version one, while the recipe result can connect the created environment through an Orca-server pairing or SSH details. That distinction matters: a recipe-defined cloud resource is not an Orca-hosted VPS, and “disposable” depends on the destroy path actually working.
These modes overlap in purpose but not in ownership. Local mode minimizes network and authority boundaries. SSH gives the laptop’s Orca runtime control over a remote execution host. A Remote Orca Server gives the remote machine control of the full runtime and supports multiple clients. A per-workspace environment prioritizes clean, repeatable task boundaries at the cost of provisioning and lifecycle complexity. None is universally best.
A small UI bug may favor local mode because the feedback loop is short and the repository is already prepared.