Introducing the Mobile Sandbox: A Disposable Cloud Phone Your Agents Can Drive

Some work only happens on a phone

A growing share of agent work ends at a screen that is not a browser. A mobile build needs a smoke test before it ships. A supplier's app has no web version, so the only way to check an order is to open the app. A crash report says "Android 13" and nobody on the team has one. Each of these needs a phone, and a phone on a desk does not scale, does not sit behind an API, and cannot be thrown away when the job is done.

Today we are launching the mobile sandbox: a disposable cloud phone that Naive Managed Agents boots on request and your code drives the way a person does, by looking at the screen and touching it. It is the third member of the computer suite, beside the Linux sandbox and the managed browser. The Mobile sandbox primitive page summarizes the surface; the mobile reference has every field.

One object

A mobile sandbox is a single resource, a mobile device on the wire (/v1/mobile_devices, ids prefixed mob_). It needs no Linux sandbox and has no shell. It is a screen, touch input and an app lifecycle.

An Android phone reaches ready in about a minute, so an agent or a test run can treat a fresh phone as something it creates per task rather than a shared machine it has to book and clean up after.

Look, then touch

Every interaction is one of seven actions sent to the device's act route. They are the same whether a script, a person in the dashboard, or an agent is doing the driving.

Screenshot pixels map one to one onto tap coordinates, so "look at the picture, tap where the button is" works without any scaling math. When a point is too brittle, tap by selector instead: { "text": "Sign in" } finds the element the way a person reads the screen. Take the next screenshot to see what an action did.

Watch it live

In the dashboard, under Computers → Mobile, every device has a workspace: the screen, which you click to tap; the hardware keys (Home, Back, Recents and Enter); controls to type, scroll and open a URL; and a Live toggle that swaps the screenshot for a realtime stream of the screen, in the same place and at the same size. That makes a mobile sandbox as useful for a person reviewing an agent's work as for the agent doing it. You can watch a test flow run, step in to dismiss an unexpected dialog, and hand control back.

Timers, not pause

A mobile device has no pause. It lives until you delete it or one of two timers fires, both set at create:

Two failsafes sit on top of the timers. Creating a device needs a funded balance, and a device is ended automatically if the organization's balance runs out or its plan lapses. There is no fixed number of phones per account: phones run as long as the account has credit to pay for them. A phone someone forgot about on Friday is not still running on Monday.

Driving one from the SDK and the CLI

The SDK is one method per route.

const { mobileDevices } = vetta;
let phone = await mobileDevices.create({ name: "pixel", os_version: "15" });
while (phone.status === "creating") {
  await new Promise((r) => setTimeout(r, 3000)); // about a minute to boot
  phone = await mobileDevices.get(phone.id);
}
 
// look.image is the screen as a base64 image
const look = await mobileDevices.act(phone.id, { type: "screenshot" });
await mobileDevices.act(phone.id, { type: "tap", x: 81, y: 1087 });
await mobileDevices.act(phone.id, { type: "tap", selector: { text: "Sign in" } });
 
await mobileDevices.delete(phone.id);

The CLI covers the same lifecycle, which makes it easy to script a smoke test in CI.

vetta mobile create --name pixel --os-version 15
vetta mobile screenshot mob_… --out shot.jpg
vetta mobile act mob_… --type tap --text "Sign in"
vetta mobile delete mob_…

The REST routes are the same shape, and they are also published in the platform's MCP catalogue. Details: API, SDK, CLI.

What it costs

There is no creation fee. A device costs $0.039 per device-minute ($2.34 per device-hour), billed in whole minutes from create to end, with a one-minute minimum. It appears as a single mobile line item on the organization ledger, drawn from the same prepaid balance as everything else. Phone minutes bill that balance directly: they are not held against a session's or an agent's budget cap. Because a device ends itself when idle, the bill tracks the minutes a phone is actually in use, not the minutes someone forgot to clean up.

What it is, and what it is not

Being honest about the edges:

• Agents pick up phones themselves. Beside the API, SDK, CLI and dashboard, an agent on the default harness has a built-in mobile tool. It opens a phone on first use, sees the screenshots it takes, and saves them as files, the way it already reaches its computer. It asks before its first call, and you can watch the phone live while it works.
• A phone is not bound by a browser's allowed domains. open_url opens any URL or deep link, so keep the tool on approval for an agent whose web reach you have narrowed.
• Apps install by package name, at create. They come from the platform's curated app catalogue (there is no upload route), and there is no install on a device that is already running.
• Android, virtual, phones only. Virtual phones cover builds, flows and version-specific bugs, not a particular handset's hardware. No iPhones, tablets or watches yet.

Get started

Create a device from the dashboard's Computers → Mobile page, or with vetta mobile create. The full surface is in the mobile reference, and the computer launch post covers the Linux sandbox and browser that a mobile sandbox now sits beside.