On-device phone agents: what open mobile agents actually bring (after OpenMobile-2)

A month ago, an agent could use your phone only in theory: models trained on screenshots existed, but there was no public environment to test them in, no datasets, no comparable benchmark. The OpenMobile-2 paper, published at the end of October, changes precisely that: it opens up the training environments, the training recipes, and the benchmarks — and it does so with numbers worth checking.

What OpenMobile-2 is and what it made open

OpenMobile-2 is a smartphone agent close to frontier level, with the difference that the entire ecosystem around it is public. The key numbers from the OpenMobile-2 (2610.14157) paper:

• MobileGym++, the training environment: 35 commercial-style apps plus 110+ apps total, with 300+ tools across 50+ apps. It is not a set of minimal demos: it is a simulated app ecosystem where the agent learns to actually do things.
• ~12,000 SFT trajectories and 2,000+ verifiable RL tasks: the post-training datasets are open, and the RL tasks are verifiable, meaning the task says by itself whether it succeeded.
• Benchmarks: AndroidWorld 79.9, MobileWorld 50.4, SPA-Bench from 31.9 to 59.6 — nearly doubled after training. SPA-Bench was the weak point (composing long action sequences) and is exactly what the RL tasks solved.

The part that matters for builders: the code and the environments are on github.com/OpenMobile2. If you want a phone agent, you no longer start from zero: you start from a recipe that already produced a near-frontier agent.

The model: 9B that fit in 4.5GB

The agent is built on OpenMobile-2-9B, a 9-billion-parameter image-text-to-text model, derived from Qwen3.5-9B and fine-tuned on OpenMobile-2 data: Android screenshots and the apps' native tools. A 27B sibling exists, and the checkpoint supports vLLM and SGLang.

Let's do the memory math, because that is the question that decides everything. At 4-bit, each parameter weighs half a byte:

Model	Parameters	Weights at 4-bit	+ KV cache	Total VRAM/RAM
OpenMobile-2-9B	9B	~4.5GB	~1-2GB (long context)	~5.5-6.5GB
LFM3-1.7B	1.73B	~0.9GB	~0.3-0.5GB	~1.2-1.5GB

Hardware requirement	9B at 4-bit	1.7B at 4-bit
Minimum RAM/VRAM	8GB (tight)	4GB
Realistic phone	12-16GB flagship	mid-range phones
PC or GPU	any 8GB GPU (3060 and up)	recent CPU, no GPU needed

The 9B does not fit a mid-range phone, but it fits an 8GB consumer GPU: that is the model to run on the PC that pilots the agent, or on 16GB flagships. The 1.7B is the one that truly fits in your pocket.

And here comes the second piece of the day, LiquidAI LFM3-1.7B: a 1.73-billion-parameter model with 256K context, 16 languages — including English — and explicit agentic post-training. At 4-bit it fits in ~1GB of RAM, under the LFM Open v1.0 license. It is not a generalist: it is optimized for the agent loop (think → call tool → observe → retry), which is exactly the loop a phone needs, where every token costs battery.

What "on-device" means in practice

Three architectures, each with a different requirement. The choice changes everything:

1. Everything on the phone (1-3B). LFM3-1.7B or models in the same class: the agent runs locally, reads screenshots, calls Android's accessibility services. Very low latency, zero cloud, but limited capability: short-step tasks, one or two apps at a time.

2. Agent on the PC, phone as a peripheral (9B+). OpenMobile-2-9B on an 8GB GPU, observing the phone's screen and driving the touch. This is the most solid route today: generous hardware, a capable model, and the phone stays the device the user holds in hand.

3. Hybrid: small steps local, reasoning in the cloud. The small model handles the repetitive steps (classify, fill in, navigate) and sends only the steps that matter to the big model. Gartner estimates 9 of 10 agentic workflow steps are routine and that open-weight models handle them at frontier parity — it is the architecture that also makes sense for businesses (more in today's news).

And the limits?

Let's be honest about what does not work:

• A phone is not a server. 1.7B at 4-bit fits in 1GB, but the battery pays another bill: an agent loop running for minutes heats up and drains the charge. Real consumption numbers do not exist in public yet.
• Screenshots have a cost. Every screenshot is an image to process: on a 1.7B phone model that means seconds per observation. This is why long tasks stay in the territory of the 9B and up.
• Verifiable ≠ generalizable. The 2,000 verifiable RL tasks are a great base, but they cover the paper's environments. The apps you actually use, with today's popups and versions, remain a test you have to run yourself.
• AndroidWorld 79.9 is not your phone. Benchmarks measure scripted tasks in a controlled environment. The jump to real use (contacts, calendar, messaging with your own data) is still open — and it is precisely because the data stays on the device that doing it locally makes sense.

Where to start

If you want to get your hands on it, the minimal sequence:

1. Play with MobileGym++ from the OpenMobile2-Code repo: it is an environment, no phone needed. See what the agent can do and where it fails.
2. Download LFM3-1.7B from Hugging Face and run it locally: the 4-bit checkpoint fits in ~1GB, and with Ollama or llama.cpp you can serve it on a PC with 4-8GB of RAM, no GPU. If it does not work: check you downloaded the quantized checkpoint (BF16 weighs ~3.5GB) and that your drivers are up to date.
3. Test the agent loop. Ask it a two-step task — "open the calculator and compute 12×8" — and read the logs: you should see thought, tool call, observation. If the tool call is skipped, widen the context and verify the system prompt describes the available tools.
4. For the 9B you need an 8GB GPU (RTX 3060 and up): serve the checkpoint with vLLM, then point the OpenMobile-2 environment at your endpoint. An evening of setup, not a week.

In summary

After OpenMobile-2, phone agents are no longer a lab experiment: environments, datasets, and benchmarks are open, and a near-frontier agent has a public recipe you can reuse. The practical split is simple: 1.7B (~1GB of RAM, in your pocket) for short steps locally, 9B at 4-bit (~4.5GB of weights) for long tasks, on an 8GB consumer GPU. The limits remain energy, the cost of screenshots, and generalization outside the paper's environments — but the direction is clear: the phone is becoming the device where local AI is first noticed, and you can now measure for yourself how true that is.

Sources: OpenMobile-2 paper · OpenMobile-2-9B · LFM3-1.7B · OpenMobile2-Code

Article generated with AI