Mobilerun

MIT-licensed framework from DroidRun that lets an LLM drive a real Android or iOS phone from a natural-language instruction — “open settings and turn on dark mode” — by reading the device’s UI state and issuing taps, swipes and text input. 8.9k GitHub stars, 957 forks, 1,318 commits on main at time of ingest. The canonical example of a mobile-device-agent in this spoke, and the first source here where the controlled surface is a phone rather than a repo, a browser or a chat channel.

Tier: T2 — first-party README plus a first-party benchmark page, with the eval harness published for reproduction. Scores are the vendor’s own runs; nobody outside DroidRun has replicated them.

Two halves: Portal on the device, runtime on your machine

• Portal — an app installed on the phone whose accessibility service (enabled over ADB on Android; a separate flow on iOS) exposes the UI tree, screenshots, text entry and gestures.
• Agent runtime — runs on the operator’s machine as CLI, TUI, Docker container or Python API. It holds the loop, the model and the tools; the phone holds nothing but the Portal.

Quickstart is three commands — mobilerun setup, mobilerun ping, mobilerun configure — then mobilerun run "<task>". Installed with uv tool install mobilerun; Python ≥3.11,<3.14, ADB for Android.

That division matters more than it looks. Because the model never runs on the device, the framework is model-agnostic by construction: OpenAI, Anthropic, Gemini, DeepSeek, OpenRouter, Ollama and any OpenAI-compatible endpoint. It is the same substrate-independence the agentic-coding-harness sources keep demonstrating, applied to a phone.

Modes

• Standard — act on the accessibility tree, screenshots optional.
• Vision — feed screenshots to the model; there is also a vision-only path for surfaces the accessibility tree can’t describe.
• Reasoning — “manager-executor planning” for longer tasks, which is orchestration in miniature: a planner decomposing, an executor tapping.

Around that: custom tools, structured output, per-app “guidance cards”, credential handling, and tracing into Arize Phoenix or Langfuse.

The benchmark: 91.4% on AndroidWorld, self-reported

Mobilerun reports 91.4% on AndroidWorld’s 116 tasks — calendar, settings, Markor notes, recipes, expenses, audio, browser, clock, files, across system apps, third-party apps and multi-step workflows — against a published leaderboard of mobile agents:

A ~7-point lead, attributed to one design choice: read the accessibility API, not the pixels. The claimed payload difference is 500×, plus better accuracy from semantic structure (a labelled button beats a rectangle the model has to recognize) and lower latency.

Against this spoke’s standing Benchmarks open question, that lands in the better half of the evidence. It is an external task set (AndroidWorld is not DroidRun’s), the harness is open for reproduction, and rivals are named with numbers rather than gestured at. It is still the vendor running its own eval and picking the frame — the same posture as jcode‘s self-benchmark, which also showed its method. Compare jetbrains-ponytail-tested, where an outside party measured ponytail and found the self-reported figure roughly 3× the median effect: self-reported numbers are measured on the sample that flatters them. Nobody has done that to Mobilerun yet.

The accessibility tree as a token-budget argument

The 500× claim is really a context-rot argument wearing a performance hat. A screenshot spends the context window describing appearance; the accessibility tree spends it describing meaning, and the model reasons over structure instead of re-deriving it every frame. Vision mode stays as the fallback for canvas-drawn or otherwise opaque screens.

Not peculiar to phones. video-use, routed the same day from an unrelated org, compresses raw footage into a word-level transcript for exactly this reason, and watch-skill rations frames against a text index. The shared move is paged as text-first-agent-design; pxpipe runs it in reverse on a coding harness, where no structured description exists to fall back on.

Cloud

Mobilerun Cloud sells the managed version: hosted devices, fleet workflows, REST APIs, no local runtime. Open framework as the funnel, device fleet as the product; the same open-core shape the spoke keeps meeting.

Related

mobile-device-agent · droidrun · text-first-agent-design · video-use · agentic-coding-harness · agent-orchestration · context-rot · agent-evals · jcode · jetbrains-ponytail-tested · pxpipe