Skip to main content
Each device is billed one of two ways. The choice is per device, not per org, so a fleet can mix both. A single device, though, runs exactly one mode: monthly or metered, never both, and a monthly device is never metered.
Rates on this page reflect the pricing decision of 2026-08-29. The canonical, always-current price list is phonebase.co; if the two ever disagree, the site wins.

​
Rates

Prices are per device, by the tier the device is on. You do not name a tier when you call a tool, and no tool takes a tier or a plan argument. A device’s tier is fixed when the device is provisioned, by the subscription that provisioned it, and it travels with the device from then on. Both identifier columns are fields you can read off a device, in the list_devices and get_device response. To find out which row of this table a device bills on, read its backendKind. fidelityTier answers a different question: how input reaches the screen. Three priced tiers share the value software, because fidelity describes the mechanism while price tracks the hardware behind it. Do not read one column off the other. See Capabilities for both fields, including the backend kinds that have no priced tier yet, and Device tiers for what fidelity buys you.
A cloud phone reaches you through the device gateway tunnel, its adapter is live, and you can buy one on the spot from the /devices/add screen. See Buy, drive and return a device.
The table above is the rate card, not the order form. What you can actually buy is whatever GET /v1/skus lists, which is one entry per pair of sku and billing mode that this deployment holds a configured price for. A pair with no price is absent from that list rather than shown without a number.No per minute pair is published today, so a device cannot be bought on the per minute mode right now, whatever rate this table names for it. Call GET /v1/skus and believe that rather than this page.
The robot arm per minute rate is not on sale. It stays on this rate card, and GET /v1/skus never lists a robot arm sku with payg, whatever a deployment configures.Robot arm devices are sold monthly only. GET /v1/skus never lists a sku with billing: "day", whatever a deployment configures.A day pass bought earlier keeps its terms. Its 24 hours start when the device is ready. When they are up, the device leaves your fleet, any task still running on it stops, and you get an order_ended notification. Until the device is ready you can cancel the order for a full refund. If it is not ready within 30 minutes of payment, the order is cancelled and refunded in full automatically.

​
Monthly

A flat monthly price for the device. There is no meter, no allowance to watch, and no overage: run the device all month and the invoice reads the same. Choose this when a device is in steady use, or whenever you want the bill to be a constant rather than a variable.

​
Per minute

No fixed fee. You are billed for active time only, in whole minutes, rounded up, with a one minute minimum per lease. A lease of ninety seconds bills as two minutes; a lease of ten seconds bills as one. Choose this for bursty or exploratory work, where a device would sit unused for long stretches of the month. Remember that active time is lease time: nothing pauses the clock while a lease is held, so release a device when you are done with it. The worst case is bounded, and the bound is the lease, not your attention. A lease expires 10 minutes after it is granted and can be renewed, and no lease may live more than 60 minutes from when it was taken. A device you took, by acquiring it or by acting on it, and then walked away from bills at most that hour and then stops, not the rest of the afternoon, and if the client holding it has crashed it stops after 10 minutes because nothing is left to renew it. Expiry is the only thing that stops the clock: nothing watches for idleness. See Metering units for how active time is integrated, and Spending controls for the limits you can set yourself.

​
Which one to pick

The break-even is arithmetic: divide the monthly price by the per minute rate and you have the number of metered minutes that costs the same as the month. Below that, per minute is cheaper. Above it, monthly is, and the gap widens as usage grows. If you do not know your usage yet, start on per minute. It is the mode that punishes a wrong guess least, and you can move a device later.

​
Agent steps are a separate axis

Steps consumed by the agent tier are counted independently of the device’s billing mode. A device on either mode can run agent tasks, and those steps are accounted for on their own axis. See Metering units. Steps are included in the device price today, and no separate step rate is published. The reasonable use ceiling is not a billing threshold you can cross into an overage. It is enforced as a per run step budget, and a run that reaches its budget is refused its next frame rather than billed more. The default budget is 50 steps per run, a deployment can set its own, and maxSteps on your request can only lower it. One org may have 4 agent runs going at once by default. See Agent tier for how each ceiling is enforced.

​
Accounts start paid

There is no self serve free tier. An org is billed from first use, and there is no trial that silently converts. What softens that is the return. Giving a device back stops its billing and returns the part of the month you did not use, so evaluating one costs a fraction of a month rather than a month. See Buy, drive and return a device. If you would rather buy from a browser than from code, the console does exactly that, on this same surface and at these same rates. It is not a separate product, and this page applies to it.