boxes.dev vs Conductor

At a glance

As of September 2026.

How the cloud machine is set up

Conductor builds cloud workspaces from your organization's scripts, and boxes.dev copies a machine where your app already runs.

Conductor's Cloud Computer is one shared environment for your organization. Each build clones your GitHub repositories, adds organization environment variables and secrets, and runs an install script for system packages and runtimes, and an agent can help write the scripts. Each repository's setup script then runs in every new workspace, for dependency installs and seed data. Conductor's paid plans include cloud workspaces with no separate charge today, and Conductor says it plans to add usage-based pricing for cloud compute.

boxes.dev first sets up your full development environment on a cloud machine called the Template box, with the tools, databases, services, and data your app needs, so an agent can run the app and test its changes end to end. A setup agent can port the environment from your laptop, including the files, local data, agent settings, and skills you choose to upload, or build it from a GitHub repository. boxes.dev then saves the Template box as a snapshot, and every task runs on its own devbox, a full, isolated copy of that machine. A maintenance script can keep the Template box current as your code changes, running on a schedule or when files such as a lockfile change, and each successful run saves a new snapshot.

You'd never let an engineer ship code they hadn't run, and a full environment holds the agent to the same standard. On a boxes.dev devbox, the agent runs your whole app, with its databases and services, and tests its changes in the browser as it builds. It reproduces bugs in the real app to find the root cause instead of guessing from the code, so it writes better code and makes fewer mistakes. It can also take screenshots and record video for you to review, so you can hand it most repetitive manual testing.

When the machine goes idle

A boxes.dev devbox keeps its running programs through sleep, and a sleeping Conductor cloud workspace keeps its files.

Conductor puts a cloud workspace to sleep after four hours without agent or terminal activity. Its docs say that files and chat history survive sleep but running processes don't, and that every sandbox stops at a maximum lifetime of 23 hours and 50 minutes, which can interrupt running processes and agent turns.

A boxes.dev devbox sleeps when nobody is using it, and an agent that is still working keeps it awake. Sleep keeps the machine's files and memory, like closing a laptop's lid, so dev servers, databases, and terminal sessions resume where they left off when it wakes. The devbox stays yours until you delete it, and a sleeping devbox doesn't use box-hours.

Reaching the running app

On boxes.dev, you and the agent can both use the app running on a devbox, and Conductor forwards a cloud workspace's ports to your Mac.

Conductor can forward the ports a cloud workspace is listening on to localhost on your Mac. The local port usually differs from the one in the sandbox, so you open the address Conductor shows for each port.

Each boxes.dev devbox runs a browser that you and the agent share, so you can watch the agent test the app, click through it yourself, or comment on page elements to show the agent what to change. Ports forwards the app to the same localhost port on your laptop and gives each devbox stable .localhost addresses. A public link shares a devbox's running app with anyone, and a Project URL gives your project one stable public address that you can point at any devbox, which suits OAuth callbacks and webhooks.

Working with your team

Conductor lets teammates prompt the agent in each other's cloud workspaces, and on boxes.dev, teammates read your threads, while only teammates you allow can send your agent work from Slack.

In a Conductor Cloud organization, workspaces are shared with the team unless you make one private. Teammates can open each other's workspaces, watch chats update as the agent works, send prompts in the same chat, and follow or reassign a workspace.

Each boxes.dev devbox belongs to one person and works with their access, such as their GitHub login and cloud credentials. Anyone who can prompt its agent could act with that access, so in the app, teammates get read-only access to your work. You can share a thread as a link, and a team admin can let teammates read every thread that isn't marked private and browse each other's projects in a Team workbench. Teammates can't send prompts, open your terminal, or control your devbox.

