boxes.dev vs Amp

At a glance

As of September 2026.

Whose agent does the work

Amp runs its own agent, and boxes.dev runs Claude Code and Codex.

In Amp, you choose a mode for each thread, from low to ultra, and Amp picks the models, prompt, and tools behind it, and you can pin models for each mode. Amp bills model usage to Amp credits at the providers' API prices, or you can route models through a ChatGPT or SuperGrok subscription, your own API keys, or a gateway.

boxes.dev runs the Claude Code and Codex CLIs on your devboxes, signed in with your Claude or ChatGPT plan or an API key, so their commands, skills, and settings work as they do on your computer.

Setup scripts or a copy of your machine

Amp prepares orbs from scripts you commit to the repository, and boxes.dev copies a machine where your app already runs.

A new Amp orb starts from Debian 12, clones your repositories, and runs .agents/setup. Amp saves the prepared orb as a project snapshot and reuses it for new threads for up to 72 hours, and long-running services such as dev servers go in .amp/services.yaml. Amp bills orb time by the minute, from the allowance in a paid tier or at standard rates, and a paused orb costs nothing.

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, and 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.

Reaching the running app

Both show the running app inside the thread and share it by link, and boxes.dev also brings the app to your laptop.

An Amp Portal is a link to a service on one of the orb's ports, which you can open in the thread's Portal tab and annotate with comments for the agent. You can make a portal public for one hour to seven days. A custom hostname stays assigned when you archive its thread, and you can move it to a portal in another thread.

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, 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

Amp can open a thread and its orb to everyone in your workspace, and on boxes.dev, teammates read your threads, while only teammates you allow can send your agent work from Slack.

Mentioning @Amp in Slack can start work or manage an existing Amp thread, and each person's Puck uses that person's permissions and connections. You can also open a thread to your workspace for seven days, so teammates can prompt the agent and use the orb's terminal, files, and portals. Amp's docs note that every workspace member can then access the orb's secrets, and all agent and orb costs are billed to the thread owner.

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 Claude Code or Codex 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.

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.

A boxes.dev devbox can hold several threads, so you can start a new conversation about the files already there, and you can branch a conversation onto a new devbox that starts with the current files, including uncommitted work.

Where Amp shines

• Puck. A personal assistant that starts, steers, and finds agents for you from the web, the CLI, the apps, or a realtime voice call.
• A desktop in every orb. A full desktop with Chrome that the agent can drive while you watch, for browser tasks, Android emulators, and other graphical apps.
• Choosing a mode instead of a model. Amp routes each mode among models from several providers and changes that routing as models improve.

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

Amp runs Anthropic models on Amp credits at API prices, your own API key, or a gateway. On boxes.dev, Claude Code uses your Claude plan, which is heavily discounted. By our estimate, a fully utilized Claude Max plan is at least 40x cheaper than the same usage at API prices, so you'll pay far less for the same tokens.

Amp counts orb minutes while an orb runs, and larger orbs use them faster. Amp says Megawatt's 45,000 minutes are enough to run three 2-CPU orbs eight hours a day all month, or 375 hours of a 4-CPU, 8 GB orb. See Amp's pricing and orb sizes and costs.

Using both

Amp and boxes.dev can work on the same repositories and pull requests. You can keep Amp for the work its agent and Puck handle, and use boxes.dev when you want Claude Code or Codex on a copy of your full environment.

Frequently asked questions

Can I use my ChatGPT or Claude plan with Amp?

Amp can route OpenAI models through a linked ChatGPT subscription and Grok models through SuperGrok, inside Amp's own agent. Anthropic models run on Amp credits, your own API key, or a gateway. boxes.dev runs Claude Code with your Claude plan and Codex with your ChatGPT plan.

What's the difference between an orb and a devbox?

Both are cloud Linux machines that pause when idle and wake with their files and running services. An orb belongs to one Amp thread and starts from your project's setup snapshot. A boxes.dev devbox starts as a copy of your Template box, can hold several Claude Code and Codex threads, and stays yours until you delete it.

Can I work on a devbox from my own editor?

Yes. dvb ide opens a devbox in VS Code or a JetBrains IDE over SSH. See Install and use the CLI. Amp's CLI connects to editors on your computer, and amp sync mirrors an orb's changes into your local checkout.

Sources

• Amp: orbs, customizing orbs, sizes and costs, Portals, desktop, agent to agent, automations, event-driven orbs, handling secrets, GitHub, projects, threads, working together in a thread, Puck, Slack, the Dial, model routing, spawning orbs, CLI, macOS and iOS apps, and pricing.
• boxes.dev: How boxes.dev works, Update your Template box and snapshots, Startup, teardown, and maintenance, Start and continue threads, 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, Branch a conversation, Organize and share threads, Team access and roles, Install and use the CLI, Work from Slack, Work from Linear, Use boxes.dev on your phone, and Plans, seats, and box-hours.