What's happening

Agents outgrew the laptop

A year ago an agent was something you ran in one terminal tab while you watched. Now an engineer runs three or six at once, and the team runs dozens. Each one wants a whole machine: a checkout, a dev server, a database, a browser, ports it can bind, processes it can leave running overnight.

Laptops were not built for this. Neither were the request-scoped sandboxes built for running a snippet and throwing it away. The agent finishes half a feature, the box vanishes, and the work goes with it.

The teams moving fastest have stopped treating the agent's machine as an afterthought. It is infrastructure, and they run it as infrastructure.

Introducing RemoteHost

Sandbox infrastructure for coding agents

RemoteHost gives every agent a real machine and gives the team one control plane over all of them. remote new claude boots a sandbox with Claude Code already running in it; the repo is cloned and a tmux session is waiting by the time you attach. Codex, or any harness you run yourself, works the same way.

Each sandbox is a full machine: root, systemd, Docker, background processes, real ports, its own filesystem. Docker, the GitHub and Linear CLIs, language servers, and the runtimes a repo expects are already in the image. Put a sandbox to sleep and it snapshots; wake it and the same branch, the same scrollback, and the same half-finished dev server are exactly where they were.

Four clients attach to the same live fleet: the remote CLI, its TUI, the desktop app, and the web console. The API drives all of it from your own code, so sandboxes can live inside your product as easily as inside your workflow.

Why switch?

What changes when the machine is real and persistent

• Nothing is thrown away. Sandboxes persist by default and resume from their own snapshot. An agent can work on a branch for a week. Put a sandbox on a TTL when you do want it to clean up after itself.
• The first move is the work. The toolchain ships in the image and the harness boots while the machine provisions. No twenty minutes of apt before the agent reads the first file.
• Many people, one dev env. A teammate attaches to the sandbox you are in and lands in the same session: your panes, your processes, your scrollback. Reviewing an agent's work means sitting down at its desk, not screen-sharing.
• One fleet, however you reach it. Terminal, TUI, desktop, browser, API. Same sandbox, same state, no copies to keep in sync.
• Agents that do not collide. Agent Claims, our coordination layer, streams every agent's position to every other agent and turns away an edit that would overlap another's claim before it lands, including from agents that have never heard of it. Six agents on one laptop, free.
• Billing that follows the machine. Usage runs while a sandbox runs. Stopped sandboxes accrue no runtime charges. There is no idle fleet to forget about at the end of the month.

The teams pulling ahead

What the fast teams have in common

They run agents in parallel, not one at a time. They hand an agent a ticket and a machine, check back in an hour, and attach to the exact session to review. They let long tasks run overnight because the box will still be there in the morning.

They stopped asking each engineer to keep a laptop capable of running the whole stack, and they stopped asking agents to rebuild the world on every run. The machine is provisioned once, from an image the team owns, and reused.

And they can see all of it. Which agent is on which branch, which sandboxes are running, what it costs, who attached when. The fleet is a thing they look at, not a thing they guess about.

How switching works

An afternoon for you, a fortnight for the team

1. Try it yourself first. Start on Starter at $20/mo with a 7-day free trial. 606 machine-hours and 35 concurrent sandboxes are included, which is more than a solo evaluation will use.
2. Send this page. The next chapter is the pitch, written for the people who will ask you the questions.
3. Run a two-week pilot. Chapter three lays it out day by day, with the numbers worth collecting.
4. Move the team onto a Pro org. $100/seat/mo flat for the whole team, with a dedicated sandbox pool, shared billing, audit logs, custom base images, and repository templates. Chapter four covers the migration.

The one-liner

Say it in one sentence

“Every agent gets a real, persistent machine with our toolchain on it, and the team gets one place to see and control all of them.”

Everything else on this page is elaboration. If you only get one sentence in a planning meeting, that is the one.

For each audience

The same product, three conversations

To engineers

Your agent stops fighting your laptop. Run four at once, close the lid, come back to the same tmux session tomorrow. When you want to check its work,remote attach puts you in the pane it is typing in.

To the engineering manager

Agent work becomes visible and reviewable. Every sandbox is a row in the console: who started it, what branch, how long it has run, what it costs. Audit logs record the lifecycle. Onboarding a new hire is an invite, not a week of environment setup.

To security and platform

Agents run in isolated VMs on our fleet, not on employee laptops with production credentials nearby. Pro orgs run on a dedicated sandbox pool from base images you define. Enterprise adds SSO and SCIM, dedicated regions, and a security review with procurement support.