In Slack, mentioning @boxes.dev in a thread starts Codex or Claude Code on a new devbox, and later mentions in that thread send follow-ups to the same conversation. By default, only you can start work in your project from Slack or follow up on it. If you allow teammates, they can also start work there with @boxes.dev @YourName and send follow-ups, and their requests run with your access and usage. boxes.dev sends you a DM with links to each task a teammate starts, and commits can link to the thread that produced them. Team Templates let an admin prepare one starting environment for everyone on the team, while each member's own credentials go only to that member's project.

What comes with every boxes.dev devbox

The boxes.dev desktop app opens the same set of tools for whichever devbox you select:

• Terminal, with tabs that keep running after you close the app.
• Files, a file browser and editor with search across the workspace.
• Git/Review, for branch history and diffs, where comments on changed lines go to the agent together as one message.
• Browser, the browser on the devbox that you and the agent share.
• Ports, for the forwarding, .localhost addresses, and public links described above.
• Activity, which shows the processes using the machine's CPU and memory.

dvb agents lists your threads and devboxes in a terminal on your computer. AWS, Tailscale, and the MCP servers and agent plugins you add for the project reach every devbox. You can branch a conversation onto a new devbox that starts with the current files, including uncommitted work.

Where Conductor shines

• Starting from GitHub. A workspace can start from a branch, pull request, or GitHub issue, and routines can run from a GitHub Action.
• Four agent families. Claude Code, Codex, and OpenCode come bundled, and Cursor sessions use Cursor Agent.
• Stacked pull requests and checkpoints. Conductor works with GitHub stacked pull requests, and checkpoints let you revert a workspace to an earlier agent turn.

Pricing

As of September 2026.

A box-hour is one default devbox awake for an hour, and sleeping devboxes don't use any. On Starter, 40 box-hours works out to about two hours of devbox time each working day, and Pro's 250 to about twelve, spread across as many as ten devboxes at once. See Plans, seats, and box-hours.

Conductor's cloud workspaces cost nothing beyond the plan today, but Conductor doesn't say how many hours a plan includes or how many cloud workspaces can run at once. Team plans are invite-only. See Conductor's pricing.

Using both

Conductor and boxes.dev can work on the same GitHub repositories and pull requests, with the same Claude and ChatGPT logins. You can keep Conductor for work you already run there, and use boxes.dev for tasks the agent should test in your full running app.

Frequently asked questions

Can I use my Claude or ChatGPT subscription with both?

Yes. boxes.dev connects Claude Code with your Claude login and Codex with your ChatGPT login, and either agent can use an API key instead. Conductor's docs say that agent usage is billed through your provider account or API key.

How do parallel tasks avoid port conflicts?

Conductor assigns each local workspace on your Mac its own ports through CONDUCTOR_PORT, and its docs suggest running one workspace's app at a time when a project depends on one fixed port, one local database, or one Docker stack. Each Conductor cloud workspace runs in its own microVM, and each boxes.dev devbox is its own machine, so every task can use your app's usual ports and its own copy of the database.

Can I bring my local setup to boxes.dev?

Yes. Setup agents on your laptop inspect your environment and prepare a plan, you review the files and data selected for upload, and an agent on the Template box checks that your app runs. See Set up from a local folder.

Sources

• Conductor: pricing, cloud FAQ, Cloud Computer, cloud environment variables, working with cloud workspaces, collaboration, set up cloud, workspaces and branches, linking multiple directories, issue to PR, scripts, harnesses, diff viewer, checkpoints, API, 0.80.0: stacks, 0.83.0: port forwarding, 0.84.0: editing in diffs and remote desktop, 0.85.0: routines and private workspaces, 0.86.0: sections, and the App Store listing.
• boxes.dev: How boxes.dev works, Update your Template box and snapshots, Startup, teardown, and maintenance, Sleep, wake, and recover a devbox, Review a page with your agent, Browse, edit, and transfer files, Preview your app, Project URLs, Commit, push, and open a pull request, Organize and share threads, Team access and roles, Agent permissions, Agent command reference, Environment files and secrets, Install and use the CLI, Work from Slack, Work from Linear, Use boxes.dev on your phone, and Plans, seats, and box-hours.