UX 개발 / ADE

Choosing an ADE: Cursor, Orca, Zed, and Today's Agent Workspaces

ADECursorOrcaZedVS CodeDevinAntigravityCodex

An agent command center connected to a laptop, an always-on server, and a cloud worker

An Agent Development Environment helps you direct coding agents, inspect their work, and manage several tasks. When you want a task to continue after closing your laptop, the decisive question is which machine owns the running agent.

This guide checks official sources on 2026-10-27. It introduces major editor ecosystems and newer agent workspaces; it is a practical shortlist rather than a measured popularity ranking. Features and availability depend on version, plan, operating system, and agent integration. The comparisons are documentation-based, not an end-to-end sleep or crash benchmark of every product.

1. What is an ADE?

Here, ADE means Agent Development Environment: a workspace for assigning work to agents, separating changes, watching progress, and reviewing results. The term describes a workflow rather than a universally standardized product category.

An editor helps you change code directly. An agent CLI can read files, run tools, and propose or implement changes. An ADE adds the coordination around that work: task lists, parallel sessions, Git worktrees, previews, diffs, and sometimes remote execution. Current products combine these layers in different ways.

Keep three parts separate:

PartWhat it doesA useful question
InterfaceEditor, desktop command center, browser, or phoneWhere do I assign work and review changes?
Agent runtimeRuns the loop and invokes shell commands and toolsWhich machine must stay awake?
Model serviceProduces the model’s responsesWhich account pays for inference?

A model being in the cloud does not mean your repository, test process, and agent loop are also running there.

2. Seven options worth understanding

EnvironmentIts main appealExecution choice to inspect
CursorAn agent-focused editor with managed cloud executionLocal Agent, Cloud Agent, or persistent CLI
OrcaSeveral agent CLIs, worktrees, terminals, and reviews in one workspaceLocal, SSH worktree, or Remote Orca Server
ZedA native editor with integrated and external agentsZed Agent, ACP integration, or terminal thread
VS Code with GitHub CopilotExisting editor tooling plus multiple agent session targetsLocal, Agent Host, remote host, or GitHub Cloud
Devin DesktopAn editor and command center for local and cloud agentsLocal agent versus a Devin cloud VM
Google AntigravityAgent-oriented app, editor, CLI, and review artifactsDesktop execution versus a headless remote-control host
Codex in ChatGPTCoding chats with local, worktree, and cloud environmentsThis computer versus a published cloud environment

Two naming changes matter. Windsurf is now Devin Desktop, according to its current official site. Antigravity’s documentation now covers a standalone app and CLI alongside editor surfaces. A comparison based on older editor-only screenshots can miss those choices. (Devin Desktop FAQ, Antigravity overview)

3. Persistence has four different meanings

What survives?What that actually tells you
Conversation historyYou can reopen the messages later
A running processThe agent or command continues while the interface disconnects
Remote accessAnother client can view or control the host’s session
A host restartThe application can restore or resume work after processes have stopped

These are different capabilities. A saved transcript does not keep a test running. Remote control does not keep a sleeping host awake. A service restarting after reboot does not preserve the exact in-flight shell process.

For unattended work, use either a managed cloud worker or a separately powered host with the appropriate runtime. A Mac mini or VPS can be that host. The laptop becomes a client.

4. Cursor: choose between cloud delegation and persistent CLI work

Cursor is a good starting point when you want to edit interactively and also hand off well-scoped tasks. Its Cloud Agents run in isolated cloud VMs with repositories, dependencies, tools, and environment setup. The official guide says your local machine does not need to remain connected. Configure repository access and the environment first, then review the resulting changes and pull requests. (Cloud Agents)

This is useful for a task such as updating documentation or adding tests while you work elsewhere. A normal local Agent conversation should not be assumed to have moved into a cloud VM just because you use the same Cursor account.

Cursor also documents persistent CLI sessions, introduced in its 2026-08-26 CLI release. On the computer that should execute the work, after following the CLI installation guide:

agent --version
agent persist --help
agent persist

Inside the persistent session:

/detach

