Boxes.dev vs CloudCLI

At a glance

As of October 2026.

A container you set up, or a copy of your running environment

CloudCLI gives each environment a container where you install your stack, and boxes.dev gives each task a full copy of an environment where your app already runs.

A CloudCLI environment is an Ubuntu container with Claude Code, Codex, Cursor CLI, Gemini CLI, and OpenCode installed, and it has 2 CPUs and 4 GB of memory on the Hobby and Growth plans. When you create one from a GitHub repository, CloudCLI clones it into the environment's /workspace/ folder, which can hold several projects. CloudCLI's docs say the environment comes "bare bones by default", so you or the agent install languages, databases, and other tools with apt, using an account with full sudo access. The pricing table lists environment templates and dotfiles support as Enterprise features. Teams can also sync organization-wide MCP servers and shared skills into each developer's environment.

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. Team Templates let an admin prepare one starting environment for everyone on the team.

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, services, and data, 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 you close your laptop

Both keep working after you close your laptop, and they handle idle machines differently.

A CloudCLI environment runs in the cloud, so its agent sessions keep going when your laptop sleeps, and you can reconnect from a phone, a browser, or VS Code. CloudCLI's API docs say an environment stops automatically after an idle window, and they don't publish its length. When an environment stops, its running processes receive a shutdown signal, SSH and web access turn off, and the files in /workspace/ stay on the server's disk until you start it again.

A boxes.dev devbox stays awake while its agent works and sleeps when nobody is using it. 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, and a sleeping devbox doesn't use box-hours. The devbox stays yours until you delete it.

Reaching the running app

On boxes.dev, you and the agent can both use the app running on a devbox, and CloudCLI forwards the app's port to your laptop over SSH.

CloudCLI's docs say to start your dev server on 0.0.0.0 and open it through VS Code's port forwarding over Remote-SSH, or through an SSH tunnel such as ssh -L 8000:localhost:8000. With Browser Use turned on, agents can also drive a browser in the environment. On hosted environments, you can watch that browser and take control for a login or MFA step, and the agent continues from the same page afterward.

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

Both let teammates into your work, and they differ in what a teammate can do there.

On CloudCLI's Team plan, the owner of an environment can share it with chosen members or with the whole organization. Teammates can open the environment in the browser, start and stop it, and connect over SSH, while deleting it, changing its settings, and sharing it stay with the owner. Usage from a shared environment counts toward the owner's plan, and organization admins see a read-only list of the organization's environments.

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. A named command such as @boxes.dev !bugfix runs a saved automation. 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.

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.

Work can also start from an assigned Linear issue, a schedule, or an API call. Agents can start other agents on new or existing devboxes, message each other, read earlier threads, and leave notes in a shared /project folder, and you can branch a conversation onto a new devbox with the current files, including uncommitted work. The iOS and Android apps can reply to agents, browse files, and open a shell on a devbox.

Where CloudCLI shines

• Five agents in every environment. Claude Code, Codex, Cursor CLI, Gemini CLI, and OpenCode work in the same container, so you can start the next run with a different agent on the same files.
• Workflows from n8n. A verified n8n node and published templates can start an agent from a Jira or Linear issue, a GitHub event, a schedule, or any webhook, and a REST API covers the same steps.
• Browser handoff for logins. When an agent's browser reaches a login or MFA screen, you can take control in the Browser panel, finish the step, and let the agent continue in the same browser.
• Open-source UI. The CloudCLI UI is licensed under AGPL-3.0, and you can run it for free on your own machine or server.

Pricing

As of October 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. Your Claude or ChatGPT plan covers the agents' usage. See Plans, seats, and box-hours.

CloudCLI charges for environments instead of hours. Hobby includes one environment with 2 CPUs and 4 GB of memory, Growth includes five of the same size, and Team adds five members, roles, and one bill. A free trial gives 2 hours of runtime on one environment, used within 2 days of signing up. See CloudCLI's pricing.

Using both

CloudCLI and Boxes.dev can work on the same repositories with the same agent subscriptions. You can keep CloudCLI for n8n workflows and agents beyond Claude Code and Codex, and use boxes.dev when a task needs its own copy of your full running app.

Frequently asked questions

Does a CloudCLI environment keep running when I close my laptop?

Yes, until its idle window ends. Then the environment stops, its running processes receive a shutdown signal, and the files in /workspace/ stay for the next start. A boxes.dev devbox sleeps when idle, keeping its files and memory, so its dev servers and databases resume when it wakes.

Can I use my own agent subscriptions with both?

Yes. CloudCLI's docs say you bring your own subscriptions and keys, such as Claude Pro, a Cursor plan, or an OpenAI API key. Boxes.dev runs Claude Code with your Claude plan and Codex with your ChatGPT plan, or with an API key.

Can I open my cloud machine in my own editor?

Yes. CloudCLI environments work with VS Code or Cursor through Remote-SSH, and dvb ide opens a boxes.dev devbox in VS Code or a JetBrains IDE over SSH. See Install and use the CLI.

Sources

• CloudCLI: home and pricing, cloud environments, AI coding agents, teams, cross-device, integrations, open source, CloudCLI Cloud overview, running and previewing your app, sharing environments, Browser Use, Git explorer, mobile, create environment, start environment, stop environment, execute agent, and source.
• 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, Preview your app, Project URLs, Create and publish a Team Template, Connect Codex and Claude, Environment files and secrets, Add MCP servers, Install agent plugins, Organize and share threads, Team access and roles, Branch a conversation, Shared project storage, Commit, push, and open a pull request, Install and use the CLI, Work from Slack, Work from Linear, Create an automation, Use boxes.dev on your phone, and Plans, seats, and box-hours.