UI-MOPD: Multi-Platform On-Policy Distillation for Continual GUI Agent Learning

Niu Lian, Alan Chen, Zhehao Yu, Chengzhen Duan, Fazhan Liu, Hui Liu, Pei Fu, Jian Luan, Yaowei Wang, Shu-Tao Xia, Jinpeng Wang

UI-MOPD uses platform-conditioned on-policy distillation to train a single GUI agent across heterogeneous desktop and mobile environments.

How can we train a single GUI agent to perform effectively on both desktop and mobile platforms without the behavioral interference that occurs when naively merging platform-specific models?

GUI agents struggle to adapt across heterogeneous platforms like desktop and mobile because different interaction conventions—such as mouse-based windowing versus touch-based navigation—cause behavioral pattern mixing and catastrophic forgetting during training. UI-MOPD addresses this by routing platform-specific rollouts to corresponding expert teachers during online reinforcement learning, using multi-teacher on-policy distillation to anchor the shared policy to native interaction patterns. This approach achieves task success rates of 38.2% on OSWorld and 12.0% on MobileWorld, significantly outperforming standard mixed-data fine-tuning and static model merging.

Paper Primer

The core challenge is that a shared policy trained on mixed desktop and mobile data tends to "average out" interaction styles, leading to poor performance on both. UI-MOPD solves this by treating multi-teacher integration as a conditional behavioral constraint: the student samples rollouts online, and the system applies a platform-specific teacher penalty only to the states actually visited by the student.

UI-MOPD is a platform-conditioned distillation framework: it routes rollouts to the appropriate expert teacher based on the environment, effectively pinning the shared policy to platform-specific behavioral anchors while allowing it to improve via reinforcement learning. This is like a student learning two different sports from two specialized coaches, where the student practices both but receives feedback from the coach relevant to the specific court they are currently on.

UI-MOPD significantly improves cross-platform task success rates compared to base models and integration baselines.

Evaluations on OSWorld and MobileWorld benchmarks show consistent gains over mixed-SFT and model-merging strategies. 38.2% success on OSWorld (12.7% relative improvement) and 12.0% on MobileWorld (55.8% relative improvement) for an 8B student model.

Platform-conditioned distillation preserves static GUI grounding better than static parameter merging.

On grounding benchmarks like ScreenSpot-Pro and OSWorld-G, UI-MOPD maintains performance near the base model, whereas TIES merging shows a clear decline. Maintains 90.88% on ScreenSpotV2 compared to 88.60% for TIES merging.

Why is this approach better than simply merging two specialized models?

Static merging (like weight averaging) often leads to interference between heterogeneous interaction patterns, causing a drop in performance. UI-MOPD uses online distillation to align the shared policy with expert behaviors only on the states it actually visits, which prevents the "averaging" effect and preserves platform-specific interaction modes.

Does this method require multiple models at inference time?

No. The platform-specific teachers are only used during the training stage to provide behavioral anchors. At inference time, the student is a single, unified policy that has internalized the interaction patterns of both platforms.

The primary assumption is that high-quality, platform-specific expert teachers can be pre-trained via supervised fine-tuning to serve as stable anchors for the distillation process.

For researchers building multi-platform agents, UI-MOPD demonstrates that platform-conditioned on-policy distillation is a more robust way to handle heterogeneous action spaces than simple data aggregation or weight-based model merging.

Motivation and Problem Framing

We expose why naïve cross‑platform training collapses distinct GUI behaviors and outline the UI‑MOPD solution.

Training a single GUI agent on both desktop and mobile environments forces the model to reconcile incompatible interaction conventions, which leads to behavioral pattern mixing, platform‑specific capability loss, and catastrophic forgetting when new platforms are added.

When one policy is forced to imitate both desktop‑style clicks and mobile‑style swipes, it produces a blended behavior that satisfies neither platform’s conventions.

UI‑MOPD tackles this entanglement by routing each rollout to a platform‑specific teacher and distilling the teacher’s behavior into a single shared policy, thereby preserving platform‑specific priors while still learning a unified model.

**Figure 1.** Motivation of UI-MOPD. Naively combining desktop and mobile signals, as in model merging or mixed SFT, can mix platform-specific behavioral conventions and produce an averaged policy. UI-MOPD uses platform-conditioned routing and multi-teacher on-policy distillation to integrate platform-specific expertise into a shared GUI agent.

