Microsoft Mage-VL-Cowork on a Mac: 2.7GB Q4 Fits 16GB, No Runtime

Microsoft's Mage-VL-Cowork is a 4B computer-use agent whose only quantized build is a 2.716 GB Q4_K_M GGUF plus a 0.353 GB vision projector, so memory is not the problem on any 16GB Mac. Software is. On October 31, 2026, no stock llama.cpp, Ollama or LM Studio build can load its vision projector, the MLX port sits in an open pull request, and Microsoft documents only an NVIDIA GPU server. Here is what fits, what blocks it, and what to watch.

What is Microsoft Mage-VL-Cowork?

Mage-VL-Cowork is a single vision-language policy that operates a desktop two ways: it clicks and types on screenshots through a computer_use tool, and it runs shell commands through a bash tool. Microsoft published it on Hugging Face on October 30, 2026 under Apache 2.0, trained from an intermediate checkpoint of its Mage-VL base model (model card, 2026).

The idea is channel routing. The card's example task asks the agent to merge spreadsheet cells, and the model skips the GUI and edits the file with openpyxl in the terminal. For a canvas or a live app window it falls back to the mouse.

Under the hood, the raw config shows a llava_onevision2 architecture: a 24-layer vision tower with 16-pixel patches in front of a Qwen3-4B-Instruct-2507 text decoder with 36 layers and 8 key-value heads. The config allows 262,144 positions, but the card states the training and inference window is 32,768 tokens. Plan for 32K.

How good is it, by Microsoft's numbers?

Microsoft reports 66.0% on OSWorld-Verified under a 50-step budget, the two-run average of 65.33% and 66.75% on 361 tasks (model card, 2026). These are vendor figures, run with Microsoft's own agent harness on Linux desktops at 1920x1080, and no independent lab has reproduced them yet.

The breakdown matters more than the headline. The card lists 87.5 on operating-system tasks and 62.7 on multi-application workflows. It also credits online reinforcement learning with a 10.16-point gain over the supervised stage, while cutting model calls by 13.0% and output tokens by 25.4%. Fewer calls is the figure a local user should care about, because every call re-reads screenshots.

On the browser side, the supervised checkpoint scores 58.6% on WebVoyager-Static, behind the browser-only Fara1.5-4B. Read the whole table as a claim from the people who trained the model.

How much memory does Mage-VL-Cowork need on a Mac?

Not much for the weights. The official repository holds BF16 safetensors in two shards of 4,563,695,792 and 4,919,972,344 bytes, 9.484 GB in total (Hugging Face API, 2026). The card rounds the same figure to 9.48 GB.

The only quantized build is community work. The Hansda/Mage-VL-Cowork-GGUF repository, created on October 30, publishes these files, byte counts from its blobs API converted to decimal gigabytes:

Every decoder file needs the shared 0.353 GB vision projector next to it, so Q4_K_M plus projector is 3,069 MB. Microsoft has published no GGUF, MLX or other quantized build of Cowork itself.

The KV cache is the second cost. From the config, each token stores 36 layers times 8 heads times 128 dimensions for keys and values at 16-bit, which is 147,456 bytes. ModelFit's arithmetic: a full 32,768-token window costs 4,832 MB, and an 8,192-token window costs 1,208 MB. One 1920x1080 screenshot is roughly 2,000 tokens at 16-pixel patches merged two by two, and the card's agent keeps the last 3 screenshots in context, so agent runs fill the window quickly.

Which Mac can run it once a runtime exists?

A 16GB Mac runs the Q4 build with the full 32K window; a 24GB Mac runs the original BF16 weights with it. ModelFit gives a model 70% of unified memory at 32GB and below, ramping to 85% at 128GB, the same budget behind the homepage picks and the RAM guide for local LLMs. Totals below are weights plus f16 KV cache in decimal megabytes, before runtime buffers:

On 8GB, Q4 with an 8,192-token window totals 4,277 MB and fits the 5,600 MB budget, which leaves room for about three screenshots plus the prompt. On 16GB, BF16 with an 8K window is 10,692 MB against 11,200 MB: it fits, with almost nothing spare for the runtime. The 8GB Mac guide explains why that budget is lower than the RAM on the box. ModelFit shows no tokens per second here: the model is not in the engine catalog, and nothing has been run.

Why can't Ollama, LM Studio or llama.cpp run it today?

Because the vision projector type it needs, magevl, is not in upstream llama.cpp, and every one of those apps builds on llama.cpp. The GGUF repository's runtime-info.json says so itself: it names a contributor fork, points at upstream pull request 26796, and records upstream_merged: false.

