Mobile-Agent: What X-PLUG's GUI Agent Family Actually Ships

The problem Mobile-Agent addresses

Mobile-Agent targets a specific gap: getting a multimodal model to operate a graphical interface it has never been specifically programmed for. The README describes GUI-Owl-1.5 as a family of native multi-platform GUI agent foundation models supporting desktop, mobile and browser automation, built on Qwen3-VL. The repository is the home for that model line plus the agent harnesses around it, including Mobile-Agent-v3 and Mobile-Agent-v3.5. The audience is narrower than the topic list suggests. This is aimed at engineers who can run or call a multimodal model and want an agent loop on top of it, plus researchers reproducing benchmark results on OSWorld and AndroidWorld. It is not a drop-in automation library for people who want to script taps on one app. The README points at an online demo on ModelScope and Bailian for the current version, which tells you the intended first contact is a hosted endpoint rather than a local install.

What is actually inside the repository

The default branch is main and the primary language is Python. The README's news entries name several subdirectories that carry the code: Mobile-Agent-v3.5 for the current model family, Mobile-Agent-v3 for the OSWorld and AndroidWorld evaluation code and for real-world mobile deployment, and UI-S1 for the semi-online reinforcement learning work. ToolCUA lives in a separate repository, X-PLUG/ToolCUA, not here. That split matters when you estimate scope, because a single checkout does not give you every component the news list mentions. The licence is MIT, which is permissive and places few restrictions on redistribution or modification. Note the boundary: the MIT licence covers the repository's code, not the model weights. GUI-Owl-1.5 weights are distributed through Hugging Face and ModelScope collections, and the terms attached to those weights are separate from the code licence. The README does not state those terms, so read them on the model pages before you plan a commercial deployment.

The mechanism: models plus an agent loop

The architecture visible in the material has two layers. The lower layer is the GUI-Owl-1.5 model family, described as native multi-platform GUI agent foundation models at 2B, 4B, 8B, 32B and 235B parameters, in Instruct and Thinking variants. The README says these support desktop, mobile and browser automation and handle end-to-end tasks, grounding, tool and MCP calling, and long-horizon memory. The upper layer is the agent harness. Mobile-Agent-v3.5 is the current version, and the README links its own README under the Mobile-Agent-v3.5 path. ToolCUA, announced separately, is described as an end-to-end Computer Use Agent for GUI-tool path orchestration with a two-stage training pipeline: trajectory-aware tool synthesis, then online agentic reinforcement learning. The stated goal is deciding when to act through the GUI, when to invoke a tool, and when to switch between the two. That is the interesting design claim in the whole repository, and it is also the part with the least implementation detail in the README itself. The README points to a paper and a separate repository for it.

Getting it running: the paths the README names

There is no top-level install command in the supplied material. The routes the README actually gives are these. For a hosted trial, use the ModelScope studio at modelscope.cn/studios/MobileAgentTest/computer_use or the Bailian demo. For the API, the README says Mobile-Agent-v3.5 is available on Bailian and links the model market page for gui-plus-2026-02-26. For weights, the GUI-Owl-1.5 collection is on Hugging Face under mPLUG and on ModelScope under iic, with GUI-Owl-32B and GUI-Owl-7B listed individually. For local evaluation, the README points to the Mobile-Agent-v3 directory and names two anchors: evaluation on OSWorld and evaluation on AndroidWorld, plus a section titled 'deploy Mobile-Agent-v3 on your mobile device'. Those anchors are the real entry points. Because the README does not include the commands themselves in the material provided here, treat the subdirectory READMEs as the source of truth and expect to read them before you can run anything. A released RL-tuned checkpoint, GUI-Owl-7B-Desktop-RL, is also published on Hugging Face.

Where the family structure becomes a cost

The honest limitation is that Mobile-Agent is a research monorepo, not a product. The README is organised as a news feed, with entries dated from 2025 into 2026, and each entry announces a paper, a model, a demo or a benchmark. That format tells you what the team has been publishing, not what is supported. Nothing in the material indicates a stable, versioned Python API that you can pin against. If your integration expects a package with semantic versioning and a changelog, this repository will not give you that. A second constraint is the cloud dependency. The current version's quickest path runs through Alibaba Cloud Bailian or ModelScope, and the news entry from 2026.3.31 describes Mobile-Agent-v3.5 on Alibaba Cloud Wuying Cloud Phone as a cloud-based Android environment. A team that needs fully offline operation on its own hardware is looking at self-hosting GUI-Owl weights, and the README does not state the hardware requirements for the larger variants. The 235B model in particular is not something most teams will run locally, and the material says nothing about quantised or smaller-footprint deployment.

How it differs from Appium-style automation

The nearest established alternative is scripted UI automation in the Appium and Selenium tradition, where you locate elements by accessibility identifiers, resource IDs or XPath and write explicit steps. The difference in approach is fundamental. Appium requires a stable selector and a test author who knows the flow in advance. Mobile-Agent instead asks a multimodal model to look at the screen and decide the next action, which is why the README frames GUI-Owl-1.5 around grounding and long-horizon memory rather than selectors. That buys you tolerance for interfaces you cannot instrument, and it costs you determinism. A scripted Appium test either finds the element or fails with a clear error. A model-driven agent can take a plausible but wrong action, and the README does not describe a verification or rollback layer in the material provided. For a regression suite on an app you control, Appium remains the more predictable tool. For an app you do not control, or a flow whose steps you cannot enumerate, the model-driven route is the one that has a chance of working at all.

Maintenance, releases and what to watch

The repository is not archived and the last push recorded in the metadata is 2026-07-07. No releases were retrieved, which is consistent with a project that distributes through model hubs and repository subdirectories rather than tagged packages. Maintenance cost therefore falls on you in a specific way: you track a moving main branch, and the components you depend on are identified by directory name (Mobile-Agent-v3.5, Mobile-Agent-v3, UI-S1) rather than by version tag. Pin to a commit hash rather than a branch name if you build on this. The MIT licence on the code is straightforward for commercial use; the model weights carry their own terms on Hugging Face and ModelScope, and the README does not reproduce them. The API route through Bailian is governed by Alibaba Cloud's terms, which is a different question again. None of this is legal advice, but the three layers (code, weights, hosted API) have three separate sets of conditions, and conflating them is the easy mistake to make here.

Editorial conclusion

Adopt Mobile-Agent if you are building or evaluating GUI automation on Android, desktop or browser and you are comfortable running GUI-Owl checkpoints or calling the hosted Bailian endpoint. Do not adopt it if you need a single stable Python package with a versioned API surface, or if your target app is not covered by the benchmarks the repository names. Before writing code, verify three things: which subdirectory matches your target platform (Mobile-Agent-v3.5 for the current models, Mobile-Agent-v3 for the OSWorld and AndroidWorld evaluation code), whether you will self-host GUI-Owl weights or depend on the Bailian and ModelScope endpoints, and whether your use case needs the ToolCUA GUI-tool switching behaviour or plain GUI actions are enough.

Official sources

1. Issues
2. License: MIT
3. README
4. X-PLUG/MobileAgent on GitHub