What happened
Efrain Garay’s November 5, 2026 article reports a local test of Mage-VL-Cowork, Microsoft’s 4-billion-parameter computer-use model. Garay writes that Microsoft released the model on Hugging Face on October 30 and published code in the Microsoft/Mage repository on November 2. Microsoft’s model card reports a 66.0% result on OSWorld-Verified. Garay did not try to reproduce that full benchmark result.
Garay describes Mage-VL-Cowork as a hybrid vision-and-language agent built from Microsoft’s Mage-ViT visual encoder, Qwen3-4B-Instruct-2507, and an adapter between them. The agent can select a computer_use route for actions including clicking, typing, dragging, scrolling, and requesting screenshots, or a bash route for commands in a persistent terminal. Garay ran Microsoft’s official SGLang container on an RTX 4070 Ti SUPER with 16 GB of VRAM. His setup used Fedora with NixOS and Docker; he reports replacing the container’s default GPU-device flag with --device nvidia.com/gpu=0 after the original command failed on his configuration.
The article reports a 90-to-120-second server load time, peak inference memory use of 13,985 MB, 2.47 seconds average response latency, and 72.86 tokens per second. Garay had set thresholds before collecting results: under 180 seconds to load, under five seconds for a 256-token response, and below 15 GB peak VRAM. The run met those thresholds. The model itself weighs 9.48 GB in bfloat16, while the full runtime also reserves memory for the visual stack and key-value cache.
The decisive test used ten synthetic 1,000-by-1,000-pixel panels, each with three or five colored buttons labeled in large type. Garay selected a target button in each panel, ran three shuffled repetitions per panel, and made 30 requests at temperature zero. Each request included the image, Microsoft’s Mage-VL-Cowork system prompt, and an instruction to click a named button. A run counted as successful only if the returned coordinate landed inside the target button’s known rectangle.
Garay reports zero successful clicks in 30 attempts. All 30 model outputs instead made a computer_use tool call requesting a screenshot. A fixed baseline that always returned the center coordinate, (500, 500), hit nine of 30 targets because several generated buttons covered that point; a random-coordinate baseline hit zero. The article also records that every model response included a closing </think> marker, an Action line, and a well-formed tool call, but no opening think marker. Garay suggests the official harness may add that marker, but does not establish the cause.
Garay’s interpretation is that Mage-VL-Cowork was trained for a loop in which the runtime receives an action, executes it, and returns a fresh screen capture. In his one-shot test, the screenshot request becomes a dead end because no harness returns another image. He also tested a text-only prompt and reports that the model began internal agent narration rather than returning the requested word within the response limit. The article does not test the bash route, real desktop captures, or a complete interactive loop.
What the archive adds
New Runtime covered Microsoft’s October 31, 2026 release of Mage-VL-Cowork, including its reported 66.0% OSWorld-Verified result and hybrid GUI-and-code design (earlier coverage). Garay’s measurements are a new fact on that story: they test consumer-GPU operation and probe behavior outside the benchmark interaction loop.
Trend signal
This supports verification bandwidth is the scarce engineering resource. A benchmark score can establish performance in a specified evaluation environment, but it does not remove the work of checking whether the model, prompt, tools, runtime, and target interface behave correctly together. This single test does not settle Mage-VL-Cowork’s overall quality; it shows why integration-specific verification remains necessary.
Why it matters
For a team selecting a computer-use model, the relevant product is not only the checkpoint or its reported benchmark score. It is the checkpoint, system prompt, server, tool schema, action executor, observation-return mechanism, and termination rules working as one system. A policy that sensibly requests a fresh screenshot in its intended environment can stall if a custom integration does not answer that request in the expected way.
The hardware figures are useful, with a narrower claim. Garay’s configuration shows that a 4B hybrid agent can run within a 16 GB consumer GPU budget and generate responses in a few seconds. It does not show that the agent can complete desktop work within that budget. Builders should evaluate both the cost of an interaction and the probability that a sequence of interactions reaches a verified state change.
A practical acceptance test is small: present a visible target, require the intended tool call, execute it in the real interface, and verify the resulting application state. Run that test through the same tool contract and observation loop that production will use. A syntactically valid tool call—or an impressive benchmark result—is not proof that the requested action occurred.
What happens next
- More teams will publish harness-specific computer-use evaluations rather than relying on a single headline score. (6 months, 65%). Watch for: test reports that separate model, runtime, and environment failures.
- Mage-VL-Cowork users will test whether a complete OSWorld-style loop restores click behavior on real desktop tasks. (3 months, 70%). Watch for: replicated runs using the official VM and action executor.
Limits and uncertainty
This was a 30-run test across ten synthetic panels, not a broad desktop-agent evaluation. The panels differed from the Ubuntu-style environment associated with Mage-VL-Cowork’s training and OSWorld evaluation, so the results cannot be treated as a measure of its performance in that environment. Garay stopped at 30 runs rather than the 60 observations originally planned after the result separated from zero.
The article does not test real desktop captures, alternate temperatures, the bash route, another vision-language model under the same protocol, or a harness that fulfills screenshot requests and executes clicks. It also does not independently verify Microsoft’s 66.0% OSWorld-Verified result. The finding is strongest as evidence of a compatibility failure in this particular one-shot setup, rather than proof that the model cannot execute GUI actions in its intended loop.
Skill to build now
Build a harness-compatibility smoke test before evaluating a computer-use model. Use a controlled screen with labeled targets, record the exact image, system prompt, tool definitions, returned call, executed action, and resulting screen state. Run it through the production observation loop rather than only through an API completion endpoint. If you use screenshots as a tool, define who supplies the next capture and how the loop stops.
Reader takeaway
Mage-VL-Cowork ran within 16 GB of VRAM in Garay’s test, but its 30 screenshot-only responses show that local inference feasibility and usable computer control are separate claims. Evaluate the full model-and-harness system, and verify real state changes in the environment where your agent will operate.