boxes.dev vs Niteshift

At a glance

As of September 2026.

Config in your repository, or a copy of your machine

Niteshift describes each environment in files in your repository, and boxes.dev copies a machine where your app already runs.

In Niteshift, a setup agent works out how to install, run, and check your project, proves it in a cloud environment, and opens a pull request that commits the .niteshift/ configuration. After setup succeeds, Niteshift snapshots the environment and starts later tasks from it. Niteshift bills credits for active agent time, which comes to $6 an hour, and doesn't charge for idle environments.

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.

Testing the change

Both agents test changes in a browser and capture screenshots and video, and Niteshift also adds them to the pull request automatically.

Niteshift's agent drives a persistent Chromium browser against your preview, and you can take the browser over. Its /screenshots and /demo skills capture screenshots and demo videos and add them to the pull request description, and you can select an element in the preview to add it to your prompt.

On boxes.dev, the agent tests in the browser you share with it, against your full environment with its databases, services, and data, and you can review its screenshots and video in the Files tool.

Reaching the running app

In both products, you and the agent can use the app running in the cloud, and boxes.dev also brings it to your laptop and gives your project one address that you can move between devboxes.

In Niteshift, each port a service declares gets a preview link that requires a Niteshift login. A service can also open a tunnel, a stable public link with no Niteshift login, for webhooks and other outside systems. Shareable preview links for each pull request are in early access.

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 it with anyone, and a Project URL gives your project one stable public address that you can point at any devbox, for OAuth callbacks and webhooks.

Working with your team

Both take requests from Slack and let teammates follow each other's work, and in boxes.dev, teammates you allow can send follow-ups to the same conversation, with your access.

Everyone in a Niteshift organization can open a task and watch it work, and only its owner can send prompts. Mentioning @Niteshift in a Slack channel starts a team-visible task, and a DM starts a private one. Your replies in the thread send follow-ups, and a teammate's reply starts that teammate's own task. Typing @ and a task's name in a prompt lets the agent read that task's transcript, branch, and pull request.

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. Agents can read earlier threads, 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 forwarding to your laptop, stable .localhost addresses, and public links.
• Activity, which shows the processes using the machine's CPU and memory.

Agents can start other agents on new or existing devboxes, message each other, and leave notes in a shared /project folder, and you can branch a conversation onto a new devbox with the current files.

Where Niteshift shines

• Proof on the pull request. The agent adds its screenshots and demo videos to the pull request description, so reviewers see the change working.
• Autofix for people's comments too. Autofix can also act on your own and your teammates' review comments, and it replies to and resolves the threads it fixed.
• Environment config you can review. The setup agent's .niteshift/ files go through a pull request like any other change.
• Database branches. With Neon connected, each task gets its own Postgres branch for migrations and destructive queries.
• An MCP server for Niteshift. Other agents can start and steer Niteshift tasks through its hosted MCP server.

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.

Niteshift turns each plan's price into credits dollar for dollar and charges 0.1 credits for each minute of active agent time. boxes.dev counts every hour a devbox is awake, including time you spend in it after the agent finishes, so the two units differ. See Niteshift's pricing.

Using both

Niteshift and boxes.dev can work on the same repositories and pull requests. You can keep Niteshift for tasks that end in a tested pull request with proof attached, and use boxes.dev when a task needs a copy of your full running environment.

Frequently asked questions

Can I use my Claude and ChatGPT subscriptions with both?

Yes. Niteshift runs Claude Code and Codex with your subscription or API keys, and boxes.dev runs them with your Claude or ChatGPT plan or an API key.

Do I need to write environment config for boxes.dev?

No. A setup agent prepares the Template box from your laptop or a GitHub repository, and every devbox is a copy of it, with no setup files in your repository.

Can I open a devbox in my own editor?

Yes. dvb ide opens a devbox in VS Code or a JetBrains IDE over SSH. See Install and use the CLI.

Sources

• Niteshift: introduction, quickstart, tasks, environment configuration, setup and resume, services, multiple repositories, database branches, browser automation, Autofix, automations, GitHub, Slack, Linear, MCP server, skills, MCP, plugins, home, changelog, and pricing.
• 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.