Alibaba's Tongyi-MAI team has published MAI-Gym, an open platform for evaluating GUI agents and training them with online reinforcement learning, along with a 9-billion-parameter model, MAI-Gym-9B, trained on it. According to the paper on arXiv (submitted October 14, 2026), the model reaches 78.4% on MobileWorld and 76.2% on OSWorld-Verified, which the authors describe as state-of-the-art among open GUI agents under 10B parameters. The model card on Hugging Face is live under Apache-2.0, but the GitHub repository says framework source code is "coming soon".
That split matters for anyone planning to try it, so this post separates what is released, what is claimed, and what you can verify today. It follows Tongyi's earlier OpenGCUA computer-use stack and fits a pattern we covered in Coinbase's fine-tuned Qwen3.5 9B beating larger models on fraud: small, specialised models trained with a task-specific loop closing the gap with frontier systems.
TL;DR: what is MAI-Gym and what can you use now?
| Question | Answer |
|---|---|
| Who built it? | Tongyi-MAI (Alibaba), 15 authors including Steven Hoi |
| What is it? | A platform for GUI agent evaluation, data collection and online RL across mobile, computer and web |
| Model size | 9B parameters, BF16 safetensors, Apache-2.0 weights |
| Reported results | 78.4% MobileWorld, 76.2% OSWorld-Verified (authors' numbers) |
| Scale claims | Up to 20,000 parallel environment instances; 10 benchmarks supported |
| Bundled content | 49 simulated apps and 2,000 execution-verified tasks (promised release) |
| Can I run the platform today? | Not yet: GitHub README says source is coming soon |
| Can I run the model today? | Yes, weights are on Hugging Face; no usage snippet on the card |
| Paper license | CC BY-NC-SA 4.0 |
Why does a GUI agent need a gym at all?
A GUI agent looks at screenshots of a phone or desktop and issues taps, clicks and keystrokes to finish a task such as booking a ticket or changing a setting. Training one with reinforcement learning is harder than training a chat model. Every training step requires a live environment that can be reset, a way to tell whether the task succeeded, and thousands of parallel copies running at once.
Most teams solve those problems separately. Evaluation harnesses live in one codebase, data collection in another, and RL training in a third. The result, the MAI-Gym authors argue, is drift: the prompt format, the action parser or the interaction loop differs between how an agent is scored and how it is trained. MAI-Gym's central design decision is to make evaluation and training share a single rollout pipeline.
What does the MAI-Gym architecture contain?
Based on the project README and paper abstract, the platform has these pieces:
- Shared agent harness. Evaluation, data collection and RL use the same prompt construction, action parser and interaction loop.
- EnvClient. One interface for allocating an instance, observing, resetting a task, executing an action and evaluating the result.
- Extension points. Agent harnesses, tasks, environment adapters and environment specifications can be added.
- Deployment targets. Kubernetes, Docker, physical devices or existing endpoints.
- Rollout reliability. Warm pools, session leases, idempotent actions and isolated verifiers, which keep long RL runs from dying on a single flaky emulator.
- Trajectory buffer. Feeds RL backends including GRPO, DAPO, GSPO, REINFORCE++, SAO and PPO through Slime.
- Dashboard. Links scores to screenshots, model outputs, actions, verifier results and environment status, so a failed run can be debugged.
The README does not say which algorithm trained MAI-Gym-9B, and the model card does not either. If you care about reproducing the result, that is the first open question to watch once the code lands.
How does it make its own training tasks?
A small shape reaching for a reward token, illustrating how MAI-Gym verifiers reward GUI agent task success
The most interesting claim is automation of task creation. The paper says MAI-Gym synthesizes resettable mocked apps, cross-app tasks and code-based verifiers. A mocked app is a lightweight imitation of a real service, for example a train-ticketing app, whose state can be wiped between attempts. A code-based verifier checks the final state directly instead of asking a model to judge a screenshot, which removes a common source of reward noise.
The release is said to include 49 simulated apps and 2,000 execution-verified tasks. The README also describes an evaluate, diagnose, synthesize, retrain loop: run the agent, find where it fails, generate new tasks aimed at those failures, and train again.
What are the numbers, and how far should you trust them?
| Result | Reported value | Source |
|---|---|---|
| MobileWorld | 78.4% | Paper abstract |
| OSWorld-Verified | 76.2% | Paper abstract |
| Real-phone transfer (train ticketing) | 28.8% to 48.1% | Paper abstract |
| Max parallel environments | 20,000 | Paper abstract |
All of these are self-reported by the authors. We could read the abstract, the project page and the model card, but the benchmark comparison chart appears only as an image, so we cannot list which competing models it was compared against or by how much. Treat "state-of-the-art under 10B" as a claim to check against the full paper tables and an independent run, not as settled.
The real-phone figure deserves the most attention. Moving from 28.8% to 48.1% on a physical phone is a 19.3-point gain, and it suggests that training on mocked environments can transfer. It is also a single reported example, on one app. Whether the effect holds across other apps, devices and languages is not shown in the sources we could access.
How does it compare with other GUI agent efforts?
Computer-use agents are moving quickly. Tongyi's own OpenGCUA takes the opposite route: a harness that improves frontier models without training them. Research such as Work2Skill turns human GUI demonstrations into reusable skills instead of weights. And broader evaluations like the Agents' Last Exam show how far general agents still are from reliable real-world work.
MAI-Gym is a third path: make training itself cheap and standardised, then ship a small model that runs locally. For teams who cannot send screenshots of internal apps to a cloud API, a 9B Apache-2.0 model is practical to host, even if it trails the largest closed systems on messy real tasks.
What are the limitations and open questions?
- Code is not out. The framework, synthesis skills, mocked apps and tasks are promised, not shipped. The GitHub page showed 21 stars and no forks at the time of writing.
- No usage guide. The Hugging Face card gives no inference snippet, prompt format or action schema, so running the model correctly today means guessing at its expected interface.
- Base model is unstated. The card tags the model
qwen3_5, which hints at the architecture, but the base is not confirmed. - Benchmark contamination. When a team builds its own tasks and trains on them, readers should ask how far those tasks overlap with the evaluation sets. The abstract does not address it.
- Safety. An agent that can operate phones and desktops can also do damage if it misreads a screen. Run any such model in a sandbox or emulator with no access to real accounts.
- Licensing. The weights are Apache-2.0, but the paper itself is CC BY-NC-SA 4.0. Check what the eventual code and task licenses say before building a product on them.
What should builders and teams take from this?
If you run internal automation, the practical question is whether a small local model can click through your own tools reliably enough to be useful. MAI-Gym does not answer that yet, because the platform is not runnable and the benchmarks are public apps rather than your software. What it does show is a recipe: build a mocked copy of the app you care about, write a verifier that reads the final state, run thousands of attempts in parallel, and let reinforcement learning push the success rate up.
If you only evaluate agents, the shared-harness idea is the lesson. A score measured with one prompt format and action parser says little about a model trained with another. Pinning both to the same code is cheap and removes a whole class of unexplained gaps between a leaderboard number and what you see in production.
If you are choosing between buying a hosted computer-use agent and training your own, a 9B open model changes the cost math, since it fits on a single modern GPU. The trade-off is reliability on unfamiliar screens, which only your own tests can measure. Keep a small set of real tasks from your workflow as a held-out check, and compare the open model against a hosted one on exactly those tasks before committing either way.
How to follow up and try it
- Read the paper abstract and the full PDF for the benchmark tables and training recipe.
- Open the project page for the overview figure and demo video.
- Download the MAI-Gym-9B weights if you want to experiment, and keep it in an emulator.
- Watch the GitHub repository for the source release before planning any training work.
If you build agents, the lesson is independent of this specific model: a deterministic reset, a code-based verifier and a single harness shared between testing and training are what make agent RL stable. You can adopt that discipline in your own evals today. For related thinking on small open models in China's ecosystem, see our look at how China's AI labs ship free models.
Related reading
- Alibaba OpenGCUA: open computer-use agent stack
- Work2Skill: turning human GUI demonstrations into agent skills
- Coinbase's Qwen3.5 9B fraud agent
- Agents' Last Exam benchmark
- China's AI playbook: free models, cheap compute
- Qwen censorship audit across 3 billion downloads
Details reflect the paper, model card and repository as of October 16, 2026; the framework code release may change what is possible.