Naïve model merging or mixed supervised fine‑tuning collapses platform‑specific interaction conventions, yielding an averaged policy that fails on both desktop and mobile tasks.

The UI-MOPD Training Pipeline

Method details the two‑stage UI‑MOPD pipeline, on‑policy distillation, and platform‑conditioned routing.

Training a single agent on both desktop and mobile forces it to blend distinct interaction conventions, so it loses fidelity on each platform. The remedy must keep platform‑specific behaviors separate while still sharing a single model.

The method proceeds in two stages: first we fine‑tune separate teacher policies for each platform, then we distill their expertise into one shared student via on‑policy reinforcement learning.

How does UI‑MOPD differ from simply averaging the logits of two teachers?

Averaging mixes the distributions before the student sees any data, erasing platform‑specific peaks. UI‑MOPD routes each rollout to the teacher that matches its platform, so the KL penalty preserves the distinct shape of each teacher’s distribution for the states the student actually visits.

Collect unified cross‑platform trajectories with the harness (desktop + mobile).

Fine‑tune a vision‑language model on each platform’s trajectories → obtain teachers $\pi$ᵈ and $\pi$ᵐ.

Initialize the shared student $\pi$_$\theta$ (e.g., from the foundation model).

Sample a minibatch of rollouts from mixed‑platform prompts using the current student.

Partition the batch by platform label and compute teacher log‑probabilities with the matching teacher.

Apply the K3 estimator to obtain token‑level KL estimates and mask them with the adaptive KL mask.

Compute the clipped policy‑gradient loss and combine with the masked KL loss (Eq 9‑11).

Update $\pi$_$\theta$ with a gradient step; repeat.

During online rollouts the student is nudged toward the platform‑specific teacher by minimizing a KL divergence computed on the very states it just visited.

Why not compute the full KL over the vocabulary instead of using K3?

Full KL requires summing over thousands of tokens for every time step, which is prohibitively expensive in RL. K3 uses only the sampled token’s probabilities, giving an unbiased estimate at a fraction of the cost.

Compute the log‑ratio: $\delta$ = log 0.6 − log 0.4 ≈ 0.405.

Exponentiate: $\rho$ = exp($\delta$) ≈ 1.5.

Apply K3 formula: Ď_KL = $\rho$ − $\delta$ − 1 ≈ 1.5 − 0.405 − 1 = 0.095.

The estimate is non‑negative and reflects that the teacher is modestly more confident in the sampled token.

K3 gives a cheap, unbiased KL estimate using only the sampled token, avoiding a full‑vocab sum while still penalizing the student when its confidence lags behind the teacher.

Each rollout is sent to the teacher that matches its platform label, so the KL penalty never mixes desktop and mobile logits.

Is platform‑conditioned routing just a fancy way of training two separate agents?

No. The student remains a single set of parameters; routing only selects which teacher’s logits are used for the KL term. At inference time the student operates without any teacher, unlike training two independent agents.

Routing selects the desktop teacher for rollout 1 and the mobile teacher for rollout 2 (Eq 6).

Compute $\delta$ for rollout 1: log 0.7 − log 0.5 ≈ 0.336; for rollout 2: log 0.6 − log 0.3 ≈ 0.693.

Apply K3 to each: Ď_KL₁≈exp(0.336) − 0.336 − 1≈0.058; Ď_KL₂≈exp(0.693) − 0.693 − 1≈0.099.

Masking ($\mu$) may zero out either estimate if the corresponding rollout already achieved high reward.

Routing guarantees that each KL estimate reflects the correct platform’s expert, so the student receives distinct corrective signals for desktop and mobile behaviors.

**Figure 2** Overview of UI-MOPD training pipeline. In Stage 1, platform-specific desktop and mobile teachers are obtained by supervised fine-tuning on Uni-GUI trajectories collected from a unified cross-platform harness. In Stage 2, a shared student policy is trained with multi-teacher on-policy distillation, where platform-conditioned routing selects the corresponding teacher to provide reverse-KL guidance together with rule-based rollout rewards.

Beyond routing, the method defines a structured outcome reward and a combined optimization objective that balances task success with platform‑specific constraints.