That pull request, "add LocateAnything and Mage-VL projectors", was opened on August 9, 2026 and closed on August 10 without being merged, according to the GitHub API read on October 31. The projector code in llama.cpp master has no magevl entry. The GGUF files were validated on one NVIDIA RTX 5060 Ti 16GB with that fork, never on a Mac.

• Ollama: no library tag. registry.ollama.ai returns 404 for both mage-vl-cowork and mage-vl, so there is no ollama run command to give.
• LM Studio: uses the upstream llama.cpp engine on GGUF files, so it cannot read the projector either. Its MLX engine hits the next problem.
• MLX: mlx-vlm already supports the base Mage-VL, but Cowork declares a different model type. Pull request 2636, "Add native Mage-VL-Cowork support", opened by the mlx-vlm repository owner on October 30, was still open and unmerged on October 31. Until it merges and ships in a release, mlx_vlm will not load the repository. For how the two Mac runtime families differ, see MLX vs Ollama on a Mac.

Is there any way to run it on a Mac right now?

Only off the paved road. Microsoft's card documents two paths: an SGLang Docker container built for NVIDIA GPUs with CUDA, and a Python Transformers example that loads the BF16 weights with trust_remote_code=True. The bundled modeling code falls back to plain PyTorch attention when flash-attn is missing, so the Transformers path is not tied to CUDA on paper. Microsoft does not mention Apple Silicon, and no one has published a Mac run of it.

The BF16 route needs the 9.484 GB of weights plus cache, which puts it at 24GB in the table above. The fork route through the community GGUF means building an unmerged llama.cpp branch that was only tested on an NVIDIA card. Both are experiments, not installs. Most readers should wait for the mlx-vlm pull request, which would give a Mac-native path; its author already validated a local 4-bit conversion.

What should you know before letting it drive a desktop?

The card is blunt: the model executes arbitrary shell commands and GUI actions, and Microsoft designed and evaluated it for isolated, disposable sandboxes such as Docker containers or snapshot-reverted virtual machines. Its benchmark desktops were Linux. Pointing it at your own macOS session is outside what was tested.

If you want a local agent that runs on a Mac today, our LFM2 and LocalCowork setup guide covers a tool-calling agent with a working Apple Silicon install, and the 16GB Mac roundup lists the models that already run on the most common tier. To find the best model for your exact Mac, start from the ModelFit homepage.

FAQ

Can I run Mage-VL-Cowork with Ollama?

No. Ollama has no library tag for Mage-VL-Cowork or the base Mage-VL, and its registry returns 404 for both names on October 31, 2026. Importing the community GGUF would not help either, because the vision projector type the model needs is not in upstream llama.cpp. The pull request that added it was closed without being merged in August.

How much RAM does Mage-VL-Cowork need?

The community Q4_K_M GGUF is 2.716 GB plus a 0.353 GB projector, and a full 32K-token cache adds 4,832 MB by ModelFit's arithmetic from the config. That totals 7,901 MB, which fits the 11,200 MB budget of a 16GB Mac. The original BF16 weights are 9.484 GB and need a 24GB Mac with the full window.

Does Mage-VL-Cowork work with MLX on Apple Silicon?

Not yet. mlx-vlm supports the base Mage-VL model, but Cowork uses a different model type. Pull request 2636 in mlx-vlm adds native Cowork support; it was opened on October 30, 2026 and was still unmerged on October 31. Once it lands in a release, an MLX conversion becomes the most direct Mac path.

Is the 66.0% OSWorld-Verified score independent?

No. It is Microsoft's own figure from the model card, the average of two runs with its own agent harness on 361 Linux desktop tasks under a 50-step budget. It puts the 4B model just above the 65.9 reported for Muse Glimmer-30B in the same table. No outside lab has published a reproduction yet.

Sources

• microsoft/Mage-VL-Cowork model card (raw README, benchmarks, context window, sandbox guidance)
• Mage-VL-Cowork config.json (architecture, layers, key-value heads)
• Hugging Face API, microsoft/Mage-VL-Cowork (shard sizes, creation date)
• Hugging Face API, Hansda/Mage-VL-Cowork-GGUF (community GGUF sizes)
• Hansda/Mage-VL-Cowork-GGUF runtime-info.json (fork, projector type, validation GPU)
• llama.cpp pull request 26796, GitHub API (closed, not merged)
• mlx-vlm pull request 2636 (open on October 31, 2026)