What happened
Delta’s documentation describes a Cloud Runner as a Linux sandbox that runs an agent’s turns for a thread on the user’s behalf. A user selects Cloud from the runner control in the composer, then sends a message; the runner starts and the transcript displays progress. Users can also switch back to Local Machine. The choice applies to that user’s own turns, not other participants’ turns. Each participant who chooses Cloud gets a distinct runner using their own settings. Delta says this lets the agent keep working while the user’s laptop sleeps and supports starting command-running turns from Delta on the web.
Cloud Runners run on Zed-hosted infrastructure as Debian Bookworm on Linux x86-64. The desktop app offers three sizes: Small has 2 CPUs, 4 GB of RAM and 15 GB of free disk; Medium, the default, has 4 CPUs, 8 GB and 30 GB; Large has 8 CPUs, 16 GB and 50 GB. A size change applies to runners started afterward, while an existing thread keeps its current size. Delta says Cloud Runner compute is free until Delta plans roll out, subject to fair-use limits. When an allowance expires, a running runner pauses and the user cannot start another one. Up to six Cloud Runners can run at once, and the feature is unavailable on Student plans. Model usage is separate and billed by the provider as it is for a local turn.
The documentation describes a repository-level setup path. A project can commit an executable .agents/setup script, which runs from the checkout root before the first turn. Delta snapshots runner machines after setup so later runners can start faster. If .agents/prepare is present, it runs in each checkout before setup. Users can add environment variables and secrets in Cloud Runner settings; Delta says these are stored in encrypted account settings and redacted from transcript and terminal output. Connected model providers and remote MCP servers are available to a runner.
The cloud checkout is based on the thread and Delta worktrees synced to Delta’s servers, not the user’s local checkout. Delta says the runner cannot access items that exist only on the computer, such as ignored files, linked files, local services or credentials. Changes sync back through the Delta worktree for review and syncing. Terminals, including background commands, close after one hour; Cloud Runners pause after 10 minutes of inactivity and resume when another turn is run. Preview URLs are not public: visitors must sign in to Delta and have access to the thread. Cloud Runners are typically created when a thread is created on or moved to Cloud and deleted when it is archived; deleting a thread also deletes its runner.
What the archive adds
New Runtime’s earlier coverage described Vercel Run as a resumable sandbox session with approval gates, and separately covered managed sandbox execution for Cursor Cloud Agents. Delta’s documentation adds a concrete runner model inside a threaded coding-agent workflow, including per-participant runners, setup scripts and limits. This is a new product event within the broader thread of managed agent execution. No archive link is included here because the earlier coverage is represented only by unlinked context.
Trend signal
This supports the shift toward a coding-agent workbench that includes persistent, managed execution environments, rather than treating the agent as only a local chat interface. The relevant assumption is that persistent runtimes can be used safely by non-experts; Delta documents controls and boundaries, but does not demonstrate safety outcomes. This does not yet fit a pattern New Runtime tracks.
Why now
Delta’s documentation frames Cloud Runners around a practical constraint: local execution depends on the user’s computer, while cloud execution lets an agent continue when that computer sleeps. The page also details setup and preview workflows, suggesting the runner is intended for ongoing project work rather than a one-off remote command. The source does not state a launch date or explain a broader market timing rationale.
Why it matters
The key engineering choice is not simply local versus cloud; it is which project state and credentials the agent needs, and what should remain inaccessible. Cloud execution can keep an agent turn moving without keeping a laptop awake, but the runner operates on the server-synced thread and worktree. Local-only services, ignored files and credentials must be made available through supported setup or configuration paths, or the task will behave differently than it does on a developer’s machine.
The one-hour terminal cap and fair-use allowance also matter for long-running tests, development servers and agent loops. Teams should not equate “keeps running while my computer sleeps” with unlimited runtime. They need to decide which tasks can pause, how to recover from an expired allowance, and whether a Personal Runner is more appropriate when the execution must use a managed computer’s local checkout and tools. Preview access is tied to thread access, so collaboration settings become part of the security boundary. These are operational constraints to test before moving routine development work into the cloud.
Limits and uncertainty
Delta’s documentation does not quantify fair-use allowances, the amount of runner time included, or the price after Delta plans roll out. It also does not report startup latency, reliability, performance against local execution, or how often runners are reprovisioned. The documented six-runner concurrency cap and one-hour terminal limit are concrete, but the page does not establish how these constraints behave across larger teams or prolonged workloads. The described access controls and secret redaction are company statements, not an independent security assessment. Teams should validate their own repository setup, integrations and permissions before relying on unattended execution.
Reader takeaway
Cloud Runners make Delta agent turns independent of an awake laptop, but not independent of the thread’s synced state, access rules or runtime allowances. Treat the feature as a managed execution environment to configure and test: prepare the repository, place necessary secrets in the supported settings, and confirm that your task can tolerate terminal timeouts and fair-use pauses.