The final loss adds a clipped policy‑gradient term (for task reward) to a masked KL distillation term (for platform fidelity), weighted by $\beta$.

What would happen if the KL mask $\mu$ were always set to 1?

The student would be constantly pulled toward the teacher distributions, suppressing exploration and potentially preventing it from discovering higher‑reward strategies that differ from the teachers.

Performance Evaluation

UI‑MOPD delivers the strongest cross‑platform success rates.

UI‑MOPD improves cross‑platform task success more than any baseline.

Table 1 shows UI‑MOPD (8B student) at 38.2 % on OSWorld and 12.0 % on MobileWorld, beating Mixed‑SFT and TIES‑merging.

OSWorld is a desktop GUI benchmark that measures how often an agent completes 361 scripted tasks.

What does a “task‑success” percentage actually count?

It counts a task as successful only if the agent reaches the final goal state without timing out or triggering an error, matching the benchmark’s strict success definition.

MobileWorld evaluates mobile GUI agents on 117 tasks, reflecting touch‑centric interaction patterns.

Why is MobileWorld performance typically lower than OSWorld?

Mobile interactions involve additional modalities (swipes, virtual keyboards) and tighter screen real‑estate, making the same policy harder to transfer without platform‑aware adaptation.

TIES‑merging statically averages the weights of two platform‑specific models to produce a single multi‑platform policy.

How does TIES‑merging differ from UI‑MOPD’s platform‑conditioned distillation?

UI‑MOPD keeps the teachers separate during online distillation and routes rollouts to the appropriate teacher, preserving distinct interaction patterns, whereas TIES‑merging collapses them into a single static weight vector.

**Table.** Performance comparison of different models and integration strategies on OSWorld and MobileWorld.

**Table 2.** Teacher-student analysis on OSWorld and MobileWorld.

**Table 3.** General GUI grounding, visual understanding, and AndroidControl* results. The star denotes the evaluated subset. The Model Merge row corresponds to the TIES-merging checkpoint.

UI‑MOPD outperforms TIES‑merging and mixed SFT across both platforms.

Data Collection and Harness

We describe the unified harness that builds a clean cross‑platform GUI dataset.

Cross‑platform GUI training suffers from noisy, mismatched demonstrations because desktop and mobile environments differ in observation formats, action primitives, and UI layouts. Without a disciplined pipeline, many collected trajectories are unusable for learning.

The harness enforces a strict four‑stage workflow that turns raw, platform‑specific interactions into a single, clean dataset usable by a unified student policy.

Step 2 appears twice → malformed step structure detected.

“swipe” action is not in the unified action set → unmappable action filtered out.

Remaining steps count = 5 (< 40) → length filter passes.

Query “open settings” matches a known functional point on the desktop environment → query‑environment check passes.

Gemini‑3.1‑Pro judges the cleaned trajectory, verifies all sub‑tasks (e.g., “click Settings”, “navigate back”) succeed → trajectory retained.

The cleaning pipeline guarantees that every kept demonstration is both syntactically well‑formed and semantically executable by the student policy.

How does this harness differ from a naïve data‑collection script that simply records every interaction?

The naïve script would capture all raw actions, including malformed sequences, platform‑specific primitives the student cannot imitate, and failed tasks. Our harness inserts four explicit quality controls—syntactic validation, action‑space mapping, length capping, and sub‑task verification—so only clean, executable demonstrations survive.

**Figure 4.** Overview of Unified Cross-Platform Data Collection Harness.

Applying the harness yields the Uni‑GUI dataset: ≈95 K desktop steps (self‑collected) + 13 K OpenCUA steps, and ≈17 K mobile steps (self‑collected) + 35 K OpenMobile steps, totaling about 160 K steps and 11.5 K trajectories.

The table summarizes the dataset composition across different platforms and source types, detailing the number of steps and trajectories for each category, culminating in a total of approximately 160K steps and 11.5K trajectories.

The harness enables consistent data collection across heterogeneous environments.

Qualitative Analysis

Fine‑grained performance of UI‑MOPD across mobile and desktop benchmarks.

Training a single GUI agent across desktop and mobile platforms often leads to Behavioral Pattern Mixing, where platform‑specific interaction conventions become entangled. UI‑MOPD mitigates this by routing inputs through platform‑conditioned modules and distilling knowledge on‑policy from specialized teachers.