After reconnecting to that same host:

agent persist list
agent persist attach

Cursor's official release note describing persistent CLI sessions, detach, attach, list, and stop

Cursor’s public CLI changelog documents this command family. (Source: CLI changelog, captured 2026-10-27)

Select any documentation image in this guide to open it at full size.

Run this on an always-on remote host if your laptop will sleep. Running agent persist on the laptop keeps the execution dependent on that laptop. The older local CLI checked for this article was 2026.01.23-916f423 and did not expose persist; use the official updater when your installed build lacks it. These commands were checked against current documentation, not exercised as paid agent jobs. (Persistent-session release)

5. Orca: manage agents on a host you control

This guide means Orca from stablyai/orca, distributed at onOrca.dev, rather than another project with the same name. Orca organizes agent sessions, terminals, diffs, previews, and Git worktrees. It suits developers who already use tools such as Claude Code or Codex and want to manage several independent tasks together.

Its execution-mode guide distinguishes local work, SSH targets, Remote Orca Servers, and bring-your-own-cloud environments. A Remote Orca Server owns the runtime; an SSH worktree is a different arrangement. Do not treat every remote-looking tab as the same persistence guarantee.

For an always-on Mac mini or desktop, the simplest documented path is graphical:

  1. Install and update Orca on the server and client. Install the agent CLIs, repositories, and required credentials on the server.
  2. Put both machines on a private route, such as the same Tailscale tailnet.
  3. On the server, open Settings → Remote Orca Servers → New Link. Select its reachable private address and generate an access link.
  4. On the client, open Remote Orca Servers → Add Server and paste the link. Select the server or one of its projects before starting work.
  5. Keep the server awake and Orca running. The official guide explicitly says agents continue when the client laptop sleeps or disconnects.

Orca's official server-sharing dialog with a Tailscale connection address and redacted pairing link

Official Orca documentation image showing the server-side pairing controls; its example link is redacted. (Source: Remote Orca Servers, accessed 2026-10-27)

Remote Orca Servers are documented as beta. The pairing link grants access to the runtime, so keep it private. Use a private network or authenticated tunnel rather than forwarding the runtime port directly to the internet. (Server setup and boundaries)

The headless alternative

On a supported macOS/Linux server with Orca and its bundled CLI installed, a trial foreground server can be started with:

orca serve --port 6768 --pairing-address 100.64.1.20

Replace the example address with your server’s reachable private address. --pairing-address advertises how clients should connect; it does not create a VPN or configure access controls. Pair the client using the printed URL. This command remains in the foreground, so an ordinary SSH shell is not itself an unattended service.

After pairing, stop that trial server with Ctrl-C before switching to the service-managed path. On supported macOS/Linux installations:

orca serve service install --port 6768 --dry-run
orca serve service install --port 6768
orca serve service status

The first line previews the installation. Current documentation says the service uses a macOS LaunchAgent or Linux systemd user unit. Linux may need user lingering to survive logout; the installer reports that condition. The service commands are not currently available on Windows. Check the CLI reference and service instructions for your release. This article did not start or publish a real Orca server.

6. Zed: a capable editor with several agent integrations

Zed offers its own agent, external agents through ACP — Agent Client Protocol, parallel threads, and worktree isolation. Its current Agent Panel guide explicitly describes multiple simultaneous threads and notes that features such as history restoration vary by external-agent integration. (Parallel agents)

Choose it when fast, direct editing and reviewing agent changes inside the editor are central to your work. Its documentation supports more than the idea of a single disposable chat window.

For unattended execution, verify the exact native agent, ACP backend, or terminal process you use. The official pages checked here do not establish a universal guarantee about every integration surviving application exit. A restored thread and a still-running process are different things. If you need a CLI to survive disconnects, running it on an always-on host inside its supported persistent runtime or tmux is a separate, testable setup.

7. Four other environments to consider

VS Code with Copilot

