OpenMobile-2 is a new open stack for training AI agents that operate a phone, released by a team from Nanjing University, SenseTime, the National University of Singapore and other groups. According to the paper on arXiv (submitted October 9, 2026), the work pairs a playground of 35 rebuilt commercial apps with 11.6K demonstration trajectories, more than 2K verifiable reinforcement-learning tasks and two trained agents. The 27B agent reports 79.9 on AndroidWorld, one of the standard phone-agent benchmarks.
The point of the release is less the score than the kit: most strong phone agents are trained on private data and private environments. OpenMobile-2 tries to hand the open community the same ingredients. This post explains what is in the box, how the numbers compare with other open work we have covered, and what to verify before you build on it. It sits alongside Tongyi's MAI-Gym and the OpenGCUA computer-use stack, which attack the same bottleneck from different angles.
TL;DR: what is OpenMobile-2 and what can you use?
| Question | Answer |
|---|---|
| Who built it? | A 24-author team across Nanjing University, Xi'an Jiaotong University, NUS, SenseTime, East China Normal University and the University of Hong Kong (per the Hugging Face paper page; author-to-affiliation mapping is not given) |
| What is it? | Environments, data, recipes and agents for training phone-control models |
| Environments | MobileGym++: 35 rebuilt commercial apps, inside a playground of more than 110 apps |
| Data | OpenMobile-Data: 11.6K trajectories for supervised fine-tuning and over 2K executable RL tasks with verifiers |
| Tools | More than 300 app-native tools across 50+ apps |
| Agents | OpenMobile-2 9B and 27B, built from Qwen3.5-9B and Qwen3.6-27B per the project page |
| Headline scores | 79.9 AndroidWorld (27B), 50.4 MobileWorld, SPA-Bench 31.9 to 59.6 on real devices |
| Where is it? | The project page lists the simulator, data, checkpoints and code |
Why phone agents are stuck on environments, not models
A phone agent learns by acting: tap, scroll, type, see what changed, try again. That needs somewhere safe to act. The project page lays out the problem bluntly. Human demonstrations are fixed once recorded, emulator rollouts cover a few dozen utilities and open-source clients, and earlier simulated apps were few and shallow.
Real commercial apps are a poor training ground. They need accounts, they change, they have side effects (a real order, a real message), and you cannot reset them in a click. So open agents have mostly trained on the same small pool of simple apps, which is why they stumble when a task crosses into a shopping app or a ride-hailing flow.
OpenMobile-2's answer is environment scaling: rebuild the apps people actually use as controllable simulated clients, with persistent state, clean reset and automatic verification, then train at scale.
What is in MobileGym++?
MobileGym++ extends the earlier MobileGym simulation platform, which the project page credits and asks users to cite. It adds 35 functional re-implementations of commercial apps with persistent business state and cross-app workflows, sitting next to emulator apps configured on the same playground, for a total above 110 apps.
Three design choices matter for anyone building agents:
- Persistent state and reset. Add an item to a cart and it stays in the cart; one click restores a clean snapshot. That makes thousands of parallel RL rollouts practical.
- Programmatic verification. Each task is checked by diffing business state before and after, not by asking a model whether the run looked right. The project page describes a benchmark where half the tasks cross app boundaries and each is checked over that diff.
- Runs in the browser. The page says the whole simulated phone runs client-side with no server, its state is one snapshot, and every app-native tool can be called from a side panel. There is a live demo and a trajectory viewer for replaying recorded episodes.
What is in the data?
OpenMobile-Data holds about 11.6K demonstration trajectories for supervised fine-tuning and more than 2K executable RL tasks, each with an automatic verifier. The authors describe it as the largest open collection of verifiable RL data for mobile agents, a claim we cannot independently confirm, though the verifier-backed format is the useful part: a reward you can compute is worth more than a larger pile of demonstrations.
The trajectories come from two runtimes, simulated apps and emulator apps, feeding one pipeline. The project page shows episodes recorded with Gemini 3.1 Pro Preview run in hybrid mode, replayed tap by tap with the reasoning behind each action. That is a reminder that the demonstrations were produced by a strong model; the open agents learn from it.
App-native tools: the most interesting idea
Most phone agents only see pixels and act through taps. OpenMobile-2 adds a second action type. Apps expose selected functions as tools, and at each step the policy picks either a GUI action or a tool call from the foreground app's catalog. The catalog is attached when that app comes to the front and removed when it leaves.
Two rules keep this honest. A tool handler and the screen read and write the same store, so add_to_cart changes the cart the GUI renders. And a strict schema rejects undeclared keys, with every call returning a structured receipt or an error code.
This echoes how the Model Context Protocol gives agents structured access to software, but on a phone. The paper reports a subtle finding: tool access barely moves success before the agent has gone through hybrid supervised fine-tuning. After it, the hybrid mode gains the most and finishes in fewer steps. In plain terms, you cannot just bolt tools onto a tap-only agent and expect a jump; it has to be trained to choose between them. The reported MobileWorld MCP result supports that: 45.0 for hybrid training against 35.0 for GUI-only SFT on tools unseen in training.
The reported results
All figures below are the authors' own, taken from the abstract, the Hugging Face paper page and the project page.
| Benchmark | Result | Note |
|---|---|---|
| AndroidWorld | 79.9 (27B) | 9B rises from 54.3 (base) to 74.0 |
| MobileWorld | 50.4 | Emulator benchmark |
| SPA-Bench (real devices) | 31.9 to 59.6 (27B, base to RL) | 57.4 after hybrid SFT alone |
| MobileGym++ Bench (27B) | 57.7 to 65.6 in hybrid evaluation with hybrid SFT | New 215-task benchmark |
Two cautions. First, the 9B and 27B base models are from the Qwen family per the project page, so a lot of the capability is inherited; the contribution is the training stack. Second, MobileGym++ Bench is the authors' own benchmark on the authors' own apps, so gains there are expected. The more convincing numbers are AndroidWorld and the real-device SPA-Bench, which come from outside the playground.
For context, our MAI-Gym coverage reports 78.4% on MobileWorld for a 9B Tongyi model, a different benchmark reading from the 50.4 here, so do not compare those two figures directly: the benchmarks are labelled alike but reported in separate papers with different setups. Always check which split and harness a score used.
What drives the gains?
The analysis section of the project page highlights two effects.
Coverage beats repetition. At a fixed budget of emulator trajectories, spreading them over more apps raises success on unseen apps while the familiar apps hold steady. If you collect your own phone data, breadth across apps is a better use of budget than more runs of the same few.
Tools pay off after hybrid training. As above, the gain appears only once the policy has seen tool use in training.
Both are practical lessons independent of this particular release.
How to try it
The project page lists four resources: the MobileGym++ simulator, tools and benchmark; OpenMobile-Data on Hugging Face; checkpoints of both agents after each training stage; and code for data collection, SFT and RL recipes plus the evaluation harness. A sensible path:
- Open the live demo and the trajectory viewer on the project page to see what an episode looks like.
- Pull the released checkpoints and the evaluation harness, and re-run AndroidWorld before trusting the headline.
- If you want to train, start with the supervised fine-tuning recipe on the 11.6K trajectories, then add RL on the verifiable tasks.
The project page points to GitHub repositories (OpenMobile2-Code and MobileGym-plusplus), the OpenMobile-Data dataset and the OpenMobile-2 models on Hugging Face. The arXiv abstract itself lists only the project page, so follow the links from there. We have not run the code ourselves.
How it fits with other open GUI-agent work
The past month has been busy for open GUI agents. MAI-Gym offers a unified evaluation and RL platform with a 9B model. OpenGCUA is a harness for desktop computer use. Work2Skill turns human demonstrations into reusable skills. Berkeley's Agents' Last Exam shows how far agents still are from reliable general tasks. And on-device work like Gemma 4 E4B driving iOS shows the same direction on small models.
What sets OpenMobile-2 apart is its emphasis on rebuilt commercial apps and verifiable tasks specific to phones. If MAI-Gym is a general gym, OpenMobile-2 is a phone-first one, with its own app catalogue and hybrid tool layer.
Limitations and open questions
- Self-reported results. No independent replication yet. Check the numbers against your own run.
- Simulation gap. Rebuilt apps are approximations. The SPA-Bench result suggests transfer, but real apps change weekly, add captchas and require logins that the simulator does not model.
- Safety. A phone agent that can tap anywhere can also spend money or send messages. The simulated environment is safe by construction; a deployed agent is not. Gate irreversible actions behind confirmation and keep it off accounts you cannot afford to lose.
- Licensing. Rebuilt commercial apps raise questions about trademarks and terms of use. The project page states Apache-2.0 for the MobileGym++ code but CC BY-NC 4.0 for its data, so the non-commercial restriction matters if you plan commercial use; check each repository's own license too.
- Base model dependence. Much of the capability comes from the Qwen base models, and the demonstration trajectories came from a strong proprietary model; check the terms on that.
What people are asking
Is this a product I can install on my phone?
No. It is a research stack for training and evaluating agents. You would need to wrap a trained model in a harness with device access to run it on a real phone.
Why release a 9B and a 27B?
The 9B is cheap enough to fine-tune and run locally; the 27B shows the ceiling of the recipe. The Coinbase write-up we covered, a fine-tuned Qwen3.5 9B beating larger models on a narrow task, makes the same case for small specialised models.
Does this help me build agents on top of an API model?
Indirectly. The environment, the benchmark and the tool-schema design are reusable even if you never train a model, and the finding that tools need hybrid training first applies to prompt-based agents less directly.
Bottom line
OpenMobile-2 is a credible, well-documented attempt to open up the environments and data behind phone agents, with sensible design choices: persistent state, programmatic verifiers, and a tool layer that shares state with the GUI. The 79.9 AndroidWorld score is the authors' claim, and the real test is whether others reproduce it and build on the data. If you work on agents that operate software, the project page and the trajectory viewer are worth an hour of your time.
Related reading
- MAI-Gym: Alibaba Tongyi opens a GUI agent gym and a 9B model
- OpenGCUA: Alibaba's open stack for computer-use agents
- Work2Skill: turning GUI demonstrations into agent skills
- Agents' Last Exam benchmark
- Gemma 4 E4B and iOS automation
- What is MCP?
- Coinbase's fine-tuned Qwen3.5 9B on fraud
Figures are as reported in the paper and project page on October 19, 2026 and may change in later versions.