AgentSDEDocs
Open console

Runtime

Runtime is where your agents actually do their work · read the code, run the tools, open the pull request. AgentSDE gives you two places for that to happen: our managed cloud, or a machine you control. The choice applies to every agent in the workspace, and it is the difference between “AgentSDE runs this for you” and “this runs on hardware you own.”

5 min readUpdated 2026-08-12 · Priya NEdit this page

#The two runtimes

You pick one runtime for the whole workspace, in Settings → Runtime.

  • AgentSDE Cloud · phases run on AgentSDE’s managed servers. There is nothing to install and nothing to keep online · you connect your repositories and AgentSDE does the rest. This is the recommended default, and for most teams it is the only setting they ever touch.
  • Your own machine · phases run on a device you control, reached through the AgentSDE Connect daemon. Your code, your credentials, and the model calls stay on that machine · AgentSDE orchestrates the run but never holds the working copy.
Settings → Runtime in the console: two large radio cards (AgentSDE Cloud, marked Recommended, and Your own machine) above a Device section showing one connected device and the no-device-online fallback.
Settings → Runtime · choose where agents run, then manage the paired device below.

#What the Connect daemon is

The Connect daemon is a small program you install on your own machine · a laptop, a build box, a server. Once it is signed in to your workspace it behaves like a self-hosted runner: it sits idle waiting for work, and when AgentSDE has a phase to run it hands the phase to the daemon instead of running it in the cloud. The daemon clones the repo locally, runs the phase there, and reports logs, artifacts and token usage back.

Because the daemon runs where you put it, everything a phase touches · the checkout, the shell, the toolchain, the network · is your machine’s, not AgentSDE’s. You pair a machine once at /connect; after that it just needs to be online.

#What local-claude means

On your own machine, phases are executed by local-claude · the daemon invokes your Claude on your hardware rather than AgentSDE calling a model for you. It is the same self-hosted-runner idea applied to the model itself: the agent’s reasoning runs under your credentials, on your box, inside your network. Nothing about the run leaves the machine except the results you would see anyway.

Same agents, different address

Switching runtimes does not change your phases, prompts or triggers · only where they run. An agent behaves the same on cloud or on your own machine; the difference is whose hardware and credentials it uses.

#Which one to pick

PickWhen
AgentSDE CloudYou want zero setup, no machine to keep online, and you are comfortable with runs happening on AgentSDE’s managed servers. This is the right default.
Your own machineYour code or credentials must not leave your environment, you need a specific local toolchain, or policy requires runs on hardware you control.

The honest trade is availability versus control. Cloud is always there; your own machine is only there when the daemon is running and online. That gap is exactly what the fallback below is for.

#When no device is online

Your own machine can be offline · the daemon isn’t running, the laptop is asleep, or its access has lapsed. Because a run can arrive at any moment, you tell AgentSDE ahead of time what to do when it has work but no device to give it. There is a single no-device-online fallback, with two settings:

  • Fall back to AgentSDE Cloud · if no device is online, the work runs in the cloud instead of waiting. Nothing stalls · this is the recommended choice.
  • Require my machine · pause · the work waits instead of running in the cloud. It starts the moment a device connects with valid access.

The fallback applies whenever the device is offline, lapsed, or busy · it is the rule that decides whether “no machine right now” means “use the cloud” or “hold the work.” It only appears when you have chosen Your own machine, since cloud has nothing to fall back to.

Choose runtimeCloud or your machine
Device online?Daemon reachable
No deviceCloud, or pause
Run executesWhere it landed
How a run is placed · on your machine when the daemon is online, otherwise the fallback decides.

#The device list is read-only

The Runtime page shows the device paired to this workspace · its host, Connect version, and whether it is online, idle, offline or lapsed. That list is read-only here. You cannot add a device on this page · pairing happens at /connect, where you install the daemon, sign it in, and approve the code it prints. See Devices and API keys for the full pairing flow.

What Runtime does let you do with a device is revoke it · signing that machine out immediately. The device’s grant (what it may do on your behalf) is fixed when it was authorized and shown read-only, for the same reason integration scopes are read-only: nothing in that list is a setting you turn up.

One device per workspace

A workspace pairs a single device · there is no fleet to manage here. To move work to a different machine, revoke the current one first, then pair the new one at /connect.

#Saving a change

Changing the runtime affects every agent in the workspace, so a save always goes through a confirmation dialog · it shows exactly what is changing (for example, cloud → your own machine, and the fallback), and if you have chosen to pause with no device currently online, it warns that new work will wait. Runs already in progress are never moved · they finish on the runtime they started on. The change takes effect for the next run once you confirm.