Always-On Coding Agents: Where Should They Actually Live?
Updated September 12, 2026 · first published August 24, 2026 · by the AQ team
An always-on coding agent is one whose session survives you walking away: the laptop lid closing, the Wi-Fi changing, the workday ending. As of August 2026 there are three practical places to get that. You can fight your laptop's power management and keep the agent local, you can run the agent on a VM you control and let tmux hold the session, or you can hand tasks to a vendor's cloud sandbox (Claude Code on the web, Codex cloud, Cursor cloud agents, GitHub Copilot's cloud agent). They differ on the axis that matters most: whether you get a persistent machine you own, or a task that runs to completion on someone else's. This guide walks all three honestly.
Why a laptop is never really always-on
Agent CLIs like Claude Code and Codex are ordinary terminal processes. When the operating system sleeps, the process freezes mid-task and does not resume the work when the machine wakes. Every laptop is built to sleep: on battery, on idle, and (on Apple Silicon Macs) whenever the lid closes, regardless of what utilities like caffeinate promise. Even a laptop that stays awake is one OS update, one dead battery, or one hotel Wi-Fi handoff away from a dead session.
You can push the boundary. macOS caffeinate prevents idle sleep for a wrapped command, and Windows lets you set the lid-close action to "do nothing" while plugged in. That is genuinely enough for a two-hour run while you make dinner, and if that is your actual problem, keeping Claude Code running after closing your laptop covers every trick in detail (and the Codex version exists too). But a kept-awake laptop is a workaround, not an architecture: it still travels, reboots, and drops off the network with you. Always-on means the agent lives somewhere that does not.
Route 1: a VM you own
The reliable default is boring: a Linux VM in your own cloud account (or a spare machine at home), the agent CLIs installed and logged in, and tmux holding each session. tmux runs a server process on the machine; your SSH connection is just a client. When your connection drops or your laptop sleeps, the server and the agent inside it keep running, and you reattach from any device later.
# On the VM, once: install and log in to your agent CLIs
ssh dev-box
# Per task: a named session that outlives every disconnect
tmux new -s payments-refactor
claude # or codex, or any terminal agent
# Detach: Ctrl-b then d. Close the laptop. Hours later, from anywhere:
ssh dev-box
tmux attach -t payments-refactorWhat you get for that effort: sessions that survive your laptop entirely, any agent CLI you like (including several at once), full custody (the repository clone, GitHub tokens, and shell live on hardware in your own account), and access to anything inside your network. The costs are equally concrete. A VM able to run builds comfortably runs from a few dollars to some tens of dollars per month depending on size and provider, which is a rounding error next to what the agent's model usage costs. The real price is operational: you harden SSH, you script git worktrees so parallel tasks do not trample one checkout, and you remember that tmux sessions live in memory, so a reboot clears them unless you add systemd units or a resurrection plugin. The step-by-step path is in run Claude Code on a cloud VM, and self-hosted AI coding agents compares the broader landscape.
Route 2: a vendor cloud sandbox
Every major agent vendor now runs its agent for you, and these are genuinely good at what they are scoped for. All claims below are as of August 2026, from the vendors' own documentation.
Claude Code on the web (a research preview for Pro, Max, Team, and eligible Enterprise plans) runs sessions on Anthropic-managed isolated VMs. Sessions persist when you close the browser, you can monitor them from the mobile app, and you can pull a session down to your terminal later. The always-on caveat is explicit in the docs: sessions stop after a period of inactivity and the VM is reclaimed; reopening provisions a fresh VM with your conversation history restored. Usage also shares rate limits with the rest of your Claude account.
Codex cloud provisions an isolated container per task on OpenAI's infrastructure, checks out your repository, and runs your setup script. Agent-phase internet access is off by default, container caching makes follow-up tasks fast, and results arrive as pull requests. It is task-scoped by design: you delegate a unit of work, not a machine.
Cursor cloud agents run in isolated Ubuntu VMs on Cursor's cloud, each with a full desktop and browser the agent can drive to verify its own changes, and Cursor positions them for long tasks that take hours. An enterprise self-hosted option (announced March 2026) keeps the workers on your infrastructure while orchestration stays in Cursor's cloud.
GitHub Copilot's cloud agent works inside an ephemeral GitHub Actions-powered environment: assign it an issue or prompt, it explores the repository, runs tests, and opens a pull request, and you can steer a running session with follow-up messages. Enterprises can point it at self-hosted Actions runners.
The shared tradeoffs are structural, not quality complaints. Each sandbox runs only its own vendor's agent, so a team using Claude Code and Codex side by side gets two separate consoles with different behavior. The environments are task-scoped or reclaimable, not persistent machines: state you did not push, a database you seeded, a dev server you left running, all evaporate between tasks. And except for the self-hosted variants, execution happens in the vendor's cloud, which your security review may or may not accept for private code.
The real question: do you need a task runner or a machine?
Vendor sandboxes answer "run this task while I do something else." A VM answers "give my agents a permanent place to live." If your always-on need is fire-and-forget PR-sized tasks, a sandbox is less work and you should use one. If it is longer-horizon work (an agent mid-refactor you want to reopen tomorrow, several agents in parallel on one codebase, dev servers a teammate can click through, tools and credentials that persist), you want a machine, and the glossary entry on background agents vs cloud agents unpacks the vocabulary vendors use around this split.
| Topic | Kept-awake laptop | VM you own | Vendor cloud sandbox |
|---|---|---|---|
| Survives lid close | Sometimes (settings dependent) | Yes | Yes |
| Lifetime | Until sleep, reboot, or travel | Persistent until you stop it | Task-scoped or reclaimed on inactivity |
| Which agents | Any CLI | Any CLI, several at once | That vendor's agent only |
| Code and credential custody | Your machine | Your cloud account | Vendor's cloud (self-hosted variants excepted) |
| Setup effort | Minutes | An afternoon | Minutes |
Where AQ fits
AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In this guide's terms, AQ is the VM route with the afternoon of setup and the ongoing glue done for you, plus the part none of the three routes above give you: your team in the same session.
Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, streamed live to the browser. Sessions survive a closed laptop and resume from any device, phone included. Because it is one machine rather than one sandbox per vendor, every agent lives in one place: each workspace gets its own isolated git worktree with dependencies installed, so parallel agents never collide, and each workspace can run a live dev-server preview with a shareable link. Teammates open the same workspace and watch the same live session; typing into someone else's terminal happens only after its owner approves a control request. Custody stays yours: VMs you connect from your own cloud (or a dedicated always-on AQ-managed VM in its own isolated network), per-user CLI logins with your own Claude and OpenAI accounts (AQ never marks up usage on your own subscriptions), and no shared multi-tenant execution tier.
Pricing is two plans: Free is a personal sandbox for one person (AQ creates a private machine in an isolated network, nothing to install, no time limit), and Team is $50 per user per month in early access (standard $200), with your rate locked for your first 12 months.
Plainly: for solo fire-and-forget tasks, the vendor sandboxes are excellent and simpler. For one engineer comfortable in tmux, the plain VM is enough. AQ earns its place when always-on stops being a personal convenience and becomes how the team works: many agents, one place, everyone able to see and steer them.
Frequently asked questions
Can I keep a coding agent running 24/7 on my laptop?
Not reliably. Utilities like macOS caffeinate prevent idle sleep, and Windows can be set to ignore the lid, but Apple Silicon Macs sleep on lid close regardless, and every laptop eventually reboots, updates, or leaves the network. A kept-awake laptop covers a single evening run; always-on means moving the session to a machine that never sleeps, either a VM you own or a vendor's cloud.
Do vendor cloud agents keep running after I close the browser?
Yes, while a task is active. As of August 2026, Claude Code on the web sessions persist when you close the browser and can be monitored from the mobile app, Codex cloud tasks run to completion in their containers, and Cursor and Copilot agents likewise finish without you watching. The caveat is lifetime: these are task-scoped environments, and idle sessions are reclaimed, so state you did not push does not persist the way it would on your own VM.
What does an always-on VM for coding agents cost?
Less than the model usage it hosts. A small cloud VM suitable for agent work costs from a few dollars to some tens of dollars per month depending on size and provider, and one VM can host many agent sessions in parallel. For most teams the LLM subscription or API spend dominates total cost, so the VM is not the line item to optimize.
Which is safer for private code: my own VM or a vendor sandbox?
They draw different boundaries. On your own VM, the repository clone, GitHub tokens, and shell stay in your cloud account, and only prompts go to the model provider. In a vendor sandbox, the execution environment itself runs in the vendor's cloud (Anthropic, OpenAI, Cursor, or GitHub), under that vendor's isolation and data terms. Cursor and Copilot offer self-hosted execution variants for enterprises. Which is acceptable depends on what your security policy actually requires: check whether it constrains where code executes, or only where it is stored.
Can several always-on agents share one machine?
Yes, and one VM running several agents is usually better economics than several sandboxes. The requirement is isolation between tasks: give each agent its own git worktree and its own tmux session so two tasks never edit one checkout. That is scriptable by hand, and it is the arrangement AQ sets up per workspace automatically, one isolated worktree and persistent session per task.