UI‑MOPD attains the highest overall accuracy on the OSWorld‑G grounding benchmark, reaching 90.88%.

Table 7 shows UI‑MOPD at 90.88% versus 87.02% for the Base model and 88.33% for Model Merge.

**Figure 3.** Mobile task execution example of UI-MOPD.

**Figure 5.** Desktop task execution example of UI-MOPD.

Table 7 reveals that Model Merge consistently degrades mobile metrics, while UI‑MOPD preserves or improves performance across all benchmarks. On ScreenSpot‑Pro and ScreenSpotV2, UI‑MOPD matches the Base model and outperforms it on Creative, Scientific, and desktop grounding sub‑categories. The overall trend confirms that multi‑teacher on‑policy distillation retains fine‑grained GUI understanding while boosting cross‑platform interaction.

Training Configuration

Details of action formatting, trajectory storage, and training hyperparameters for both platforms.

We re‑annotate grounding bounding boxes for actions that refer to visual UI elements. These boxes are later used by a rule‑based evaluation stage to verify that each action targets the correct region. Consequently, the harness outputs a set of successful, executable, action‑compatible, reasoning‑normalized, and visually grounded GUI trajectories for both mobile and desktop platforms.

The prompt templates (see Appendix F) define platform‑specific tool interfaces used by Qwen3‑VL policies. Desktop trajectories employ the `computer_use` interface with mouse and keyboard actions, while mobile trajectories use the `mobile_use` interface with touchscreen actions. Table 5 summarizes the full action spaces.

The table lists the platforms, tools, and available actions for computer and mobile use.

Each trajectory is stored as an episode directory. A mobile episode contains a normalized trajectory file task.json, a raw generation record `task_raw`.json, and step‑indexed screenshots (e.g., 0.jpg, 1.jpg). The normalized file records metadata such as task source, application name, screen resolution, user query, device type, and train/test split, plus a data field with per‑step records (index, query, normalized reasoning, tool‑call plan, grounding boxes, screenshot path, and flags). The raw file preserves the original prompt, model response, and conversion details for traceability.

Table 6 aggregates the hyperparameters used throughout training. The student policy starts from Qwen3‑VL‑8B‑Thinking, while platform‑specific teachers are initialized from Qwen3‑VL‑32B‑Thinking. Both teacher SFT and student training run for a single epoch.

**Table 6.** Training hyperparameters. TP, PP, and DP denote tensor, pipeline, and data parallelism, respectively.

Student training uses a GRPO‑based DAPO objective with multi‑teacher on‑policy distillation; each prompt samples eight rollouts and the OPD auxiliary KL loss is weighted by $0.01$. Visual inputs during training consist of the current screenshot only, whereas inference incorporates four historical screenshots plus the current one and the full text action history. Optimization runs on $64$ NVIDIA H100 GPUs (8 nodes × 8 GPUs) with tensor, pipeline, and data parallelism configured as TP$=2$, PP$=1$, DP$=32$ for the student and TP$=8$, DP$=8$ for the teacher. Learning rate is $1\!\times\!10^{-6}$ in bfloat16 precision, and rollout sampling is performed asynchronously by SGLang.

System Prompts

Four system prompts define desktop and mobile interfaces and trajectory‑collection formats.

The Desktop System Prompt for Qwen3‑VL lists a single function “`computer_use`” with actions such as `mouse_move`, `left_click`, and wait, and mandates a two‑part response: an imperative Action line followed by a JSON block.

The Mobile System Prompt for Qwen3‑VL defines a “`mobile_use`” function supporting touch actions like click, swipe, and `long_press`, and requires three‑part output: Thought, Action, and a JSON block.

The Desktop Trajectory Collection Prompt (Kimi‑K2.6) instructs the agent to emit a Thought line, a “## Action:” line, and a “## Code:” block containing either pyautogui code or calls to helper functions such as computer.wait or computer.terminate.

The Mobile Trajectory Collection Prompt (Gemini‑3.1‑Pro) defines an Android operator role, an action‑framework table mapping verbs to JSON schemas, and a set of Execution Principles and Decision Process steps that shape the single‑JSON output.

Read the original paper

Open the simplified reader on Paperglide

Browse all simplified papers