MAI-Gym: An Open All-in-One Platform for GUI Agent Evaluation and RL Training across Mobile and Computer Environments

# MAI-Gym: An Open All-in-One Platform for GUI Agent Evaluation and RL Training across Mobile and Computer Environments
Source: [https://arxiv.org/html/2610.20939](https://arxiv.org/html/2610.20939)
Alibaba Token Hub, Alibaba Group††thanks:MAI\-UI Team\. MAI\-GYM was used to train Qwen\-UI\-Agent˜\[[Zhou et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib1)\]\. See[Contributions](https://arxiv.org/html/2610.20939#S7)for the full author list\.

###### Abstract

Online reinforcement learning \(RL\) with verifiable rewards has driven rapid progress in mathematics, coding, and tool use, but scaling this success to GUI agents remains challenging due to the high cost of interactive environments and the scarcity of realistic training tasks\. We introduceMAI\-Gym, an open all\-in\-one platform that unifies GUI agent evaluation, data collection, and online RL training across mobile, computer, and web environments\. Through a shared rollout pipeline, MAI\-Gym ensures consistent agent behavior across evaluation and training, supports ten established benchmarks, and scales to20,00020\{,\}000parallel environment instances\. Beyond scalable infrastructure, MAI\-Gym enables automated synthesis of diverse GUI applications and challenging tasks, including resettable mocked apps and coherent cross\-app worlds with execution\-validated task verifiers\. Using MAI\-Gym, we trainMAI\-Gym\-9B, a unified 9B agent for mobile and computer use, achievingstate\-of\-the\-art performance among open GUI agents under 10B parameters:78\.4%78\.4\\%on MobileWorld and76\.2%76\.2\\%on OSWorld\-Verified\. Importantly, RL in a mocked train\-ticketing app transfers to its real\-world counterpart, improving task success on a physical phone from28\.8%28\.8\\%to48\.1%48\.1\\%\. We release the framework, synthesis skills, mocked apps,2,0002\{,\}000verified tasks, and the model checkpoint to support reproducible research and further advances in scalable GUI agent training\.

![Refer to caption](https://arxiv.org/html/2610.20939v1/fig1_mai_gym_overview.png)Figure 1:Overview of MAI\-Gym\.Left: online GUI environments\. Center: core capabilities\. Bottom: the evaluation–diagnosis–synthesis–retraining loop\. Right: performance comparison of MAI\-Gym\-9B with models of different sizes on MobileWorld and OSWorld\-Verified\.Contents

## 1Introduction

Reinforcement learning \(RL\) with verifiable rewards has driven rapid progress in mathematics, coding, and tool use\[[DeepSeek\-AI, 2025](https://arxiv.org/html/2610.20939#bib.bib2),[Pan et al\., 2024](https://arxiv.org/html/2610.20939#bib.bib3),[Jain et al\., 2025](https://arxiv.org/html/2610.20939#bib.bib4),[Yang et al\., 2025](https://arxiv.org/html/2610.20939#bib.bib5),[RUC\-NLPIR, 2026](https://arxiv.org/html/2610.20939#bib.bib6),[Dong et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib7)\]\. Beyond advances in training algorithms, this progress relies on environments that are inexpensive to execute, easy to verify, and rich in meaningful tasks\. Mathematical problems often admit automatic answer checking, while software repositories provide executable tasks with files and tests\. Such environments can efficiently support large\-scale training and evaluation, as many tasks can share the same verification or execution infrastructure\. Recent work has extended online RL to GUI agents for mobile and computer use\[[Bai et al\., 2024](https://arxiv.org/html/2610.20939#bib.bib8),[THUDM, 2025](https://arxiv.org/html/2610.20939#bib.bib9),[Qi et al\., 2025](https://arxiv.org/html/2610.20939#bib.bib10),[Lai et al\., 2025](https://arxiv.org/html/2610.20939#bib.bib11),[ByteDance Seed, 2025](https://arxiv.org/html/2610.20939#bib.bib12)\]\. However,scaling GUI\-based RL to a comparable level remains challenging due to the unique demands of interactive GUI environments\.

Bringing this success to GUI agents presents two fundamental challenges\.First, GUI environments are expensive to scale and difficult to maintain consistently\.Unlike a code sandbox, a GUI instance cannot be shared by concurrent attempts, because the agent acts on the whole screen and changes the device’s files and settings\. Each attempt therefore needs its own phone, computer, or browser instance in a known initial state, and makes many screenshot\-based model calls before the instance is reset\. Large\-scale training runs thousands of such instances at once\. Because platforms and benchmarks differ, evaluation and training easily end up with separate agent implementations that drift apart, so measured performance can depend on the harness as well as the model\[[Wu et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib13)\]\. Open infrastructure is therefore needed that runs environments at scale and keeps agent behavior the same in evaluation and training\.Second, realistic GUI learning requires diverse tasks grounded in coherent and resettable environment states\.Unlike isolated question\-answering tasks, real\-world GUI workflows often depend on information distributed across multiple applications and files\. For example, replying to an email with the total from an attached invoice requires the relevant email, attachment, and invoice contents to exist consistently in the environment\. However, existing task synthesis approaches often rely on isolated input files or shared sample data \(Table[1](https://arxiv.org/html/2610.20939#S1.T1)\), limiting the diversity and realism of generated tasks\. Furthermore, real\-world applications involving transactions can be unsafe or impractical for training, while evaluating adaptation to unfamiliar interfaces requires entirely new applications\. Addressing these challenges calls for both scalable execution infrastructure and automated construction of realistic, resettable GUI environments\.

Existing GUI gyms typically address only part of this problem \(Table[1](https://arxiv.org/html/2610.20939#S1.T1)\)\. Infrastructure\-focused gyms make evaluation or training easy to reproduce\[[Le Sellier De Chezelles et al\., 2025](https://arxiv.org/html/2610.20939#bib.bib14),[Bai et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib15),[Wu et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib16),[Lv et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib17),[Tang et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib18)\], but each covers only one platform, and those that release training code run at most hundreds of environments in parallel\. In contrast, data\-oriented gyms\[[Wang et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib19),[Aggarwal et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib20),[Cao et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib21),[Liu et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib22)\]curate many new apps and tasks, but release neither training code nor a way to run existing benchmarks\. These limitations are closely intertwined: scalable infrastructure requires a continuous supply of meaningful tasks, while synthesized tasks are most useful when they can be efficiently evaluated and used for learning\.A unified platform that combines scalable execution with automated environment and task synthesis is therefore essential for advancing GUI agent RL\.

To this end, we introduceMAI\-Gym, an open all\-in\-one platform for GUI agent evaluation and online RL training across mobile, computer, and web environments \(Figure[1](https://arxiv.org/html/2610.20939#S0.F1)\)\. Its central design choice is a shared rollout path: for a given agent and environment, evaluation, data collection, and training reuse the same observation processing, context construction, and action execution, so a fix to the agent code reaches all three at once\. With a single command, researchers can evaluate a local or API\-served model on ten existing benchmarks \(three mobile, four computer, and three web\) and inspect every trajectory in a dashboard\. With another, they can launch online RL training, including joint training on mobile and computer tasks\. The platform automatically manages environment provisioning, isolation, resetting, and recovery, and we have run it with20,00020\{,\}000environment instances in parallel\.

Beyond scalable infrastructure, MAI\-Gym enables automated synthesis of diverse applications and realistic, challenging tasks, expanding GUI learning beyond fixed benchmarks and environments\.At the app level, coding agents construct*mocked apps*: self\-contained applications with resettable backends\. They come in two kinds:*real\-world clones*of existing services, enabling safe practice of transactional workflows, and*novel apps*with entirely new interfaces for studying agent adaptation\. At the task level, MAI\-Gym introducescross\-app world constructionwithin MobileWorld and OSWorld environments\. Rather than generating isolated tasks, it first constructs a coherent world from a persona and scenario, populating multiple applications with interconnected files and records that share consistent people, events, and facts\. Tasks are then generated from this world, requiring agents to retrieve, reason over, and integrate information across applications\. To ensure reliable evaluation, task requirements are established before generating code\-based verifiers, which are subsequently validated through execution on initial, completed, and reset states\. Furthermore, failure\-driven synthesis uses diagnoses of unsuccessful agent trajectories to target model weaknesses\. All synthesized applications and tasks share the same execution interface as existing benchmarks,forming a unified workflow for environment synthesis, evaluation, and online RL training\.

Table 1:Comparison with representative online GUI gyms\.SystemScopeOpen\-source InfrastructureTasks & EnvironmentsPlatformsBenchmarkevaluationOnline RL\(\# envs\)NewenvironmentsNew World\(files & app state\)RewardBrowserGym\[[Le Sellier De Chezelles et al\., 2025](https://arxiv.org/html/2610.20939#bib.bib14)\]88\( \)×\\times×\\times×\\timesCodeWebGym\[[Bai et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib15)\]×\\times✓\\checkmark256256×\\times×\\timesVLMMobileGym\[[Wu et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib16)\]s×\\times✓\\checkmark256256Mocked appsPre\-defined WorldCodeGUI\-Genesis\[[Cao et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib21)\]s×\\times×\\times†Mocked appsGenerated per task, in app codeCodePhoneWorld\[[Liu et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib22)\]×\\times×\\times†Mocked appsPre\-defined WorldCodeCUA\-Gym\[[Wang et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib19)\]×\\times×\\times†Mocked websitesGenerated per task, lightweightCodeGym\-Anything\[[Aggarwal et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib20)\]×\\times×\\timesReal softwarePre\-defined WorldVLMSCALECUA\[[Lv et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib17)\]22\( \)✓\\checkmark600600×\\times×\\timesCodeMAI\-Gym𝟏𝟎\\mathbf\{10\}\(3 4 3 \)✓\\checkmark20,000\\mathbf\{20\{,\}000\}Mocked apps & websitesGenerated cross\-app worlds,shared by many tasksCode & VLM
sSimulated in a browser\.†RL was run; code not released\.

Using MAI\-Gym, we trainMAI\-Gym\-9B, a unified 9B policy for mobile and computer use, in one joint online RL run on synthesized tasks, and evaluate it on seven benchmarks\. On MobileWorld and OSWorld\-Verified, whose tasks never appear in training, it achieves state\-of\-the\-art results among open GUI agents of comparable size\. Moreover, RL consistently improves performance over the SFT warm\-up checkpoint across all five benchmarks outside its training environments, demonstrating generalization beyond them\. We further investigate thesim\-to\-real transferabilityof capabilities learned in synthesized applications\. Notably, training in real\-world clones transfers effectively to the real apps: RL in the clone of a train\-ticketing app improves success on5252tasks in the real app, evaluated on a physical phone, from28\.8%28\.8\\%to48\.1%48\.1\\%\. Training on entirely novel apps also improves held\-out task success from25\.8%25\.8\\%to45\.2%45\.2\\%, highlighting the potential of synthesized environments for learning generalizable GUI capabilities\. To sum up, our contributions are fourfold:

- •A Unified and Scalable Platform for GUI Agent Evaluation and Online RL\.We introduce MAI\-Gym, an open all\-in\-one platform that unifies evaluation, data collection, and online RL training across mobile, computer, and web through shared environment interfaces and agent harnesses\. It supports ten benchmarks and demonstrates scalability to20,00020\{,\}000parallel environments \(Section[3](https://arxiv.org/html/2610.20939#S3)\)\.
- •Automated Application and Task Synthesis for Scalable GUI Learning\.We introduce automated synthesis of resettable mocked applications and challenging cross\-app tasks grounded in coherent environment states\. Our synthesis pipeline constructs interconnected application data, generates execution\-validated task verifiers, and supports failure\-driven task generation \(Section[3\.4](https://arxiv.org/html/2610.20939#S3.SS4)\)\.
- •The Strongest Open\-Source GUI Agent under 10B Parameters\.We release MAI\-Gym\-9B, a unified mobile and computer agent achieving78\.4%78\.4\\%on MobileWorld and76\.2%76\.2\\%on OSWorld\-Verified, setting new state\-of\-the\-art results among open GUI agents under 10B parameters\. It outperforms strong open baselines, includingUI\-Venus\-2\-9B\[[Venus Team, 2026](https://arxiv.org/html/2610.20939#bib.bib23)\]\(75\.275\.2/70\.870\.8\),SCALECUA\-Qwen3\.5\-9B\[[Lv et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib17)\]\(12\.812\.8/68\.768\.7\), and even the largerGUI\-Owl\-1\.5\-32B\[[Xu et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib24)\]\(43\.943\.9/56\.556\.5\) \(Section[4](https://arxiv.org/html/2610.20939#S4)\)\.
- •Open Resources for Reproducible GUI Research\.We release the framework, including evaluation harnesses and online\-RL training code; synthesis skills;4949mocked apps with accompanying tasks; and2,0002\{,\}000tasks with execution\-tested verifiers,1,0001\{,\}000each for MobileWorld and OSWorld\.

## 2Preliminaries

This section defines the executable tasks that MAI\-Gym runs \(Section[2\.1](https://arxiv.org/html/2610.20939#S2.SS1)\), the agent harness and its GUI and CLI action space \(Section[2\.2](https://arxiv.org/html/2610.20939#S2.SS2)\), and online RL over these tasks \(Section[2\.3](https://arxiv.org/html/2610.20939#S2.SS3)\)\.

### 2\.1Executable Tasks in GUI Agents

An*environment*ℰ\\mathcal\{E\}is a software system in which an agent acts, such as an Android device, a desktop virtual machine, or a browser application\. An*executable task*is

x=\(ℰ,s0,g,V\),x=\(\\mathcal\{E\},\\,s\_\{0\},\\,g,\\,V\),\(1\)with an initial states0s\_\{0\}, a natural\-language instructiongg, and a verifierVV\. The initial state holds the application records, files, accounts, and settings, such as the current date, that are loaded before the episode begins\. It is part of the task: the same instruction under a differents0s\_\{0\}can have a different correct outcome\. Each attempt runs in its own isolated*instance*ofℰ\\mathcal\{E\}, reset tos0s\_\{0\}\.

##### Verification\.

The verifier checks the final statesTs\_\{T\}and, when needed, the trajectoryτ\\tau\. We express a task’s requirements as binary criteriabj​\(sT,τ\)∈\{0,1\}b\_\{j\}\(s\_\{T\},\\tau\)\\in\\\{0,1\\\}with weightswj\>0w\_\{j\}\>0, of which a subset𝒞\\mathcal\{C\}is required\. The reward and task success are

r=∑jwj​bj∑jwj∈\[0,1\],S=∏j∈𝒞bj,r=\\frac\{\\sum\_\{j\}w\_\{j\}b\_\{j\}\}\{\\sum\_\{j\}w\_\{j\}\}\\in\[0,1\],\\qquad S=\\prod\_\{j\\in\\mathcal\{C\}\}b\_\{j\},\(2\)so the reward gives partial credit while success requires every required criterion\. Criteria can be checked by code that reads application or system state, or by a VLM judge; MAI\-Gym supports both\.

### 2\.2Agent Harness and Action Space

An agent is a policy together with its*harness*, the code between the policy and the environment\. At steptt, the harness builds the contextctc\_\{t\}from the instruction, the interaction history, and the current observationoto\_\{t\}, a screenshot together with any command output\. It then invokes the policy, parses the outputyty\_\{t\}into actions, and executes them\. Changing the harness alone can change a fixed model’s benchmark score\[[Wu et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib13)\], which motivates the shared harness of Section[3\.1](https://arxiv.org/html/2610.20939#S3.SS1)\.

Table 2:Agent observations, context, and actions\.AgentObservationoto\_\{t\}Contextctc\_\{t\}Actionsyty\_\{t\}GUI agentScreenshotLastkkscreenshots \+ text historyClick, type, drag, …CLI agentCommand outputText history, often summarizedShell commandsMAI\-GymScreenshot \+ command outputCustomized by the harnessBatched GUI \+ CLI actions##### GUI and CLI Actions\.

MAI\-Gym agents act through both the GUI and the command line \(Table[2](https://arxiv.org/html/2610.20939#S2.T2)\)\. GUI actions follow Qwen\-UI\-Agent\[[Zhou et al\., 2026](https://arxiv.org/html/2610.20939#bib.bib1)\]\(Appendix[A\.3](https://arxiv.org/html/2610.20939#A1.SS3)\) and work with any application on screen\. On computers, agents can also run shell commands and choose the interface for each action: one command can locate, edit, or move files that would take many GUI steps, while the GUI remains necessary for applications without a command\-line interface\. Mobile and web environments use GUI actions only\. A failed command returns its error as feedback rather than ending the episode\. A*step*is one model decision and may emit an ordered batch of GUI and CLI actions; step limits and history windows count steps\. Theterminateaction ends the episode with a final answer and a claimed success or failure\.

### 2\.3Online Agentic RL

A*rollout*is one attempt at a task: an instance is reset tos0s\_\{0\}, the policy samplesyt∼πθ\(⋅∣ct\)y\_\{t\}\\sim\\pi\_\{\\theta\}\(\\cdot\\mid c\_\{t\}\)at each step, and the episode ends onterminateor at the step limit, yielding a trajectoryτ=\(c1,y1,…,cT,yT\)\\tau=\(c\_\{1\},y\_\{1\},\\ldots,c\_\{T\},y\_\{T\}\)and a single terminal rewardrr\. Online RL maximizesJ\(θ\)=𝔼x∼𝒳𝔼τ∼πθ\(⋅∣x\)\[r\(x,τ\)\]J\(\\theta\)=\\mathbb\{E\}\_\{x\\sim\\mathcal\{X\}\}\\,\\mathbb\{E\}\_\{\\tau\\sim\\pi\_\{\\theta\}\(\\cdot\\mid x\)\}\[r\(x,\\tau\)\]over a task pool𝒳\\mathcal\{X\}with rollouts from the current policy\. Unlike training on fixed demonstrations, every update needs fresh rollouts, so instances must be reset, isolated, and served at scale throughout training\.

Our main recipe uses GRPO\[[Shao et al\., 2024](https://arxiv.org/html/2610.20939#bib.bib25)\], which replaces a learned value function with a group baseline: each task is attemptedGGtimes, and trajectoryiiwith rewardrir\_\{i\}receives the advantage

Ai=ri−mean\(r1:G\)std\(r1:G\)\+δ,A\_\{i\}=\\frac\{r\_\{i\}\-\\operatorname\{mean\}\(r\_\{1:G\}\)\}\{\\operatorname\{std\}\(r\_\{1:G\}\)\+\\delta\},\(3\)with a smallδ\>0\\delta\>0, shared by all of its policy\-generated tokens\. A group whose attempts all receive the same reward has zero advantage and contributes no gradient, so rollouts are best spent on tasks that the policy sometimes solves \(Section[3\.5](https://arxiv.org/html/2610.20939#S3.SS5)\)\.

## 3MAI\-Gym

Online RL for GUI agents usually requires building a separate system for each platform: environments that reset reliably at scale, an agent loop for every benchmark, a pool of tasks with trustworthy rewards, and a trainer for long multimodal trajectories\. MAI\-Gym replaces these with one open codebase, organized around a single rollout path that evaluation, data collection, and training all share\.

We describe MAI\-Gym in two parts\. The first covers its foundation: the system architecture \(Section[3\.1](https://arxiv.org/html/2610.20939#S3.SS1)\) and the mechanisms that make rollouts scalable and efficient \(Section[3\.2](https://arxiv.org/html/2610.20939#S3.SS2)\)\. The second follows the improvement loop of Figure[1](https://arxiv.org/html/2610.20939#S0.F1), in which MAI\-Gym evaluates the model \(Section[3\.3](https://arxiv.org/html/2610.20939#S3.SS3)\), synthesizes environments and tasks that target its weaknesses \(Section[3\.4](https://arxiv.org/html/2610.20939#S3.SS4)\), and retrains it on them \(Section[3\.5](https://arxiv.org/html/2610.20939#S3.SS5)\)\.

### 3\.1System Architecture

Figure[2](https://arxiv.org/html/2610.20939#S3.F2)shows MAI\-Gym’s architecture and its two design choices\. First, all workloads share one rollout path and one agent harness, so evaluation, data collection, and training see the same agent \(left\)\. Second, agents reach every environment only through the environment manager, which exposes a common interface and hides environment and deployment details \(center\)\. Deployment backends host mobile, computer, and web instances \(right\), and a dashboard reports system status \(bottom\)\.

Figure 2:Architecture of MAI\-Gym\.Left: evaluation and RL training share one harness and rollout path; data collection uses the same path without the policy update\. Center: the environment manager provides a common interface\. Right: mobile, computer, and web instances hosted by deployment backends\. Bottom: the dashboard\. Purple tags mark extension points\.##### One Harness, One Rollout Path\.

The same model can score differently under different harnesses\. When evaluation, data collection, and training each keep their own copy of the agent, these copies drift apart in screenshot preprocessing, history truncation, prompt templates, or action parsing\. If the training copy keeps the last five screenshots and the evaluation copy keeps ten, we evaluate a different agent from the one we trained\. We repeatedly saw such drift as unexplained gaps between training reward and evaluation score\. MAI\-Gym therefore keeps one harness for each environment and agent configuration and runs it on a single rollout path\. The rollout scheduler queues task attempts\. For each attempt, a rollout worker obtains an instance through the EnvClient and runs the harness, which queries the inference engine at every step; the worker then writes the trajectory and its verifier reward to the trajectory buffer\. The three workloads differ only in how they use these trajectories:*evaluation*scores and aggregates them,*data collection*stores them, for example as supervised fine\-tuning data, and*RL training*uses them to update the policy and then synchronizes the new weights to the inference engine\. A fix to the harness therefore reaches all three workloads at once\.

##### Environment Manager\.

The environment manager exposes five operations: request instances, observe, reset to a task, step, and evaluate \(Appendix[A\.2](https://arxiv.org/html/2610.20939#A1.SS2)\)\. Behind these operations, it provisions and allocates instances, manages each session from initialization through reset and cleanup, registers tasks, computes rewards with code verifiers or VLM judges, persists trajectories, and reports status to the dashboard\. Environment adapters translate the operations into each environment’s native APIs and keep the benchmark’s own task initialization and verification; nothing in an adapter refers to RL\. Deployment backends host instances on Kubernetes or Docker, or connect to existing phones, computers, and browser sessions\.

##### Extension Points\.

The purple tags in Figure[2](https://arxiv.org/html/2610.20939#S3.F2)mark four places where users extend MAI\-Gym:

- •Add Agent Harness\.A new harness defines context construction, policy invocation, output parsing, and action dispatch, and all three workloads use it unchanged\.
- •Add Tasks\.A new task supplies an instruction, required assets, a setup procedure, and a verifier for an existing environment; the synthesis pipeline of Section[3\.4](https://arxiv.org/html/2610.20939#S3.SS4)creates such tasks at scale\.
- •Integrate Environments\.An adapter maps an external benchmark’s initialization, observation, action execution, verification, and cleanup to the environment manager’s operations\. The benchmark keeps its native behavior and gains MAI\-Gym’s instance management and rollout path\.
- •Customize Environments\.An environment specification lists an environment’s applications, supporting services, and launch and restore configuration\. Adding an app to MobileWorld, for example, creates a new variant that reuses the existing adapter and deployment backend\.

### 3\.2Scalable and Efficient Rollouts

GUI rollouts cost far more than text rollouts in three ways\. Each attempt needs its own phone or desktop in an exact initial state; a training run keeps thousands of such instances busy at once, and some of them fail; and each attempt makes tens of multimodal inference calls before the verifier returns a single reward\. MAI\-Gym provides reliable resets, scalable provisioning, and efficient multi\-turn inference\.

##### Reliable Task Resets\.

Because every attempt must start from exactly the task’s initial states0s\_\{0\}and an online RL run resets environments many thousands of times, we adapt each platform’s execution stack for this workload\. On mobile, the standard Android emulator needs nested virtualization, which most container clusters lack, so we use ReDroid\[[Remote Android Project, 2024](https://arxiv.org/html/2610.20939#bib.bib26)\]to run each phone as an ordinary container directly on the host kernel; each reset restores a golden/datasnapshot with the matching service state\. On desktop, most failures come from virtual machines that report ready too early and from concurrent attempts that interfere with each other; we add stricter readiness checks, recover containers that fail mid\-attempt, give each instance its own service ports and artifact cache, and wait for applications to finish starting and saving so the verifier does not read a half\-written state\. On the web, headless Chromium hosts both real websites and locally served apps, including our mocked apps \(Section[3\.4\.1](https://arxiv.org/html/2610.20939#S3.SS4.SSS1)\)\. With these adaptations, a reset, including queueing and task preparation, takes a median of165165,3737, and66seconds on Android, desktop virtual machines, and the browser, respectively \(Section[4\.3\.1](https://arxiv.org/html/2610.20939#S4.SS3.SSS1)\)\.

##### Fast Provisioning at Scale\.

We have tested MAI\-Gym with20,00020\{,\}000instances running in parallel, and1,0001\{,\}000fresh instances come up in328\.4328\.4seconds for mobile and88\.988\.9seconds for computer \(Section[4\.3\.1](https://arxiv.org/html/2610.20939#S4.SS3.SSS1)\)\. Three design choices make this possible\.*First*, provisioning is asynchronous: the environment manager starts instances independently of the requests that asked for them and does not hold a thread while it waits on each backend operation\.*Second*, warm pools keep initialized instances ready, and an instance accepts work only after its initialization and registration complete\.*Third*, screenshots travel through object storage rather than inside control messages, which keeps the manager’s traffic small as the fleet grows\. At this scale, some instances, workers, and network calls fail in every run, so MAI\-Gym also confines each failure to the session where it occurs: session leases reject actions from replaced workers, action identifiers make a retried action take effect only once, every operation has a deadline, and verifiers run in separate process groups with resource limits\. MAI\-Gym records environment failures separately from zero rewards, so infrastructure faults do not enter the training signal\.

##### Efficient Multi\-Turn Inference\.

Figure[3](https://arxiv.org/html/2610.20939#S3.F3)a shows how MAI\-Gym builds each prompt’s history so that the inference engine can reuse its KV cache\.

Figure 3:Window\-wise history for rollout and training\.Each turn is one step\. WithK=10K=10steps per window andO=2O=2overlapping steps, \(a\) appending history within a window enables KV\-cache reuse; older screenshots become placeholders at window boundaries, while text is retained\. \(b\) Training reuses these windows, applying loss only to new outputs \(hatched\)\. S/T: system prompt and task instruction\.Consecutive prompts of a trajectory share most of their history, but the engine can reuse cached computation only when a new prompt begins with exactly the tokens of a cached one\. The common last\-kkpolicy, which keeps thekkmost recent screenshots, breaks this at every step: dropping the oldest screenshot changes the start of the prompt, so the engine must prefill almost the entire history again\. MAI\-Gym instead groups steps into windows ofKKsteps that overlap byOOsteps\. Within a window, new screenshots and text are only appended, so each prompt extends the previous one\. At a window boundary, earlier screenshots collapse into placeholders while their text stays\. WithK=10K=10andO=2O=2, turn 11 starts a new window: screenshots 1–8 become placeholders, turns 9–10 carry over, and turn 12 reuses the cached prefix of turn 11\. The prefix thus changes once everyK−OK\-Osteps rather than at every step\. Because the policy sees betweenO\+1O\+1andKKrecent screenshots, the window size is part of the training recipe, and training reuses the same windows as samples \(Figure[3](https://arxiv.org/html/2610.20939#S3.F3)b; Section[3\.5](https://arxiv.org/html/2610.20939#S3.SS5)\)\. MAI\-Gym sends the first request of each trajectory to the least\-loaded engine and routes the trajectory’s later requests to the same engine, which holds its cache\. If that engine fails, MAI\-Gym moves the trajectory to a healthy engine, which rebuilds the cache\.

### 3\.3Evaluation and Diagnostics

Evaluation and diagnosis are the first two steps of the improvement loop\. MAI\-Gym supports them with three tools: one\-command evaluation across benchmarks, a dashboard that traces each score back to its screenshots, and agent\-driven diagnosis that turns failed attempts into targets for task synthesis\.

##### One\-Command Evaluation\.

A single command evaluates a local checkpoint or an API\-served model on any set of registered benchmarks, including the ten in Table[3](https://arxiv.org/html/2610.20939#S3.T3):

`\\iow\_now:Ne˝\\iow\_now:Ne˝$ mai\-gym eval –model <checkpoint or API endpoint\> \\\\iow\_now:Ne˝ –benchmarks mobileworld androidworld mobilegym \\\\iow\_now:Ne˝ osworld\-verified osworld\-2 macagentbench mypcbench \\\\iow\_now:Ne˝ webvoyager onlinemind2web webarena \\\\iow\_now:Ne˝ –trials 3 The command starts instances in parallel and runs every task through the same harness used in training, so a reported score measures the agent being improved\. It preserves each benchmark’s step limit, verifier, and native metric, and also reports pass@nn and passn, the fractions of tasks solved in at least one and in all of nn trials\. When an attempt ends in an environment failure rather than an agent failure, the command reruns it, so infrastructure faults do not lower a model’s score; the dashboard still shows every rerun\.`

`Table 3: Evaluation benchmarks supported by MAI\-Gym\. Domain Benchmark Tasks Max steps Metric Mobile MobileWorld \(GUI\-only\) \[MobileWorld Team, 2025\] 117117 100100 Success rate AndroidWorld \[Rawles et al\., 2025\] 116116 Task\-dependent Success rate MobileGym \[Wu et al\., 2026\] 256256 100100 binary / partial Computer OSWorld\-Verified \[Xie et al\., 2024\] 361361 100100 Success rate OSWorld 2\.0 \[Yuan et al\., 2026\] 108108 500500 binary / partial MacAgentBench \[Fu et al\., 2026\] 676676 5050 Success rate MyPCBench \[Jang et al\., 2026\] 184184 100100 Perfect\-task rate Web WebVoyager \[He et al\., 2024\] 643643 1515 Success rate OnlineMind2Web \[Xue et al\., 2025\] 123123 5050 Success rate WebArena \[Zhou et al\., 2024\] 812812 3030 Success rate``Dashboard\. A score or a reward curve says that an agent fails, not why: a low reward can come from a wrong decision, an unexpected screen, or an emulator that never finished booting, and each cause calls for a different fix\. The MAI\-Gym dashboard \(Appendix A\.1\) answers three questions\. Is the fleet healthy? It shows instance availability, active sessions, and throughput over time\. Which tasks explain a score? It links each run and benchmark summary to per\-task results and to every attempt, including reruns\. Where did an attempt go wrong? It replays the attempt step by step, aligning each screenshot with the model’s output, the executed actions, and the verifier’s result, so that agent failures stand apart from environment failures and timeouts\. Agent\-Driven Diagnosis\. Inspecting trajectories by hand does not scale to thousands of attempts across ten benchmarks, so MAI\-Gym hands this work to coding agents\. It exposes evaluation records through diagnosis endpoints, which a coding agent such as Claude Code or Codex \[Anthropic, 2026, OpenAI, 2026\] queries to retrieve a model’s trajectories and rewards\. The agent compares successful and failed attempts and analyzes the model’s behavior at three levels: individual actions, whole trajectories, and the knowledge that tasks require\. The task generator takes the resulting report as input and composes tasks that exercise the weak capabilities \(Section 3\.4\.3\), so the model’s own failures decide what it trains on next\. MAI\-Gym supports running this loop repeatedly; this paper does not yet evaluate repeated rounds\. 3\.4 Synthesizing Environments and Tasks Diagnosis tells MAI\-Gym what a model needs to practice; synthesis supplies the practice\. MAI\-Gym synthesizes every component of an executable task x=\(ℰ,s0,g,V\)x=\(\\mathcal\{E\},s\_\{0\},g,V\): mocked apps provide new environments ℰ\\mathcal\{E\} \(Section 3\.4\.1\), cross\-app world construction supplies coherent initial states s0s\_\{0\} \(Section 3\.4\.2\), and task and verifier synthesis derives instructions gg and tested verifiers VV \(Section 3\.4\.3\)\. Each stage is an agent skill, a set of instructions that a coding agent such as Claude Code follows, and we release the skills together with the apps and tasks they produce\. 3\.4\.1 Environment Synthesis Environment synthesis builds mocked apps: self\-contained applications with resettable backends, so that a policy can repeat a workflow thousands of times without side effects\. Mocked apps come in two kinds, depending on whether a real app serves as the reference\. Figure 4: Real apps and their MAI\-Gym clones\. Top: real\-app screens\. Bottom: corresponding clones with independent data\. CCB: China Construction Bank\. Real\-World Clones\. Many everyday apps act on the real world: they move money, place orders, or publish posts, and these actions cannot be undone, so a policy cannot practice in them thousands of times\. We therefore build real\-world clones of seven such apps, spanning travel \(12306\), banking \(China Construction Bank\), ride hailing \(DiDi\), food delivery \(Meituan\), local services \(Dianping\), and social media \(Douyin and Xiaohongshu\)\. A coding agent builds each clone from scratch with the real app as a reference\. The clone reproduces the app’s main user flows, such as booking, ordering, and payment, over a backend that resets between attempts\. Testers check each clone against the real app by carrying out the same tasks in both and comparing the screens along the way \(Appendix A\.7\.1\); Figure 4 shows one screen of each clone next to the real app\. The task pipeline below supplies their tasks, and Section 4\.3\.4 shows that training in the 12306 clone improves success in the real app on a physical phone\. Novel Apps\. Without a real\-app reference, we generate novel apps: apps invented outright, which no model can have seen during training, for studying whether an agent can learn unfamiliar interfaces through interaction\. A coding agent defines each app’s initial data, action rules, screens, tasks, and executable checks on a shared HTML5 template\. Each novel app is a deterministic state machine that runs in Chromium: the same initial state and action sequence always produce the same result, so resets and rewards are exact\. The pipeline tests each app’s logic without a browser, runs the same code in Chromium, and validates the app with reference solutions, reset tests, and checks that both runs agree \(Appendix A\.7\.2\)\. Section 4\.3\.5 reports RL results on these apps\. We release 4949 mocked apps: the seven real\-world clones and 4242 novel apps with 840840 tasks\. Users can apply the same skills to build apps for their own needs; any such app connects to MAI\-Gym through the web adapter and reuses its evaluation, rollout, and training workflows\. 3\.4\.2 Cross\-App World Construction Realistic tasks need an initial state that already holds the evidence and resources required to complete them, so the pipeline builds a coherent world before it writes any task \(Figure 5a\)\. A persona defines the user’s identity, role, and goals; a scenario specifies a timeline, events, and constraints\. From these, the pipeline generates files and app records that share people, events, and facts: a project brief, a budget spreadsheet, an email thread, and a calendar entry can describe different parts of the same project\. Figure 5: World, task, and verifier synthesis\. \(a\) Construct a coherent world of files and app records\. \(b\) Generate and review tasks targeting model weaknesses\. \(c\) Independently synthesize golden and verifier code, validate by execution, and review model rollouts before acceptance\. This shared context lets tasks require finding and combining evidence, as real requests do\. Instead of “create an event named Budget review”, a task can ask the agent to move the budget review to the day after the revised spreadsheet is due, which requires reading an email, a spreadsheet, and a calendar\. The task is grounded in the world’s evidence rather than spelled out as an isolated navigation instruction\. The pipeline loads the generated content into a running environment through reusable initialization templates, populating app data on mobile and a desktop workspace on computers, and checks that the expected files and records are present\. When a later task needs assets that the world lacks, the pipeline adds them and validates the updated world\. The resulting initialization procedure is the task’s reproducible s0s\_\{0\}\. 3\.4\.3 Task and Verifier Synthesis Online RL consumes tasks quickly: every task is attempted many times, and a task that the policy always or never solves stops providing gradient\. Earlier synthesis either relies on model judges whose false positives a policy can learn to exploit \[Yang et al\., 2025, Ramrakhya et al\., 2025\] or verifies with code only in simplified applications \[Cao et al\., 2026, Wu et al\., 2026\]\. Our pipeline combines explicit task specifications with execution\-based validation inside full MobileWorld, OSWorld, and real\-world\-clone environments \(Figure 5b–c\)\. Grounded, Failure\-Driven Task Generation\. The generator extracts facts that the world’s files and apps share and composes tasks that chain evidence, reasoning, and action: the agent must find relevant information, work out what to do, and make the requested changes\. Diagnosis reports, which summarize the model’s failed rollouts, tell the generator which capabilities the new tasks should exercise, so the task pool grows where the model is weak\. A review step removes repetitive tasks, clarifies ambiguous instructions, and checks that each requested outcome is meaningful and supported by the world\. Requirements before Verifier\. Each task specification contains the instruction, references to required assets, success criteria, and an internal answer context that records the supporting facts, calculations, and expected values; the policy never sees the answer context\. The specification thus fixes the requirements from the user’s goal and the world’s evidence before any verifier exists\. Two independent synthesis calls then generate golden code, which sets the environment directly to a completed state, and verifier code, which checks file changes, computed values, and app updates; neither call reads the other’s output\. A reward audit compares the verifier with the specification to catch missing requirements, unsupported conditions, and wrong expected values, so the verifier checks what the user asked for rather than what one solution happened to do\. Execution before Acceptance\. The pipeline runs each verifier on a live instance through an initial–completed–reset sequence: the verifier must score 00 on the initial state, 11 after the golden code runs, and 00 again after reset\. The pipeline also inspects the actual environment state against the requirements, repairs any issue it finds, and drops candidates that still fail\. Because golden code sets the completed state directly, it does not show that an agent can solve the task through the GUI\. Several models therefore attempt each remaining task through the agent interface, and a review of their trajectories checks executability, difficulty, instruction clarity, and reward\-hacking risk\. If too few tasks pass, the pipeline generates more candidates\. Models help build and review tasks; online RL rewards come only from verifier execution\. Accepted tasks include the four components of xx: an environment, reproducible initial state, grounded instruction, and tested verifier\. We release 2,0002\{,\}000 tasks, 1,0001\{,\}000 each for MobileWorld and OSWorld; Appendix A\.6 shows examples\. 3\.5 Online RL Training Like evaluation, online RL starts with one command\. A YAML file specifies the policy checkpoint, task pools and environments, the RL algorithm and its hyperparameters, rollout budgets and concurrency, the history window, and the training backend and parallelism \(Appendix A\.5\)\.\\iow\_now:Ne˝\\iow\_now:Ne˝$ mai\-gym train –config configs/mai\-gym\-9b\.yaml Each round, the command collects rollouts on the shared rollout path, computes verifier rewards, updates the policy, and synchronizes the new weights to the inference engines\. The trainer builds on slime \[THUDM, 2025\], which trains with Megatron\-LM \[Shoeybi et al\., 2019\] and generates rollouts with SGLang \[Zheng et al\., 2024\]\. It supports GRPO \[Shao et al\., 2024\], DAPO \[Yu et al\., 2025\], GSPO \[Zheng et al\., 2025\], REINFORCE\+\+ \[Hu et al\., 2025\], SAO \[Hou et al\., 2026\], and PPO \[Schulman et al\., 2017\], which all consume the same records: trajectories, their rewards, and the log\-probabilities of policy\-generated tokens\. Our main recipe uses GRPO, whose objective Appendix A\.4 gives; asynchronous optimizers such as SAO instead update from individually completed trajectories, and Section 4\.3\.6 compares the two\. GUI trajectories make three parts of training harder than in text RL\. Rollouts are expensive, so they must go to tasks that still teach the policy; trajectories are long and full of screenshots, so training must not re\-encode the same history again and again; and the trainer must see exactly the inputs that the inference engine saw\. MAI\-Gym addresses these with policy\-adaptive task sampling, window\-wise packing, and train–rollout consistency checks\. Policy\-Adaptive Task Sampling\. Task synthesis decides which tasks exist; task sampling decides how often the policy attempts each one\. GRPO learns only from groups whose attempts receive different rewards, so rollouts spent on tasks that the policy always or never solves are wasted\. Before each rollout round, the scheduler estimates each task’s success rate from its past attempts\. Unseen tasks and tasks that the policy sometimes solves receive the full group of GG attempts\. Tasks that the policy has never solved, and tasks that it has mastered with a success rate above η\\eta, receive small but nonzero budgets, so the scheduler rechecks them as the policy changes; we use η=0\.8\\eta=0\.8 and budgets of 44 and 22 attempts, respectively\. The trainer computes a task’s advantages only after all of its attempts are resolved, so completion order and trajectory length do not bias its baseline\. Window\-Wise Packing\. Figure 3b shows how training reuses the rollout windows: each window of a trajectory becomes one causal training sequence, so the trainer encodes a screenshot once per window rather than once per step\. The two common alternatives each pay a cost\. Step\-wise training turns every step into a separate sample and re\-encodes the shared history each time\. Trajectory\-level training packs a whole trajectory into one sequence, which is exact only if each context extends the previous one and quickly exceeds accelerator memory on long, screenshot\-heavy trajectories\. Windows sit between the two\. Loss applies only to each window’s new steps: with K=10K=10 and O=2O=2, the first sample trains turns 1–10 and the second trains turns 11–18, using turns 9–10 only as context, so no output is trained twice\. Each window replays the exact tokens sampled during rollout, and the packer falls back to step\-wise samples for any trajectory whose turns do not form a consistent token prefix\. To fit long sequences in memory, screenshots reach the trainer as compressed images and are decoded only when their microbatch is scheduled, while selective activation recomputation in the vision tower and configurable context, pipeline, and data parallelism keep memory bounded\. Train–Rollout Consistency\. Training is only as correct as its agreement with rollout: if the trainer rebuilds a prompt or processes an image differently from the inference engine, the policy is updated on inputs it never saw\. Launch\-time checks catch known faults in multimodal processing\. During the run, MAI\-Gym compares trainer and rollout log\-probabilities on every response token and gates the run on the k3k\_\{3\} estimator of their KL divergence\. Unlike the mean absolute difference, k3k\_\{3\} is dominated by the few tokens that disagree sharply, so a sudden rise points to a corrupted generation kernel, a misaligned packed history, or a version skew between trainer and engine\. 4 Experiments 4\.1 Experimental Settings Training MAI\-Gym\-9B\. We train MAI\-Gym\-9B from Qwen3\.5\-9B \[Qwen Team, 2026\] in two stages\. The warm\-up stage applies supervised fine\-tuning on data that covers both mobile and desktop environments, so that the model learns to follow mixed GUI and CLI instructions in both domains\. The RL stage then trains this initialization on mobile and computer tasks jointly, in a single run\. A common recipe instead runs RL separately in each domain and merges the resulting experts by parameter averaging \[ByteDance Seed, 2025\]\. Because MAI\-Gym serves phones and desktops through one rollout path, a run draws tasks from both domains, training one policy rather than reconciling separate experts afterward\. We train with GRPO \[Shao et al\., 2024\] on 5,0005\{,\}000 tasks from the synthesis pipeline \(Section 3\.4\.3\), mixed across MobileWorld and OSWorld environments, with rewards from their code verifiers only, and use policy\-adaptive task sampling and window\-wise history with K=10K=10 and O=2O=2 \(Section 3\.5\)\. The run is launched by mai\-gym train with the configuration in Appendix A\.5, using 512512 GPUs and a peak of 20,00020\{,\}000 concurrent environments, and trains for approximately 9696 hours\. Section 4\.3\.2 compares joint training with merging per\-domain experts; Appendix A\.4 lists the main hyperparameters\. Benchmarks and Metrics\. We evaluate MAI\-Gym\-9B on seven benchmarks, three for mobile use and four for computer use: MobileWorld \[MobileWorld Team, 2025\], AndroidWorld \[Rawles et al\., 2025\], MobileGym \[Wu et al\., 2026\], OSWorld\-Verified \[Xie et al\., 2024\], OSWorld 2\.0 \[Yuan et al\., 2026\], MacAgentBench \[Fu et al\., 2026\], and MyPCBench \[Jang et al\., 2026\]\. MobileWorld and OSWorld\-Verified are Task OOD: they share their environments, but not their tasks, with training\. The other five are Env OOD: MAI\-Gym\-9B never trains in the environments of AndroidWorld, MobileGym, MacAgentBench, or MyPCBench, and OSWorld 2\.0 adds 3131 self\-hosted websites and long\-horizon workflows that our training environments do not contain\. Our evaluations run through the mai\-gym eval command, with the agent harness used in training\. We report success rates under each benchmark’s own evaluation metric \(Table 3\)\. For OSWorld 2\.0, we report binary accuracy / partial score, where partial score is the mean task reward in percent; for MobileGym, we report the partial score\. To summarize results, we use unweighted averages: Mobile Avg and Computer Avg over the three mobile and four computer benchmarks, Cross Avg as the mean of the two, and Task\-OOD Avg and Env\-OOD Avg over the two Task OOD and five Env OOD benchmarks; all averages use the binary score of OSWorld 2\.0 and the partial score of MobileGym\. In Table 4, parenthesized values give gains over Qwen3\.5\-9B in percentage points; dashes denote unreported results\. Baselines\. We compare MAI\-Gym\-9B with three groups of models \(Table 4\)\. Frontier models: Claude Opus 4\.8 \[Anthropic, 2026\], GPT\-5\.5 \[OpenAI, 2026\], and Qwen3\.8\-Max \[Qwen Team, 2026a\], all accessed through APIs, together with the open\-weight Qwen3\.8\-27B \[Qwen Team, 2026b\]\. GUI agent models: GUI\-Owl\-1\.5\-8B and GUI\-Owl\-1\.5\-32B \[Xu et al\., 2026\], UI\-Venus\-2\-9B \[Venus Team, 2026\], SCALECUA\-Qwen3\.5\-9B \[Lv et al\., 2026\], EvoCUA\-1\.5\-32B \[Huang et al\., 2026\], CUA\-GYM\-35B\-A3B and CUA\-GYM\-397B\-A17B \[Wang et al\., 2026\], and Qwen\-CUA \[Qwen Team & XLANG Lab, 2026\]; UI\-Venus\-2\-9B and SCALECUA\-Qwen3\.5\-9B match MAI\-Gym\-9B in size\. Base model: the Qwen3\.5\-9B backbone, which measures the gain of the whole recipe\. Baseline entries come from published reports and leaderboards, except eight entries from our runs: Qwen3\.8\-Max on MacAgentBench and MyPCBench, Qwen3\.8\-27B and Qwen3\.5\-9B on MacAgentBench, and both GUI\-Owl sizes on MyPCBench and OSWorld 2\.0\. 4\.2 Main Results Table 4: Mobile and computer benchmark results \(%\)\. Task OOD: unseen tasks in training environments; Env OOD: unseen environments\. Model Size Access Mobile Computer Task OOD Env OOD Task OOD Env OOD MobileWorld GUI\-only Android World Mobile Gym OSWorld Verified OSWorld 2\.0 MacAgent Bench MyPC Bench Frontier models Claude Opus 4\.8 – API 69\.2 75\.0 50\.7 83\.4 20\.3/54\.8 58\.4 62\.0 GPT\-5\.5 – API 62\.4 74\.1 48\.1 78\.7 13\.9/47\.5 66\.7 47\.3 Qwen3\.8\-Max 2\.4T\-A95B API 77\.8 85\.3 61\.3 86\.1 19\.4/46\.7 74\.3 48\.6 Qwen3\.8\-27B 27B Open 70\.1 81\.9 57\.5 84\.3 19\.4/48\.0 65\.4 28\.5 GUI agent models GUI\-Owl\-1\.5\-8B 8B Open 38\.2 71\.6 15\.1 52\.9 0\.0/1\.6 10\.2 1\.8 GUI\-Owl\-1\.5\-32B 32B Open 43\.9 69\.8 20\.3 56\.5 0\.9/2\.5 17\.2 6\.3 UI\-Venus\-2\-9B 9B Open 75\.2 80\.2 52\.7 70\.8 0\.0/7\.5 36\.2 6\.3 SCALECUA\-Qwen3\.5\-9B 9B Open 12\.8 47\.4 13\.5 68\.7 0\.0/2\.2 3\.9 1\.1 Qwen\-CUA 397B\-A17B Open – – – 86\.2 18\.5/48\.4 69\.2 58\.7 EvoCUA\-1\.5\-32B 32B Unreleased – – – 63\.2 –/– – – CUA\-GYM\-35B\-A3B 35B\-A3B Unreleased – – – 62\.1 –/– – – CUA\-GYM\-397B\-A17B 397B\-A17B Unreleased – – – 72\.6 –/– – – Ours Qwen3\.5\-9B \(base model\) 9B Open 18\.0 57\.8 9\.0 41\.8 0\.0/2\.5 20\.7 6\.5 78\.4 75\.9 46\.5 76\.2 3\.7/11\.3 41\.3 15\.2 MAI\-Gym\-9B 9B Open \(\+60\.4\) \(\+18\.1\) \(\+37\.5\) \(\+34\.4\) \(\+3\.7/\+8\.8\) \(\+20\.6\) \(\+8\.7\) Task OOD Benchmarks\. Table 4 evaluates one MAI\-Gym\-9B checkpoint on all seven benchmarks, whereas four of the GUI agent baselines report computer use only\. On the two benchmarks whose environments appear in training, MAI\-Gym\-9B reaches 78\.4%78\.4\\% on MobileWorld and 76\.2%76\.2\\% on OSWorld\-Verified, the highest scores among GUI agent models of comparable size\. It leads UI\-Venus\-2\-9B by 3\.23\.2 and 5\.45\.4 points and GUI\-Owl\-1\.5\-8B by 40\.240\.2 and 23\.323\.3 points, respectively\. It also outperforms the larger GUI agents that report these benchmarks: GUI\-Owl\-1\.5\-32B on both, and EvoCUA\-1\.5\-32B, CUA\-GYM\-35B\-A3B, and CUA\-GYM\-397B\-A17B on OSWorld\-Verified; only Qwen\-CUA, a 397B\-A17B model, scores higher on OSWorld\-Verified\. Against frontier models, MAI\-Gym\-9B surpasses Claude Opus 4\.8 \(69\.2%69\.2\\%\), GPT\-5\.5 \(62\.4%62\.4\\%\), and Qwen3\.8\-Max \(77\.8%77\.8\\%\) on MobileWorld, and comes within 2\.52\.5 points of GPT\-5\.5 on OSWorld\-Verified\. Because no benchmark task is used in training, these scores measure how well the policy solves new tasks in environments it has trained in\. Env OOD Benchmarks\. The other five benchmarks test whether these abilities carry over to environments where MAI\-Gym\-9B lacks environment\-specific knowledge\. MAI\-Gym\-9B remains competitive on the two mobile Env\-OOD benchmarks, achieving 75\.975\.9 on AndroidWorld and 46\.546\.5 on MobileGym, within 4\.34\.3 and 6\.26\.2 points of UI\-Venus\-2\-9B and above GUI\-Owl\-1\.5\-8B on both\. On the more challenging computer Env\-OOD benchmarks, it reaches 3\.7/11\.33\.7/11\.3 on OSWorld 2\.0, 41\.341\.3 on MacAgentBench, and 15\.215\.2 on MyPCBench, leading all similarly sized open GUI agents with reported results\. Figure 6: Gains from SFT warm\-up and joint RL\. Gains from SFT and Joint RL\. Figure 6 splits each score of MAI\-Gym\-9B into the reported score of its Qwen3\.5\-9B base, the gain from the SFT warm\-up, and the gain from joint RL, with the SFT warm\-up checkpoint evaluated under our protocol\. The superscript pp marks partial scores for MobileGym and OSWorld 2\.0\. The SFT warm\-up provides most of the improvement: it raises Task\-OOD Avg from 29\.929\.9 to 66\.466\.4 and Env\-OOD Avg from 18\.818\.8 to 32\.332\.3\. Joint RL then raises Cross Avg from 44\.144\.1 to 50\.550\.5, with gains of 8\.78\.7 points on Mobile Avg and 4\.24\.2 on Computer Avg, so training the two domains in one run improves both rather than trading one for the other\. RL adds 14\.114\.1 and 7\.87\.8 points on the two Task OOD benchmarks and 4\.24\.2 on Env\-OOD Avg, and it improves every Env OOD benchmark, so what the policy learns from synthesized tasks in two environments transfers beyond them\. Figure 7: Efficient behaviors learned by MAI\-Gym\-9B\. Top: adaptive zoom in MobileWorld\. Middle: batched GUI actions in OSWorld\. Bottom: CLI tool use in OSWorld\. Efficient Behaviors Learned through Training\. Figure 7 illustrates efficient behaviors that MAI\-Gym\-9B learns through training\. On computer tasks, the model can invoke CLI tools when they are the most efficient interface\. In OSWorld, it uses ffprobe to inspect video streams and ffmpeg to export subtitles and remux the file losslessly, instead of taking a longer GUI route for media editing\. The model also supports batch execution for GUI actions\. In spreadsheet\-style interactions, steps such as locking focus, entering a range, confirming the input, and copying with a keyboard shortcut can be combined into fewer higher\-level actions, which reduces execution steps, observation–decision cycles, and user token cost\. On mobile tasks, MAI\-Gym\-9B further shows model\-native adaptive zoom\-in\. By using app\-native double\-tap zoom and shifting the zoom target across pages, it can inspect small details that are unreadable in the full\-page view, which helps with information retrieval and exact numerical extraction\. These examples suggest that MAI\-Gym\-9B improves not only by selecting better actions, but also by choosing the right interaction mode for each task, including direct GUI manipulation, batched GUI execution, and external tool use\. 4\.3 Analysis We next analyze MAI\-Gym and its training recipe\. Each analysis answers one question: whether the infrastructure runs efficiently at the scale that online GUI RL needs \(Section 4\.3\.1\), whether joint RL beats merging per\-domain experts \(Section 4\.3\.2\), how RL gains grow with the number of synthesized tasks \(Section 4\.3\.3\), whether training in a real\-world clone transfers to the real app \(Section 4\.3\.4\), whether an agent can learn novel apps from reward alone \(Section 4\.3\.5\), and how GRPO compares with SAO on MAI\-Gym \(Section 4\.3\.6\)\. 4\.3\.1 Infrastructure Runs Efficiently at Scale Table 5: Environment efficiency and reliability\. Bring\-up ends when 1,000 environments are GUI\-ready\. Unscored aborts are attempts rerun after environment failures, without scoring\. Environment Bring\-up time for 1k envs \(s\) Reset p50 / p95 \(s\) Unscored aborts \(%\) Mobile 328\.4 \(≥6×\\geq 6\\times faster\)†\\dagger 165\.0 / 184\.0 1\.2 Computer 88\.9 37\.2 / 100\.1 1\.9 Browser 94\.2 6\.0 / 27\.0 0\.0 †\\dagger Mobile speedup versus estimated KVM/bare\-metal: 100 serial batches of 10 with 20\-second waits require at least 1,980 seconds\. Table 6: Efficiency of step\-wise and window\-wise history\. History Prefix\-cache hit \(%\) Rollout steps/s Train input tokens/traj\. Train update \(s\) Step\-wise 42\.5 2\.3 566,375 2166\.4 Window\-wise \(K=10K\{=\}10, O=2O\{=\}2\) 85\.9 \(\+102\.1%\) 1\.9 \(\-18\.9%\) 86,855 \(\-84\.7%\) 810\.9 \(\-62\.6%\) Table 6 summarizes the environment efficiency of MAI\-Gym\. Across mobile, computer, and browser settings, MAI\-Gym supports low\-abort operation while bringing up 1,000 GUI\-ready environments within a few minutes\. In particular, mobile bring\-up takes 328\.4 seconds, which is at least 6×6\\times faster than our estimate for a serial KVM\-style setup, suggesting that the environment manager is effective for scaling online RL in GUI domains\. Evaluating a MAI\-Gym\-9B checkpoint on all seven benchmarks with three trials per task takes approximately three hours\. Table 6 compares step\-wise and window\-wise history\. Window\-wise history yields much higher prefix\-cache reuse and substantially lower training token cost, which in turn reduces training update time from 2166\.4 to 810\.9 seconds, although rollout throughput decreases moderately\. Overall, these measurements suggest that window\-wise history offers a better efficiency trade\-off in our training setup\. 4\.3\.2 Joint RL Beats Expert Merging We compare joint RL on mobile and computer tasks with a two\-stage alternative: training separate per\-domain experts and then merging them by weighted parameter averaging \[Goddard et al\., 2024\]\. All runs start from the same warm\-up checkpoint, and the joint RL run uses the combined training budget of the two experts\. Table 7 reports success rates in percent, with merge weights listed in mobile/computer order\. The merged models retain a substantial portion of the domain\-specific gains from the two experts, but they do not match joint training\. No single merge leads in both domains: the best merge for MobileWorld \(50/50\) reaches 76\.4%, and the best for OSWorld\-Verified \(30/70\) reaches 74\.8%\. Joint RL attains 78\.4% and 76\.2%, above the best merge in each domain\. These results suggest that joint RL outperforms specialist merging in both domains\. Setting MobileWorld OSWorld\-Verified Mobile expert 76\.4 71\.4 Computer expert 73\.5 73\.8 Merge 70/30 74\.4 68\.4 Merge 50/50 76\.4 73\.7 Merge 30/70 73\.5 74\.8 Joint RL 78\.4 76\.2 Table 7: Joint RL vs\. expert merging\. 0\.5k1k5k6060656570707575808069\.273\.578\.469\.770\.976\.2Synthesized training tasksSuccess rate \(%\)MobileWorldOSWorld\-Verified Figure 8: Synthesized task scaling\. Figure 9: Clone\-to\-real transfer \(12306, 52 tasks\)\. Figure 10: GRPO vs\. SAO on MobileWorld\. Figure 11: Relative\-date reasoning after clone\-only RL\. Top: incorrect dates before RL\. Bottom: the correct Monday is selected and the reminder is set in both the clone and real app after RL\. 4\.3\.3 Scaling Synthesized Tasks Improves Generalization We examine how larger synthesized task pools affect performance\. From the synthesized MobileWorld and OSWorld tasks, we randomly sample training sets of 500500, 1,0001\{,\}000, and 5,0005\{,\}000 tasks in total across the two environments\. All RL runs use the same algorithm, hyperparameters, and rollout budget\. Figure 8 shows that scaling synthesized training tasks improves generalization on MobileWorld and OSWorld\-Verified, whose benchmark tasks are not used in training\. Increasing the number of tasks from 500500 to 5,0005\{,\}000 improves the success rate from 69\.2%69\.2\\% to 78\.4%78\.4\\% on MobileWorld and from 69\.7%69\.7\\% to 76\.2%76\.2\\% on OSWorld\-Verified\. With the rollout budget held constant, these results show the benefit of training on more diverse synthesized tasks\. 4\.3\.4 Clone Training Transfers to the Real App Using 5252 paired tasks, we compare success rates before and after clone\-only RL in the 12306 clone and the real 12306 app on a physical phone\. Figure 9 shows clone\-only RL improves success from 36\.5%36\.5\\% to 73\.1%73\.1\\% in the clone and from 28\.8%28\.8\\% to 48\.1%48\.1\\% in the real app \(a gain of 19\.219\.2 percentage points\)\. Figure 11 illustrates shared relative\-date reasoning: after RL, the policy selects the correct Monday and sets the reminder in both apps\. Transfer remains incomplete: the clone–real gap widens from 7\.77\.7 to 25\.025\.0 percentage points, so clone gains do not fully predict real\-app performance\. 4\.3\.5 Agents Learn Unfamiliar Apps from Reward Novel apps test learning unfamiliar interfaces\. We train on 252252 tasks and evaluate on 6262 held\-out ones, one attempt each, under a 6060\-step budget\. RL raises success from 25\.8%25\.8\\% to 45\.2%45\.2\\%, reduces budget\-exhausting attempts from 2727 to 55, and shortens mean trajectories from 33\.333\.3 to 16\.416\.4 steps\. Figure 12 illustrates one held\-out task\. RL uses only verifier rewards, with no demonstrations of these apps\. Figure 12: RL enables efficient task completion in a novel app\. Before RL, repeated ineffective gestures exhaust the 6060\-step budget; after RL, the agent moves the folder and reports unchanged free space, passing all four checks in five steps\. 4\.3\.6 Comparing GRPO and SAO MAI\-Gym supports RL algorithms through shared environment interfaces, rollout collection, and verifier rewards \(Section 3\.5\)\. We compare our GRPO recipe with SAO \[Hou et al\., 2026\], which replaces grouped rollouts with asynchronous single\-rollout updates and uses a learned value model for advantage estimation\. Figure 10 shows similar early task success for both recipes, with SAO ending the displayed interval at a slightly lower success rate than GRPO\. In our timing comparison, SAO reduces sampling wait time, but the added critic computation, including two critic updates per actor update, offsets this benefit\. Thus, SAO shows no clear overall training\-time advantage over GRPO under the tested configurations\. 5 Related Work RL for GUI Agents\. Online RL has become a standard way to improve GUI agents, and most work contributes a training recipe for one domain\. On Android, DigiRL, DistRL, MobileRL, and MobileGUI\-RL study reward design, asynchronous collection, and adaptive training \[Bai et al\., 2024, Wang et al\., 2025, THUDM, 2025, Shi et al\., 2025\]\. On the web, WebRL trains with a self\-evolving curriculum and WebAgent\-R1 with end\-to\-end multi\-turn RL \[Qi et al\., 2025, Wei et al\., 2025\]\. On computers, ComputerRL scales RL with parallel execution, DART\-GUI decouples training from rollouts, and Qwen\-CUA learns native computer use from screenshots \[Lai et al\., 2025, Li et al\., 2025, Qwen Team & XLANG Lab, 2026\]\. Later systems refine the training loop: EvoCUA\-1\.5 adds asynchronous multi\-turn RL with policy\-aware filtering and an adaptive curriculum, UI\-Mate combines environment\-grounded training with in\-context demonstrations, and SCALECUA couples verifiable task synthesis with efficient RL \[Huang et al\., 2026, Ding et al\., 2026, Lv et al\., 2026\]\. UI\-TARS\-2, Qwen\-UI\-Agent, and UI\-Venus\-2 go further and train one policy for mobile, computer, and web \[ByteDance Seed, 2025, Zhou et al\., 2026, Venus Team, 2026\]; to combine domains, a common recipe trains a separate RL expert per domain and merges the experts afterward \[ByteDance Seed, 2025\]\. These works contribute models and recipes, and most build their own environments and training stack for the domains they study\. MAI\-Gym is complementary: it offers one open platform on which such recipes run across domains, and it trains mobile and computer tasks together in a single RL run\. GUI Gyms and Training Infrastructure\. Open GUI gyms focus either on running agents or on supplying tasks \(Table 1\)\. Infrastructure\-focused gyms make evaluation or training reproducible on one platform: BrowserGym unifies web benchmarks behind one interface, WebGym, MobileGym, and SCALECUA run online RL on hundreds of parallel environments, and ClawGUI provides a framework for training, evaluating, and deploying GUI agents \[Le Sellier De Chezelles et al\., 2025, Bai et al\., 2026, Wu et al\., 2026, Lv et al\., 2026, Tang et al\., 2026\]\. Data\-focused gyms, such as CUA\-Gym, Gym\-Anything, GUI\-Genesis, and PhoneWorld, contribute new environments and tasks but release neither training code nor a way to run existing benchmarks \[Wang et al\., 2026, Aggarwal et al\., 2026, Cao et al\., 2026, Liu et al\., 2026\]\. Outside GUIs, AgentGym and GEM provide gyms for LLM agents in text\- and tool\-based environments \[Xi et al\., 2025, GEM Team, 2026\], and general\-purpose RL frameworks such as verl, OpenRLHF, AReaL, and slime scale policy optimization for language models but do not manage GUI environments \[Sheng et al\., 2025, Hu et al\., 2024, Fu et al\., 2025, THUDM, 2025\]\. Consistency is a further concern: changing the harness alone can change a fixed model’s score \[Wu et al\., 2026\], so separate evaluation and training code can measure a different agent from the one being trained\. MAI\-Gym covers both sides on mobile, computer, and web\. It runs ten existing benchmarks and online RL with 20,00020\{,\}000 parallel environments through one shared harness, builds its trainer on slime, and adds its own synthesized apps and tasks\. Environment and Task Synthesis\. GUI benchmarks ship only hundreds of hand\-written tasks, far fewer than online RL consumes, so recent work synthesizes tasks, and each approach trades reward reliability against scope\. One line scores success with a VLM judge: ZeroGUI generates tasks and rewards them with a VLM, AutoPlay explores an app before proposing tasks with a VLM verifier, and OS\-Genesis synthesizes trajectories in reverse \[Yang et al\., 2025, Ramrakhya et al\., 2025, Sun et al\., 2025\]\. These methods scale easily, but false\-positive rewards can destabilize RL\. A second line grounds rewards in code, which is more reliable but narrower\. GUI\-Genesis turns apps into lightweight web environments with executable assertions, AutoWebWorld models environments as finite\-state machines, InfiniteWeb builds verifiable web tasks, and AutoEval derives rewards from mobile UI sub\-states \[Cao et al\., 2026, Wu et al\., 2026, Zhang et al\., 2026, Sun et al\., 2025\]\. At larger scale, CUA\-Gym builds grounded task pools for computers, MobileGym and PhoneWorld build mock mobile apps, and OpenComputer synthesizes desktop tasks and initial states around application\-specific verifiers \[Wang et al\., 2026, Wu et al\., 2026, Liu et al\., 2026, Wei et al\., 2026\]\. In most of these systems, a task starts from a single input file or from sample data shared by all tasks of an app \(Table 1\)\. Task generation can also follow the learner: WebRL generates new tasks from failed attempts, TRACE turns recurrent agent failures into capability\-targeted environments, and GenEnv and Agent\-World evolve environments together with the agent \[Qi et al\., 2025, Kang et al\., 2026, Guo et al\., 2025, Dong et al\., 2026\]\. MAI\-Gym brings these threads together for GUI tasks\. It builds a cross\-app world of interlinked files and app records before writing any task, steers generation with diagnoses of failed rollouts, fixes success criteria before generating a code verifier, and accepts the verifier only after it passes execution tests\. Its mocked apps include real\-world clones, in which we measure transfer to the real app, and novel apps for studying adaptation to unfamiliar interfaces\. 6 Conclusion We presented MAI\-Gym, an open all\-in\-one platform for GUI agent evaluation and online RL across mobile, computer, and web\. Evaluation, data collection, and training share one rollout path and one agent harness, ensuring the evaluated agent is the trained agent; the environment manager serves ten benchmarks and has run 20,00020\{,\}000 parallel instances\. MAI\-Gym supplies online RL with synthesized mocked apps, cross\-app worlds of interlinked files and app records, and tasks whose code verifiers pass execution tests\. One joint RL run on mobile and computer tasks trained MAI\-Gym\-9B\. It reaches 78\.4%78\.4\\% on MobileWorld and 76\.2%76\.2\\% on OSWorld\-Verified, the best results among open GUI agents under 10B parameters; RL improves on the SFT warm\-up across all five benchmarks outside its training environments\. Our analyses indicate that joint training outperforms merging per\-domain experts, larger synthesized task pools strengthen the policy, and skills learned in a real\-world clone transfer to the real app, raising success on a physical phone from 28\.8%28\.8\\% to 48\.1%48\.1\\%\. We release the framework, synthesis skills, mocked apps, 2,0002\{,\}000 verified tasks, and the model checkpoint for GUI agent evaluation, synthesis, and training on one platform\. 7 Contributions Core Contributors Panrong Tong∗, Quyu Kong∗, Pengxiang Li∗, Tianyu Xia∗, Hanzhang Zhou∗, Lei Wang, Chenglin Cai, Long Li, Long Chen, Jianan Zhang, Zhengwen Zeng, Xu Zhang, Gongjie Zhang, Yue Wang†, Steven Hoi\. Contributors Chen Liu, Yuchen Sun, Yang Zi, Peng Li, Nana Jiang, Jiaqi Gao, Jun Huang, Ennan Zhai, and Wenchao Zhou\.††footnotetext: ∗ Project Co\-Leader\. † Project Leader\. References Zhou et al\. \[2026\] Hanzhang Zhou, Panrong Tong, Xu Zhang, et al\. Qwen\-UI\-Agent technical report: Toward next\-generation real\-world centric foundation GUI agents\. arXiv preprint arXiv:2607\.28227, 2026\. URL https://arxiv\.org/abs/2607\.28227\. DeepSeek\-AI \[2025\] DeepSeek\-AI\. DeepSeek\-R1: Incentivizing reasoning capability in llms via reinforcement learning\. Nature, 645:633–638, 2025\. Pan et al\. \[2024\] Jiayi Pan, Xingyao Wang, Graham Neubig, et al\. Training software engineering agents and verifiers with SWE\-Gym\. arXiv preprint arXiv:2412\.21139, 2024\. Jain et al\. \[2025\] Naman Jain, Jaskirat Singh, Manish Shetty, et al\. R2E\-Gym: Procedural environments and hybrid verifiers for scaling open\-weights SWE agents\. arXiv preprint arXiv:2504\.07164, 2025\. Yang et al\. \[2025\] John Yang, Kilian Lieret, Carlos E\. Jimenez, et al\. SWE\-smith: Scaling data for software engineering agents\. arXiv preprint arXiv:2504\.21798, 2025\. RUC\-NLPIR \[2026\] RUC\-NLPIR\. EnvScaler: Scaling tool\-interactive environments for llm agent via programmatic synthesis\. arXiv preprint arXiv:2601\.05808, 2026\. Dong et al\. \[2026\] Guanting Dong, Junting Lu, Junjie Huang, Wanjun Zhong, and Longxiang Liu\. Agent\-World: Scaling real\-world environment synthesis for evolving general agent intelligence\. arXiv preprint arXiv:2604\.18292, 2026\. Bai et al\. \[2024\] Hao Bai, Yifei Zhou, Mert Cemri, et al\. DigiRL: Training in\-the\-wild device\-control agents with autonomous reinforcement learning\. In Advances in Neural Information Processing Systems \(NeurIPS\), 2024\. THUDM \[2025\] THUDM\. MobileRL: Online agentic reinforcement learning for mobile gui agents\. arXiv preprint arXiv:2509\.18119, 2025\. Qi et al\. \[2025\] Zehan Qi, Xiao Liu, Iat Long Iong, et al\. WebRL: Training LLM web agents via self\-evolving online curriculum reinforcement learning\. In International Conference on Learning Representations \(ICLR\), 2025\. Lai et al\. \[2025\] Hanyu Lai, Xiao Liu, Yanxiao Zhao, et al\. ComputerRL: Scaling end\-to\-end online reinforcement learning for computer use agents\. arXiv preprint arXiv:2508\.14040, 2025\. ByteDance Seed \[2025\] ByteDance Seed\. UI\-TARS\-2 technical report: Advancing gui agent with multi\-turn reinforcement learning\. arXiv preprint arXiv:2509\.02544, 2025\. Wu et al\. \[2026\] Wenyi Wu, Sibo Zhu, Kun Zhou, et al\. StructAgent: Harness Long\-horizon Digital Agents with Unified Causal Structure\. arXiv preprint arXiv:2607\.11388, 2026\. URL https://arxiv\.org/abs/2607\.11388\. Le Sellier De Chezelles et al\. \[2025\] Thibault Le Sellier De Chezelles, Maxime Gasse, Alexandre Drouin, et al\. The BrowserGym ecosystem for web agent research\. In Transactions on Machine Learning Research \(TMLR\), 2025\. Bai et al\. \[2026\] Hao Bai, Alexey Taymanov, Tong Zhang, Aviral Kumar, and Spencer Whitehead\. Webgym: Scaling training environments for visual web agents with realistic tasks\. arXiv preprint arXiv:2601\.02439, 2026\. URL https://arxiv\.org/abs/2601\.02439\. Wu et al\. \[2026\] Dingbang Wu, Rui Hao, Haiyang Wang, Shuzhe Wu, Han Xiao, Zhenghong Li, Bojiang Zhou, Zheng Ju, Zichen Liu, Lue Fan, and Zhaoxiang Zhang\. MobileGym: A verifiable and highly parallel simulation platform for mobile gui agent research\. arXiv preprint arXiv:2605\.26114, 2026\. Lv et al\. \[2026\] Bowen Lv, Xiao Liu, Yanyu Ren, et al\. SCALECUA: Scaling Computer Use Agents with Verifiable Task Synthesis and Efficient Online RL\. arXiv preprint arXiv:2607\.11185, 2026\. URL https://arxiv\.org/abs/2607\.11185\. Tang et al\. \[2026\] Fei Tang, Zhiqiong Lu, Boxuan Zhang, et al\. ClawGUI: A Unified Framework for Training, Evaluating, and Deploying GUI Agents\. arXiv preprint arXiv:2604\.11784, 2026\. URL https://arxiv\.org/abs/2604\.11784\. Wang et al\. \[2026\] Bowen Wang, Dunjie Lu, Junli Wang, Tianyi Bai, Shixuan Liu, Zhipeng Zhang, Haiquan Wang, Hao Hu, Tianbao Xie, Shuai Bai, Dayiheng Liu, Que Shen, Junyang Lin, and Tao Yu\. CUA\-Gym: Scaling verifiable training environments and tasks for computer\-use agents\. arXiv preprint arXiv:2605\.25624, 2026\. Aggarwal et al\. \[2026\] Pranjal Aggarwal, Graham Neubig, and Sean Welleck\. Gym\-anything: Turn any software into an agent environment\. arXiv preprint arXiv:2604\.06126, 2026\. URL https://arxiv\.org/abs/2604\.06126\. Cao et al\. \[2026\] Yuan Cao, Dezhi Ran, Mengzhou Wu, Yuzhe Guo, Xin Chen, Ang Li, Gang Cao, Zhi Gong, Hao Yu, Linyi Li, Wei Yang, and Tao Xie\. GUI\-GENESIS: Automated synthesis of efficient environments with verifiable rewards for gui agent post\-training\. arXiv preprint arXiv:2602\.14093, 2026\. Liu et al\. \[2026\] Yuxuan Liu, Xin Lai, Junyi Li, et al\. PhoneWorld: From Real\-App Trajectories to Dynamic and Verifiable Environments for Phone\-Use Agents\. arXiv preprint arXiv:2605\.29486, 2026\. URL https://arxiv\.org/abs/2605\.29486\. Venus Team \[2026\] Venus Team\. UI\-Venus\-2 technical report\. arXiv preprint arXiv:2609\.00028, 2026\. URL https://arxiv\.org/html/2609\.00028\. Xu et al\. \[2026\] Haiyang Xu, Xi Zhang, Haowei Liu, et al\. Mobile\-Agent\-v3\.5: Multi\-platform fundamental GUI agents\. arXiv preprint arXiv:2602\.16855, 2026\. URL https://arxiv\.org/html/2602\.16855\. Shao et al\. \[2024\] Zhihong Shao, Peiyi Wang, Qihao Zhu, et al\. DeepSeekMath: Pushing the limits of mathematical reasoning in open language models\. arXiv preprint arXiv:2402\.03300, 2024\. Remote Android Project \[2024\] Remote Android Project\. Redroid: A multi\-arch, gpu\-enabled android in cloud container solution\. https://github\.com/remote\-android/redroid\-doc, 2024\. MobileWorld Team \[2025\] MobileWorld Team\. MobileWorld: Benchmarking autonomous mobile agents in agent\-user interactive and mcp\-augmented environments\. arXiv preprint arXiv:2512\.19432, 2025\. Rawles et al\. \[2025\] Christopher Rawles, Sarah Clinckemaillie, Yifan Chang, et al\. AndroidWorld: A dynamic benchmarking environment for autonomous agents\. In International Conference on Learning Representations \(ICLR\), 2025\. Xie et al\. \[2024\] Tianbao Xie, Danyang Zhang, Jixuan Chen, et al\. OSWorld: Benchmarking multimodal agents for open\-ended tasks in real computer environments\. In Advances in Neural Information Processing Systems \(NeurIPS\) Datasets and Benchmarks, 2024\. Yuan et al\. \[2026\] Mengqi Yuan, Zilong Zhou, Xinzhuang Xiong, Weiming Wu, Jiayang Sun, Jiamin Song, Kaiqian Cui, Bowen Wang, Haoyuan Wu, Yitong Li, et al\. OSWorld 2\.0: Benchmarking computer use agents on long\-horizon real\-world tasks\. arXiv preprint arXiv:2606\.29537, 2026\. Fu et al\. \[2026\] Y\. Fu, B\. Fu, Z\. Wu, S\. Cheng, X\. Sun, B\. Yang, Z\. Li, Y\. Zhao, Z\. Ding, Z\. Liu, S\. Wang, B\. Qi, and B\. Zhou\. MacAgentBench: Benchmarking AI agents on real\-world macOS desktop\. arXiv preprint arXiv:2606\.22557, 2026\. URL https://arxiv\.org/abs/2606\.22557\. Jang et al\. \[2026\] L\. K\. Jang, A\. K\. Jang, J\. Y\. Koh, and R\. Salakhutdinov\. MyPCBench: A benchmark for personally intelligent computer\-use agents\. arXiv preprint arXiv:2606\.16748, 2026\. URL https://arxiv\.org/abs/2606\.16748\. He et al\. \[2024\] Hongliang He, Wenlin Yao, Kaixin Ma, Wenhao Yu, Yong Dai, Hongming Zhang, Zhenzhong Lan, and Dong Yu\. Webvoyager: Building an end\-to\-end web agent with large multimodal models\. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\), pp\. 6864–6890, 2024\. Xue et al\. \[2025\] Tianci Xue, Weijian Qi, Tianneng Shi, Chan Hee Song, Boyu Gou, Dawn Song, Huan Sun, and Yu Su\. An illusion of progress? assessing the current state of web agents\. In Second Conference on Language Modeling, 2025\. URL https://openreview\.net/forum?id=6jZi4HSs6o\. Zhou et al\. \[2024\] Shuyan Zhou, Frank F\. Xu, Hao Zhu, et al\. WebArena: A realistic web environment for building autonomous agents\. In International Conference on Learning Representations \(ICLR\), 2024\. Anthropic \[2026\] Anthropic\. Claude code\. https://github\.com/anthropics/claude\-code, 2026\. GitHub repository\. Accessed: 2026\-10\-10\. OpenAI \[2026\] OpenAI\. Codex\. https://github\.com/openai/codex, 2026\. GitHub repository\. Accessed: 2026\-10\-10\. Yang et al\. \[2025\] Chenyu Yang, Shiqian Su, Shi Liu, et al\. ZeroGUI: Automating online gui learning at zero human cost\. arXiv preprint arXiv:2505\.23762, 2025\. Ramrakhya et al\. \[2025\] Ram Ramrakhya, Andrew Szot, Omar Attia, et al\. Scaling synthetic task generation for agents via exploration\. arXiv preprint arXiv:2509\.25047, 2025\. Wu et al\. \[2026\] Yifan Wu, Yiran Peng, Yuyao Zhai, Bang Liu, Chenglin Wu, and Yuyu Luo\. AutoWebWorld: Programmatic synthesis of verified web environments for agent training\. arXiv preprint arXiv:2602\.14296, 2026\. THUDM \[2025\] THUDM\. slime: An SGLang\-native post\-training framework for RL scaling\. https://github\.com/THUDM/slime, 2025\. Shoeybi et al\. \[2019\] Mohammad Shoeybi, Mostofa Patwary, Raul Puri, Patrick LeGresley, Jared Casper, and Bryan Catanzaro\. Megatron\-LM: Training multi\-billion parameter language models using model parallelism\. arXiv preprint arXiv:1909\.08053, 2019\. Zheng et al\. \[2024\] Lianmin Zheng, Liangsheng Yin, et al\. SGLang: Efficient execution of structured language model programs\. In Advances in Neural Information Processing Systems \(NeurIPS\), 2024\. Yu et al\. \[2025\] Qiying Yu, Zheng Zhang, Ruofei Zhu, et al\. DAPO: An open\-source llm reinforcement learning system at scale\. arXiv preprint arXiv:2503\.14476, 2025\. Zheng et al\. \[2025\] Chujie Zheng, Shixuan Liu, Mingze Li, et al\. Group sequence policy optimization\. arXiv preprint arXiv:2507\.18071, 2025\. Hu et al\. \[2025\] Jian Hu, Jason Klein Liu, Haotian Xu, and Wei Shen\. REINFORCE\+\+: Stabilizing critic\-free policy optimization with global advantage normalization\. arXiv preprint arXiv:2501\.03262, 2025\. Hou et al\. \[2026\] Zhenyu Hou, Yujiang Li, Jie Tang, and Yuxiao Dong\. Single\-rollout asynchronous optimization for agentic reinforcement learning\. arXiv preprint arXiv:2607\.07508, 2026\. Schulman et al\. \[2017\] John Schulman, Filip Wolski, Prafulla Dhariwal, Alec Radford, and Oleg Klimov\. Proximal policy optimization algorithms\. arXiv preprint arXiv:1707\.06347, 2017\. Qwen Team \[2026\] Qwen Team\. Qwen3\.5\-9B model card\. https://huggingface\.co/Qwen/Qwen3\.5\-9B, 2026\. Anthropic \[2026\] Anthropic\. Claude Opus 4\.8 system card\. https://www\-cdn\.anthropic\.com/0b4915911bb0d19eca5b5ee635c80fef830a37ea\.pdf, 2026\. OpenAI \[2026\] OpenAI\. Introducing GPT\-5\.5\. https://openai\.com/index/introducing\-gpt\-5\-5/, 2026\. Qwen Team \[2026a\] Qwen Team\. Qwen3\.8\-Max: A new bar for coding and cowork\. https://qwen\.ai/blog?id=qwen3\.8, 2026a\. Visual benchmark chart also available at https://github\.com/AlibabaCloud\-Official/Qwen3\.8\-max\. Qwen Team \[2026b\] Qwen Team\. Qwen3\.8\-27B model card\. https://huggingface\.co/Qwen/Qwen3\.8\-27B, 2026b\. Huang et al\. \[2026\] Mianqiu Huang, Taofeng Xue, Chong Peng, et al\. EvoCUA\-1\.5: Online reinforcement learning for multi\-turn computer\-use agents\. arXiv preprint arXiv:2607\.09773, 2026\. URL https://arxiv\.org/html/2607\.09773\. Qwen Team & XLANG Lab \[2026\] Qwen Team and XLANG Lab\. Qwen\-CUA: Native computer use for \(almost\) everything\. arXiv preprint arXiv:2608\.02352, 2026\. URL https://arxiv\.org/html/2608\.02352v1\. Goddard et al\. \[2024\] Charles Goddard, Shamane Siriwardhana, Malikeh Ehghaghi, Luke Meyers, Vladimir Karpukhin, Brian Benedict, Mark McQuade, and Jacob Solawetz\. Arcee’s MergeKit: A toolkit for merging large language models\. In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing: Industry Track, pp\. 477–485\. Association for Computational Linguistics, 2024\. doi: 10\.18653/v1/2024\.emnlp\-industry\.36\. URL https://aclanthology\.org/2024\.emnlp\-industry\.36/\. Wang et al\. \[2025\] Taiyi Wang, Zhihao Wu, et al\. DistRL: An asynchronous distributed reinforcement learning framework for on\-device control agents\. In International Conference on Learning Representations \(ICLR\), 2025\. Shi et al\. \[2025\] Yucheng Shi, Wenhao Yu, Zaixi Li, et al\. MobileGUI\-RL: Advancing mobile gui agent through reinforcement learning in online environment\. arXiv preprint arXiv:2507\.05720, 2025\. Wei et al\. \[2025\] Zhepei Wei, Wenlin Yao, Yao Liu, et al\. WebAgent\-R1: Training web agents via end\-to\-end multi\-turn reinforcement learning\. In Conference on Empirical Methods in Natural Language Processing \(EMNLP\), 2025\. Li et al\. \[2025\] Pengxiang Li, Zechen Hu, Zirui Shang, Jingrong Wu, Yang Liu, Hui Liu, Zhi Gao, Chenrui Shi, Bofei Zhang, Zihao Zhang, Xiaochuan Shi, Zedong Yu, Yuwei Wu, Xinxiao Wu, Yunde Jia, Liuyu Xiang, Zhaofeng He, and Qing Li\. Efficient multi\-turn rl for gui agents via decoupled training and adaptive data curation\. arXiv preprint arXiv:2509\.23866, 2025\. Ding et al\. \[2026\] Zihan Ding, Longxu Dou, Qi Gao, et al\. UI\-Mate: Advancing Open\-Weight Foundation GUI Agents with In\-Context Demonstrations\. arXiv preprint arXiv:2608\.15930, 2026\. URL https://arxiv\.org/abs/2608\.15930\. Xi et al\. \[2025\] Zhiheng Xi, Wenxiang Chen, Boyang Hong, et al\. AgentGym: Evolving large language model\-based agents across diverse environments\. In Annual Meeting of the Association for Computational Linguistics \(ACL\), 2025\. GEM Team \[2026\] GEM Team\. GEM: A gym for agentic llms\. In International Conference on Learning Representations \(ICLR\), 2026\. Sheng et al\. \[2025\] Guangming Sheng, Chi Zhang, Zilingfeng Ye, et al\. HybridFlow: A flexible and efficient RLHF framework\. In European Conference on Computer Systems \(EuroSys\), 2025\. Hu et al\. \[2024\] Jian Hu, Xibin Wu, Weixun Wang, et al\. OpenRLHF: An easy\-to\-use, scalable and high\-performance RLHF framework\. arXiv preprint arXiv:2405\.11143, 2024\. Fu et al\. \[2025\] Wei Fu, Jiaxuan Gao, et al\. AReaL: A large\-scale asynchronous reinforcement learning system for language reasoning\. arXiv preprint arXiv:2505\.24298, 2025\. Sun et al\. \[2025\] Qiushi Sun, Kanzhi Cheng, Zichen Ding, et al\. OS\-Genesis: Automating gui agent trajectory construction via reverse task synthesis\. In Annual Meeting of the Association for Computational Linguistics \(ACL\), 2025\. Zhang et al\. \[2026\] Ziyun Zhang, Zezhou Wang, Xiaoyi Zhang, Zongyu Guo, and Yan Lu\. InfiniteWeb: Scalable web environment synthesis with verifiable evaluation\. arXiv preprint arXiv:2601\.04126, 2026\. Sun et al\. \[2025\] Jiahui Sun, Zhichao Hua, and Yubin Xia\. AutoEval: A practical framework for autonomous evaluation of mobile agents\. arXiv preprint arXiv:2503\.02403, 2025\. Wei et al\. \[2026\] Jinbiao Wei, Qianran Ma, Yilun Zhao, et al\. OpenComputer: Verifiable Software Worlds for Computer\-Use Agents\. arXiv preprint arXiv:2605\.19769, 2026\. URL https://arxiv\.org/abs/2605\.19769\. Kang et al\. \[2026\] Hangoo Kang, Tarun Suresh, Jon Saad\-Falcon, and Azalia Mirhoseini\. TRACE: Turning recurrent agent failures into capability\-targeted training environments\. arXiv preprint arXiv:2604\.05336, 2026\. Guo et al\. \[2025\] Jiacheng Guo, Ling Yang, Peter Chen, Qixin Xiao, Yinjie Wang, Xinzhe Juan, Jiahao Qiu, Ke Shen, and Mengdi Wang\. GenEnv: Environment simulator co\-evolution with difficulty\-aligned curriculum\. arXiv preprint arXiv:2512\.19682, 2025\. Appendix A Appendix A\.1 The MAI\-Gym Dashboard Figure 13 shows fleet monitoring, run and benchmark navigation, and step\-by\-step attempt replay\. Figure 13: MAI\-Gym dashboard\. \(a\) Fleet capacity \(1\), usage history \(2\), and sessions \(3\)\. \(b\) Runs \(1\), evaluation rollouts \(2\), and training batches \(3\)\. \(c\) Benchmarks \(1\), scores \(2\), and runs \(3\)\. \(d\) Task and verifier result \(1\), action replay \(2\), and model output \(3\)\. A\.2 Gym Interface and Environment Contract Every environment adapter implements five operations\. reqEnvs\(spec, n\) provisions instances; observe\(h\) returns the current observation; reset\(h, x\) initializes an instance for task xx; step\(h, a\) applies an action; and eval\(h, x\) invokes the task verifier\. The environment manager implements allocation, session management, trajectory recording, and reward delivery once above this contract; Table 8 lists the responsibilities on each side\. Table 8: Responsibilities across the environment contract\. Concern Environment adapter MAI\-Gym Capacity Reports health and available instances Leases sessions, reclaims expired capacity, and assigns attempts Isolation Initializes task state and isolates concurrent instances Keeps one attempt bound to one session for its lifetime Observation Returns screenshots, command output, and metadata Selects the transport and records observations in trajectories Action Executes the declared action vocabulary Parses model output, dispatches actions, and records results Task Installs task state and invokes its verifier Samples tasks, forms rollout groups, and delivers rewards to training Sessions carry leases so that replaced workers cannot continue to act, and mutating operations carry caller\-supplied identifiers so that a retried request does not apply the same action twice\. A\.3 Action Space Table 9 defines the action vocabulary used by MAI\-Gym\. It combines coordinate\-based GUI operations with CLI and API calls, user interaction, and task termination\. Table 9: Action space of MAI\-Gym\. Action Definition GUI Actions click Clicks at coordinates \(x,y\)\(x,y\)\. double\_click Double\-clicks at coordinates \(x,y\)\(x,y\); on touch screens, a double tap\. long\_press Long\-presses at coordinates \(x,y\)\(x,y\)\. type Types the specified text content\. hotkey Presses a key combination, such as ctrl\+c\. open Opens the specified app\. drag Drags from start coordinates \(x1,y1\)\(x\_\{1\},y\_\{1\}\) to end coordinates \(x2,y2\)\(x\_\{2\},y\_\{2\}\)\. system\_button Presses a system button, selected from back, home, menu, and enter\. wait Waits for a specified duration in seconds\. CLI Actions cli\_command Executes a bash command in the active CLI environment\. API Actions api\_call Invokes an API with specified arguments\. Interaction and Control Actions ask\_user Requests information from the user\. terminate Ends the task with a final answer and a status of success or failed\. A\.4 Hyperparameters Unless stated otherwise, runs use the settings below; Section 4 notes settings that differ for individual experiments, and Appendix A\.5 gives the shared configuration structure\. Initialization\. The policy is a Qwen3\.5\-9B backbone and keeps that model’s tokenizer\. Observations are screenshots at the environment’s native resolution, together with command output on computers; actions are emitted in the vocabulary of Appendix A\.3\. Before the RL stage the model is warmed up by supervised fine\-tuning on mixed mobile and computer data\. The joint RL run and the expert runs of Section 4\.3\.2 start from this warm\-up checkpoint\. Optimization\. Unless an experiment says otherwise, the algorithm is GRPO with a group size of 88 and a per\-token loss\. Every policy\-generated token of trajectory ii receives the advantage AiA\_\{i\} of Equation 3\. With 𝒴i\\mathcal\{Y\}\_\{i\} the policy\-generated tokens of trajectory ii and ρu=πθ\(u∣⋅\)/πθold\(u∣⋅\)\\rho\_\{u\}=\\pi\_\{\\theta\}\(u\\mid\\cdot\)/\\pi\_\{\\theta\_\{\\mathrm\{old\}\}\}\(u\\mid\\cdot\) the importance ratio of token uu, the policy maximizes the clipped surrogate \[Schulman et al\., 2017\] ℒ⁡\(θ\)=1∑i\|𝒴i\|​∑i=1G∑u∈𝒴imin⁡\(ρu​Ai,clip⁡\(ρu,1−ϵ,1\+ϵ\)​Ai\)\.\\mathcal\{L\}\(\\theta\)=\\frac\{1\}\{\\sum\_\{i\}\|\\mathcal\{Y\}\_\{i\}\|\}\\sum\_\{i=1\}^\{G\}\\sum\_\{u\\in\\mathcal\{Y\}\_\{i\}\}\\min\\\!\\big\(\\rho\_\{u\}A\_\{i\},\\ \\operatorname\{clip\}\(\\rho\_\{u\},1\-\\epsilon,1\+\\epsilon\)\\,A\_\{i\}\\big\)\. \(4\) The objective carries a KL loss term with coefficient 10−310^\{\-3\} and no entropy bonus; the reward itself is not KL\-penalized, so the constraint acts on the loss rather than on the returns\. Adam runs at a constant learning rate of 10−610^\{\-6\}, with weight decay 0\.10\.1 and \(β1,β2\)=\(0\.9,0\.98\)\(\\beta\_\{1\},\\beta\_\{2\}\)=\(0\.9,0\.98\)\. The micro\-batch is a single sequence, and the unit the trainer counts is the window, not the step or the trajectory, which follows from the window\-wise packing of Section 3\.5\. History uses a window of K=10K=10 steps with an overlap of O=2O=2\. Training runs on Megatron\-LM and generation on SGLang, with the parallelism of Appendix A\.5\. Task Selection\. Within a pool, sampling follows the policy\-adaptive rule of Section 3\.5: a success threshold of η=0\.8\\eta=0\.8 separates mastered tasks from the frontier, and never\-solved and mastered tasks receive reduced budgets of 44 and 22 attempts against the full group of 88\. In the joint run, a rollout round draws from both domains; the pools themselves are the output of the synthesis pipeline of Section 3\.4, and Appendix A\.6 shows what its tasks look like\. Evaluation\. Every benchmark is run through the harness of Section 3\.3 with that benchmark’s own verifier and step limit \(Table 3\)\. Decoding uses temperature 0\.0 with 3 trials per task\. A\.5 Training Configuration A single YAML file configures a training run \(Section 3\.5\): the task pools and the environments behind them, the algorithm, the rollout budget, the history format, and the training backend\. The listing below follows the structure of the file the runs in this paper use\. Values in angle brackets are set per experiment; credentials are never written in the file and are read from the environment at load time\. \\iow\_now:Ne˝\\iow\_now:Ne˝model:\\iow\_now:Ne˝ checkpoint: <SFT warm\-up checkpoint\>\\iow\_now:Ne˝ policy\_variant: <action/response format\>\\iow\_now:Ne˝ tool\_parser: <action parser\>\\iow\_now:Ne˝\\iow\_now:Ne˝tasks: \# pools, and the environment each is served by\\iow\_now:Ne˝ \- pool: <mobile task pool\>\\iow\_now:Ne˝ env\_type: <mobile backend\>\\iow\_now:Ne˝ \- pool: <computer task pool\>\\iow\_now:Ne˝ env\_type: <computer backend\>\\iow\_now:Ne˝\\iow\_now:Ne˝algorithm:\\iow\_now:Ne˝ name: grpo \# or sao, …\\iow\_now:Ne˝ group\_size: 8\\iow\_now:Ne˝ learning\_rate: 1\.0e\-6\\iow\_now:Ne˝ kl\_loss\_coef: 1\.0e\-3 \# KL on the loss, not on the reward\\iow\_now:Ne˝ entropy\_coef: 0\.0\\iow\_now:Ne˝ per\_token\_loss: true\\iow\_now:Ne˝ reward\_allocation: uniform \# terminal advantage on every policy token\\iow\_now:Ne˝\\iow\_now:Ne˝sampling: \# policy\-adaptive task sampling\\iow\_now:Ne˝ success\_threshold: 0\.8 \# eta\\iow\_now:Ne˝ fail\_budget: 4 \# attempts for never\-solved tasks\\iow\_now:Ne˝ mastered\_budget: 2 \# attempts for mastered tasks\\iow\_now:Ne˝\\iow\_now:Ne˝rollout:\\iow\_now:Ne˝ concurrency: <C\> \# trajectories in flight\\iow\_now:Ne˝ num\_sessions: <leased sessions per pool\>\\iow\_now:Ne˝ temperature: <temperature\>\\iow\_now:Ne˝ max\_turns: <step limit\>\\iow\_now:Ne˝ max\_total\_length: <context budget per sample\>\\iow\_now:Ne˝\\iow\_now:Ne˝history:\\iow\_now:Ne˝ window: 10 \# K\\iow\_now:Ne˝ overlap: 2 \# O\\iow\_now:Ne˝ image\_retention: <screenshots kept\>\\iow\_now:Ne˝ token\_native\_history: true \# replay the sampled tokens verbatim\\iow\_now:Ne˝ windowwise\_train: true \# each window becomes one training sample\\iow\_now:Ne˝\\iow\_now:Ne˝observations:\\iow\_now:Ne˝ screenshot\_transport: oss \# inline, or by reference to object storage\\iow\_now:Ne˝\\iow\_now:Ne˝trainer:\\iow\_now:Ne˝ backend: <training backend\>\\iow\_now:Ne˝ parallelism: \{tensor: <tp\>, pipeline: <pp\>, context: <cp\>, data: <dp\>\} A\.6 Synthesized Task Examples Figure 14 shows two presentation tasks from synthesized desktop workspaces\. Comparing print proofs requires settings from a job ticket, handwritten notes, and a confirmation email\. Completing the symposium deck uses planning documents, a budget workbook, and speaker travel estimates\. The verifiers check slide text, dates, chart data, and computed totals in the saved presentations\. \(a\) Comparing print proofs Initial title slide Task\. Read the job ticket, handwritten notes, and confirmation email to consolidate the printing settings for three proofs in Calc\. Add one slide per proof to the comparison deck\. Export the spreadsheet to CSV and the completed presentation to PDF\. Input Files\. Draft presentation, job ticket, studio notes, and the print lab’s confirmation email\. Checks\. CSV and presentation values match the required settings\. Each proof has its own slide, and the PDF includes all three proof labels\. \(b\) Completing a symposium deck Initial title slide Task\. Complete the symposium opening deck using the planning files\. Add the proposed date and venue, each speaker’s role and home city, and the budget items\. Build a budget bar chart in Calc and include it in the deck\. Compute total speaker travel cost from fares and hotel costs, and save the completed presentation as a new file\. Input Files\. Draft presentation, planning documents, budget workbook, and speaker travel estimates\. Checks\. Required slides contain the venue, speaker, and budget facts; the embedded chart has the correct categories and values; the summary reports the computed travel total\. Figure 14: Synthesized desktop task examples\. Screenshots show the initial slides; task instructions and verifier checks are summarized\. Figure 15 shows a mobile example: the street\-tree inventory task applies counting and unit\-conversion rules from a generated survey protocol\. In each case, task files determine the required result\. Mobile: street\-tree inventory Ramona Delgado wants our street tree inventory attached to the Kestrel Ridge application, topped with a one\-page summary\. Analyze the three surveys in your Downloads folder \[…\] using the methodology in Street\_Tree\_Inventory\_Protocol\_2023\.pdf, and save the summary as a new spreadsheet \[…\] one row per street plus a totals row, containing the figures requested in her email\. Finally, reply to her email \[…\] and provide each street’s figures, the totals, and the date each street was last surveyed\. The protocol named in the instruction Figure 15: A mobile task with a generated protocol\. Left: abridged street\-tree inventory instruction\. Right: the protocol specifying counting and measurement rules\. A\.7 Mocked Apps We release seven real\-world clones and 4242 novel apps\. A\.7\.1 Real\-World Clones We build resettable clones of seven apps whose real versions move money, place orders, or publish posts\. Each clone reproduces the main user flows over a backend that restores its state between attempts\. Testers carried out the same tasks in each clone and its real counterpart and compared the screens along the way\. Figure 4 in Section 3\.4\.1 shows these comparisons\. The China Construction Bank tasks require a real bank card, so its pair shows the home screens\. A\.7\.2 Novel Apps The 4242 novel apps contain 840840 tasks at three difficulty levels\. Each app is a deterministic state machine executed in Chromium, and each task specifies an instruction, initial state, step limit, executable completion checks, and a reference action sequence\. The collection contains 3,1963\{,\}196 checks over app state, action history, and submitted answers\. Before release, every reference sequence must complete its task within the step limit\. The validation suite also checks reset restoration, rejects untouched and random\-action states, and verifies agreement between browser and browser\-free execution\.`