Model Card: Microsoft Mage-VL-Cowork

🌏 中文版

Model Overview

Highlights

• At just 4B parameters, Mage-VL-Cowork hits 66.0% on OSWorld-Verified — the best public score at the 4B scale, ahead of the 27B Qwen3.6-27B (63.9%), the 72B OpenCUA-72B (44.9%), and Claude Sonnet 4.5 (62.9%) despite Sonnet getting double the step budget (100 steps vs. this model's 50)
• A single vision-language policy carries two built-in channels: screenshot-grounded GUI control (computer_use) and a persistent shell/Python terminal (bash). The model decides for itself, turn by turn, whether to click or to write code — no external router or multi-agent split needed
• Online Hybrid RL (GRPO with verifiable task rewards) adds roughly 10 percentage points over plain Hybrid SFT, while cutting model calls by 13.0% and output tokens by 25.4% — more accurate and cheaper at the same time
• A purpose-built data synthesis engine, Mage-CUA-Forge, drives per-task generation cost down from $0.906 to $0.158 (−82.6%) by reusing skill-level workflows and application-specific preparers instead of running an open-ended agent loop for every task

The five-stage training curriculum stacks capability gradually, and the official technical report breaks the OSWorld-Verified gain down into two clean increments:

Benchmarks

⚠️ All figures above come from Microsoft's own technical report and HuggingFace model card; none have been independently reproduced yet. The headline 66.0% on OSWorld-Verified is the average of two full runs (65.33% and 66.75%) over 361 tasks, excluding Google Drive–dependent tasks.

Versus Predecessor / Competitors

Mage-VL-Cowork is the Mage family's first public agent variant, so there's no predecessor within the family to compare it against — the relevant comparison set is "4B-scale computer-use agents." There it's unambiguous: it beats every open model listed, including the far larger 27B Qwen3.6-27B (63.9%), the 32B EvoCUA-32B (56.7%), and the 72B OpenCUA-72B (44.9%). Against closed frontier models, it also beats OpenAI's CUA at a 50-step budget (31.3%) and Claude Sonnet 4.5 even with double the step budget (62.9%), but it trails GPT-5.4-mini (69.6%, also at 50 steps) and genuine flagship models (GPT-5.5 at 78.7%, Claude Opus 4.7 at 78.0%).

The real differentiator isn't the score — it's the architecture. Most computer-use agents only drive the GUI through screenshots. Mage-VL-Cowork folds GUI control and terminal execution into one policy, letting the model decide for itself when to click and when three lines of Python will do the job faster. In Microsoft's own side-by-side demos, merging cells and charting a spreadsheet in LibreOffice Calc took 39 seconds and 6 steps by editing the file directly through the terminal, versus 9 minutes 56 seconds and 39 steps for the GUI-only 27B Qwen3.6-27B — a 15.3× speedup. Browser-only tasks aren't where it shines, though: on WebVoyager-Static it scores 58.6%, behind the browser-specialist Fara1.5-4B (68.0%), because that model gave up general desktop competence to specialize purely in browsers.

What This Means for Agent Builders

A common pattern in MCP and multi-agent setups is a supervisor or router that decides whether to call a GUI agent or a coding agent. Mage-VL-Cowork shows that this routing decision can be trained directly into a single model's policy, with no extra orchestration layer required.

• If you're building computer-use or RPA-style agents: this "GUI + terminal, model picks the channel" design is worth copying — don't force your front-end model to do structured operations (editing a spreadsheet, a config file, checking a file's state) entirely through screenshots when three lines of shell would do it faster
• If you handle sensitive screens (internal systems, customer data, compliance documents): a 4B model can run locally on a single 16GB GPU in bf16, or 8GB with a 4-bit GGUF, which means screenshots never have to leave your environment for a cloud API — useful wherever data residency matters
• Not a fit: scenarios that touch a real filesystem, network, or credentials directly. Microsoft's own card insists it only run inside an isolated, disposable sandbox or VM, never with real SSH keys, cloud tokens, or password stores mounted, and never against unfiltered external web content (to limit indirect prompt injection)
• If you're building a pure browser agent: this isn't its strength — WebVoyager-Static still trails a smaller browser-specialist model, so a browser-limited task is better served by a model built just for that

Today's Takeaway

I used to assume that "screenshot-based control" and "writing code" had to be stitched together by an external router or multi-agent setup — one model classifies the task, then hands it off to the right specialist. Mage-VL-Cowork's hybrid CUA training shows that routing decision can become part of a single model's policy instead: the same 4B model first builds two independent channels through a five-stage curriculum, then uses RL to learn when to use which — and ends up both more accurate and cheaper in tokens than plain SFT. The lesson for architecture decisions: sometimes the answer to "should we split this into separate agents" is to train both capabilities into one policy first, rather than rushing to decompose into specialists.

References

• microsoft/Mage-VL-Cowork · HuggingFace
• Mage-VL-Cowork official project page
• microsoft/Mage · GitHub
• How to Run Mage-VL-Cowork Locally: Microsoft's 4B Agent Beats Sonnet 4.5 (DEV Community)
• Microsoft's Mage-VL-Cowork fits a desktop agent into 4B parameters (i-scoop.eu)