VS Code’s current agent model includes local sessions, Copilot sessions in the Agent Host, remote sessions, and cloud work on GitHub infrastructure. Its session guide explicitly identifies Cloud as the asynchronous option that can produce a pull request while VS Code is closed. Choose it when your extensions, debugging tools, and team workflow already live in VS Code. A local background session still uses its execution machine.

VS Code's official Session Target picker for choosing where an agent session runs

Official VS Code documentation image illustrating explicit session-target selection. (Source: Agent sessions and where agents run, accessed 2026-10-27)

Devin Desktop, formerly Windsurf

Devin Desktop retains an editor and adds an Agent Command Center for local and cloud agents. Its documentation separates local editor agents from Devin sessions on their own cloud VMs; Cascade remains one local-agent option. Choose it when you want a task board and editor together, particularly for a workflow already using Windsurf or Devin. Check the selected execution mode before stepping away.

The public Devin Desktop demo groups agent tasks into Running, Waiting for review, and Done columns

Cognition’s public product-page demonstration of the agent board, captured as published. It is a product illustration rather than this author’s live project. (Source: Devin Desktop, captured 2026-10-27)

Google Antigravity

Antigravity now spans an app, editor interfaces, CLI, and SDK, with agent coordination and review artifacts such as plans and browser recordings. Its Remote Control guide distinguishes an interactive connection from a headless background daemon. Choose it when the Google agent ecosystem and those review workflows fit your projects. Remote control still depends on the execution host remaining on; it does not automatically relocate local files or commands into managed cloud compute.

Codex in ChatGPT

The current official environment guide describes Local, Worktree, and Cloud coding chats in the ChatGPT desktop app. Local and Worktree run on your computer; Cloud uses a published environment. Choose it for a Codex-centered coding workflow with those environment choices. Its remote-connection guide also distinguishes connected-host access from cloud work: a host going asleep or unavailable affects access to that host’s tools and files.

8. A first experiment that reveals the real differences

Use a disposable repository or a small branch, with one agent initially. Give every environment the same request: add one small test, run the focused test command, and summarize the diff. Keep credentials and dependency setup comparable.

Before the paid agent task, you can check terminal continuity with a harmless, 60-second timestamp command on the intended host:

python3 -u -c 'import time; [(print(time.strftime("%H:%M:%S"), flush=True), time.sleep(5)) for _ in range(12)]'

Disconnect only the client, then reconnect. Check whether output progressed during the gap. Next, repeat with one small agent task: a surviving terminal alone does not prove the full agent workflow continued.

Record whether the task was running, waiting for approval, paused by a usage limit, or finished. An agent waiting for an answer can be perfectly connected while making no progress. Test application quit separately from closing a chat tab. Test host restart separately again, using only disposable work.

For a plain CLI, tmux provides a simple reference workflow:

ssh devbox
tmux new -s ade-demo

Start the CLI inside that remote session. Detach with Ctrl-b, then d. After reconnecting to the same host:

tmux attach -t ade-demo

tmux preserves a terminal session on its host. It does not keep that host running through sleep or reboot, and it does not turn an editor’s native agent into a detached CLI session.

9. Choose the workflow, then check the total cost

Your main needA sensible first trial
Edit closely with one agentCursor, Zed, or your existing VS Code setup
Compare several agent CLIs and isolated changesOrca, or another environment’s worktree workflow
Close the laptop and review a PR laterExplicit cloud execution in Cursor, VS Code/Copilot, Devin, or Codex
Keep your own Mac mini or VPS as the workerOrca Remote Server, Cursor persistent CLI, or a supported remote/headless runtime
Coordinate Google agent workflows and artifactsAntigravity

Count the workspace app, model/agent usage, and execution-host costs separately. Adding a command center does not make the underlying agent calls free. Cloud tasks need their own dependencies, credentials, and reachable services. A worktree separates checkouts; use an appropriate sandbox or VM when you need an execution security boundary. For Claude-backed workflows, the subscription/API billing comparison explains why the active credential matters.

After each trial, review the actual diff and test evidence before merging. Compare useful work completed, recovery after a disconnect, review effort, and total spend. Start with one environment and one execution host you can explain clearly, then add parallelism when the workflow is reliable.

Related