Your AI Agent Can Drive a Real Phone Now. What That Actually Costs
Synergised Consulting Ltd
Last Updated: 4 November 2026
Phone Harness gives AI agents a real phone to work with: cloud-hosted iPhones and Android devices that an agent drives through the screen itself, tapping and typing like a person, at 5 US cents per Android phone-minute or a flat monthly rate for a real iPhone. The direct cost is small and easy to calculate. The real cost sits elsewhere: the logins, messages and 2FA codes that live on that phone belong to your business, and the device sits in someone else's cloud.
What Phone Harness Actually Is
Phone Harness is a hosted phone rental for AI agents: real iPhones and Android emulators running in the vendor's cloud, which an agent controls through the same interface a person uses. There is no jailbreak, no per-app API and nothing to install on the device. The agent reads the screen and acts on it.
Phone Harness is a Y Combinator Fall 2026 company founded by Shawn Pana, and it describes itself on Y Combinator's public directory as the most popular open-source harness for phone automation. On 23 October 2026 the company released its MCP server, phone-harness/mcp, under an MIT licence on GitHub. MCP, the Model Context Protocol, is the connection standard that lets an AI agent use external tools, so adding this one server gives an agent hands on a phone from inside Claude, Cursor, ChatGPT, Codex or any other MCP client [1].
The fifteen tools
The hosted server registers exactly 15 tools [1]. The names describe a person's hands rather than an app's internals: take a screenshot, list the elements visible on screen with their tap positions, tap at coordinates, long-press, swipe, type text into the focused field, press HOME or BACK, launch an app by the name on its icon. Two details tell you a lot about the design. Screenshots are JPEG images capped at a default long side of 1,024 pixels, so the agent works from a compressed view of the screen. And there is no tool that opens a URL. The agent can only reach what a person could reach by touching the screen, one app at a time.
On an Android device the agent reads the screen through the operating system's accessibility tree, the same structured text a screen reader uses. On an iPhone it falls back to text recognition on the image, which is slower and less precise. That asymmetry matters when you are deciding which tasks suit the tool.
What it costs in money
The pricing is straightforward and published [2]. Cloud Android emulators are free to start, then 5 US cents per phone-minute, charged from the moment the device is ready until the session ends, with partial final minutes rounded up.
Boot time is free, and a new account starts with $5 of credit, roughly 100 emulator minutes. A real cloud iPhone is a flat subscription rather than a metered device: $80 per month, or $100 with an eSIM that gives the phone a real number for SMS and 2FA, discounted 20 percent for annual billing to $64 and $80 effective monthly.
Accounts can run up to 8 phones at once, and an emulator takes about 80 seconds from request to ready [2].
One arithmetic example, illustrative rather than measured: an agent that drives an emulator for a 6-minute task each working day uses about 130 phone-minutes a month, which at 5 cents comes to around $6.50. The meter itself is not the barrier. The reason to look closely is what the phone is logged into while the meter runs.
What a Run Actually Looks Like
Picture a repetitive mobile task: checking whether a supplier's invoice has appeared in their app, then copying the total into your accounting spreadsheet. Today that is ten minutes of one person's evening, and the only record is whatever that person remembers. With this tooling, an agent starts a cloud Android, opens the supplier's app with saved logins kept from the previous session, reads the invoice total from the screen, writes it to the spreadsheet, and stops the phone. The vendor's own documentation shows the shape of this working pattern, and states that emulator sessions keep apps and logins between runs [1]. This is an illustration of the category, not a case study: this exact task has not been run here, and any real result depends on the specific app's behaviour.
For an owner running agent workflows, the practical change is that mobile-app steps stop being the part of a process that only a human can execute. Whether they should be executed by an agent is the next question, and it is about identity more than capability.
What It Is Not For
The limits are stated plainly in the vendor's own material, which is worth more to a buyer than any capability list [1]. There is no URL-opening tool, so the agent cannot browse the web through the phone; it works inside the apps installed on it. iPhone reading is text recognition rather than a structured screen tree, so dense small-text screens are the weak case. Sessions have a chosen timeout and there is no unlimited mode, so this is not a place to park an always-on presence. And the vendor's own profile is a team of one at an early stage [3], which is a fair reason to keep anything critical off it for now.
There is also a boundary worth stating precisely: this drives phones that the vendor hosts. Driving your own physical phone over your own network is a documented mode of the same open-source harness, and it keeps the device inside your walls [4]. The cloud phones are the convenient option, and convenience is where the identity question lives.
The Identity Question
The phone is yours in the sense that you pay for it, but it terminates in the vendor's cloud, and the logins on it are real. Put your banking app on a cloud phone and every session, screen and stored credential sits on infrastructure you do not operate. That is not an accusation against this vendor; it is the structural fact of any hosted device service, and it is the part the price-per-minute does not cover.
The vendor's own documentation points at the right pattern without naming the risk: for agent fleets, an orchestrator holds the account credentials while each individual agent sandbox receives only a host, a port and a single-use connection code, so one compromised agent cannot reach other phones or spend credit [4]. The same instinct scales to a small business: decide which accounts may ever live on a hosted phone, start with ones that are recoverable, and keep anything where a login is the crown jewel on a device you own.
In our own work scoping agent tooling for small operations, the conversation rarely starts with a capability list. It starts with one repetitive task and the question of what the agent is allowed to touch while doing it. Phone Harness fits that conversation well, precisely because its design makes the boundary visible: a fixed set of 15 tools, no web browsing, one device at a time. That is the shape of tooling that can be scoped honestly.
What an Owner Can Usefully Take From It
Agents gained real hands on mobile apps this month, at a price a small business can trial for the cost of a coffee. The sensible response is neither excitement nor refusal, but a scoping decision: pick one low-risk, repetitive mobile task, run it on an emulator with a throwaway account, and read the session log before any real login goes near a hosted phone. The tool list, the per-minute meter and the session record together give you something rare in agent tooling, which is evidence of exactly what the agent did, on which device, for how long. Deciding what deserves that kind of trial, and what stays on your own hardware, is the owner's call, and it is worth making before the next round of agent tooling makes it for you.
