Choosing where to run work
- Approved by
- Panaversity ·
7 min read
Match the job to the runtime
Each way of running Claude decides two things: what kind of machine the work runs on, and what survives afterward.
| If you need | Use | Where it runs | What survives |
|---|---|---|---|
| Research, code or files, now, working back and forth with Claude | A Claude chat (a cloud session in the chat examined, not confirmed for every chat) | A cloud sandbox for the session. In the session examined, a Firecracker microVM | The conversation and saved files. The VM's state lasts until the VM is reclaimed or the session ends |
| Work on files on your own computer | A chat linked to your computer, or Claude Code on your machine | A cloud sandbox plus a bridge to the folders you connect. Or your own machine | Your files |
| Recurring work while your computer is off | A cloud scheduled task | A new cloud session for each run, with a fresh copy of the repository and a cached setup script | Only external state |
| A stream of related tasks that outlasts one session | A Claude project (beta, Pro and Max) | Each task in its own thread, usually a new cloud session with its own sandbox. A coordinator session routes the work | Project memory, instructions, the Library and pushed branches. Uncommitted sandbox changes can be lost |
| Recurring work on local files | A Desktop scheduled task | Your machine, while the app is open and the computer is awake | Your local folder |
| Repeating a check during a session | /loop | Inside the open session | The session's state |
| Cloud sessions that must reach internal systems, or keep code on your own machines | A self-hosted environment (beta, Team and Enterprise) | Your runners, inside your network. Anthropic still runs the control plane and receives the conversation | Checkouts, artifacts and files on your hosts. Anthropic stores the transcript |
| Team work handed to Claude in Slack | Claude Tag (beta, Team and Enterprise) | A sandbox for each Slack thread, in an organization-level environment | The thread, pushed branches and posted results. Files only in the sandbox are lost when the thread goes quiet |
| A bot, service or database that runs 24 hours a day, 7 days a week | Your own server or a managed service. Claude Code can work on it over SSH | That server | The data that is stored durably, according to the service's design for storage and backups |
The last row follows from the overview: no VM stays on for you. Work that never stops needs a service you or a provider runs.
For the project row, see Projects: coordination on top of sessions.1 For the self-hosted row, see Cloud environments and self-hosted runners.2 For the Claude Tag row, see Claude Tag.3
Five habits, whichever you choose
- Save anything that matters outside the VM: in an artifact, a repository, Drive or a connected app.
- Expect a fresh VM after an idle gap. Have your scripts install what they need. For cloud scheduled tasks, put the installs in the environment's setup script, whose result is cached.
- Write scheduled prompts as complete, standalone instructions. The page on scheduled tasks explains why.
- Keep long-lived secrets out of the sandbox. Reach services through connectors, or use a narrow network secret. A key that can do something serious, such as paying, belongs in a connector with its own check.
- Enforce approval for consequential actions in the service that performs them. Consequential actions are ones with real effects, such as payments, sends and deletes. An approval prompt in Claude is an extra layer. It is not the safeguard.
The fifth habit is the same rule as in What stays your responsibility: permissions over words. The worked example shows it in a real design.
Check yourself
Question 1 / 3
0 answered
You need a bot that runs 24 hours a day. What should you use?
Sources
- Owner
- Panaversity