Objections you will hear

And what is true

“We already have devcontainers.”

Devcontainers describe an environment. They do not give an agent a machine of its own that persists between runs, or give the team a view of every agent at once. Keep the Dockerfile: it becomes your custom base image.

“Ephemeral sandboxes are cheaper.”

Per minute, sometimes. Per task, rarely, once you count every rebuild of the same environment and every half-finished branch that vanished with its box. Stopped sandboxes here accrue no runtime charges, so persistence does not mean paying for idle.

“Our stack is too heavy to run remotely.”

Root, systemd, Docker, real ports. Anything that needs a machine rather than a request handler runs unchanged, and heavier profiles are a setting, not a migration.

“Another tool to learn.”

Six commands cover the lifecycle: new, ls, attach, stop, and their variants. Engineers who prefer a UI use the desktop app or the web console against the same fleet. Nobody has to change how they work with the agent itself.

“Vendor lock-in.”

Your code lives in your git remote and your environment lives in an image you own. Agent Claims runs on your own machines, free, with no account. Leaving is remote stop.

The shape of a good pilot

Small, real, and comparable

• Three to five engineers who already use an agent daily. You want people with a baseline, not people learning agents and sandboxes at once.
• One real repository, the one everyone dreads setting up locally. The pilot is most convincing on the codebase where laptops struggle.
• Real tickets from the current sprint. Toy tasks prove nothing to the people you need to convince.
• A Pro org from day one, on the 7-day free trial. The pilot should exercise shared billing, the dedicated pool, and attaching to each other's sandboxes, because those are what the team is buying.

Two weeks, step by step

What happens when

1. Day 1. Create the org, invite the pilot group, and build a base image or repository template from your existing Dockerfile or setup script. Everyone runs remote new claude against the repo and confirms the dev server comes up.
2. Days 2 to 5. Each engineer takes their normal tickets, but hands them to agents in sandboxes instead of on their laptop. Aim for two or three running at once per person. Stop sandboxes at the end of the day; resume them in the morning.
3. Day 6. Pair review. Each engineer attaches to a teammate's sandbox and reviews the agent's work in the live session rather than from a diff. Note how that felt.
4. Days 7 to 10. Push the concurrency. Overnight tasks, long migrations, anything you would never leave running on a laptop. Try Agent Claims with several agents on one branch.
5. Day 11 onward. Pull the numbers below out of the console, write a page, and send it with a link to this one.

What to measure

Numbers that survive a skeptical room

From laptops

Turn the setup doc into an image

Whatever your onboarding document tells a new hire to install, that is your base image. Start from the default image, which already carries Docker, the GitHub and Linear CLIs, language servers, and common runtimes, and layer your extras on top. Pro orgs can save this as a custom base image and a repository template, soremote new lands every engineer and every agent on the same machine.

Secrets move out of dotfiles and into the sandbox's environment through the console or the API. Nothing production-shaped needs to sit on a laptop anymore.

From devcontainers and cloud IDEs

Keep the Dockerfile, change what runs on it

A devcontainer or cloud IDE image already describes your environment. Bring it as the base image. What changes is what you do with the machine: instead of one editor session per person, the same image now boots as many agent sandboxes as the team needs, each persistent, each attachable from any client.

Engineers who liked the IDE workflow get the desktop app. Engineers who liked the terminal get remote attach. Both are looking at the same machine.

From ephemeral sandbox APIs

Same API shape, machines that stay

If you have wired an agent product to a request-scoped sandbox API, the RemoteHost API covers the same lifecycle: provision, ready, running, stopped. The difference is the default. Sandboxes persist and resume from a snapshot unless you set a TTL, so a user's agent can come back to yesterday's work.

Cutover is a client swap behind your own interface. Run both for a week, compare time to first output and rebuild counts, then turn the old one off.

Setting up the org

The checklist

1. Create the Pro org and invite the pilot group first, then the rest. Shared billing and limits are set once at the org level.
2. Publish the base image and repository templates so a fresh sandbox is one command for everyone.
3. Set sandbox defaults: persistent for feature work, TTL for throwaway experiments and CI-style runs.
4. Point people at the clients they prefer. CLI and TUI from Downloads, the desktop app, or the web console.
5. Turn on Agent Claims for any repo where more than one agent works at a time.
6. Talk to us about Enterprise when SSO, SCIM, dedicated regions, or a security review enter the conversation.