Fara1.5: Microsoft's Open-Weight Computer Use Agents Now Beat OpenAI Operator at 27B

Computer use agents — models that drive a real browser by looking at screenshots and emitting mouse and keyboard actions — have been a proprietary capability for most of their short history. OpenAI Operator, Claude’s computer use, Gemini 2.5 Computer Use: all hosted, all closed, all priced per call. Microsoft’s Fara project has been the main open-weight counterargument since the original Fara-7B in late 2025, and on July 22 the team shipped Fara1.5, a full family of computer use models at three scales — 4B, 9B, and 27B — with weights on Hugging Face under the MIT license.

The headline number: Fara1.5-27B scores 72.3% on Online-Mind2Web, which the paper reports ahead of OpenAI Operator (58.3%), Gemini 2.5 Computer Use (57.3%), and Yutori Navigator n1 (64.7%). The 9B model — small enough to self-host on a single consumer GPU — hits 63.4% on the same benchmark, which is better than every proprietary system Microsoft re-ran except its own training-time solver. An open 9B model outbrowsing Operator is a sentence I did not expect to write this year.

What a “Native” Computer Use Agent Actually Is

The architecture detail that matters most is what Fara1.5 does not use. Most web agents — including essentially everything built on general-purpose chat models — operate on an accessibility tree or DOM parse: the page is serialized into a structured text representation, the model reasons over that text, and a separate grounding step maps its chosen element back to screen coordinates. This works, but it has two well-known failure modes: accessibility trees lose visual information (canvas elements, icons without labels, layout cues), and the grounding step is a second model or heuristic that can fail independently of the reasoning.

Fara1.5 is a native CUA. The input is a screenshot plus the conversation history. The output is a thought followed by an action with directly predicted pixel coordinates — click at (x, y), type this text, scroll, search, or manage context. No accessibility tree, no DOM, no separate parsing or grounding model. The model sees what a human sees and points where a human would point.

This is the same design philosophy as the original Fara-7B and as UI-TARS and Operator’s underlying model, but it matters more at 4B–27B scale. Every component you remove from the pipeline is a component that doesn’t add latency, doesn’t need its own hosting, and can’t fail silently upstream of the model. A single vision-language model that goes screenshot → action is the simplest possible computer use loop, and simplicity is what makes a 9B model viable as a local agent rather than a demo.

The loop itself is observe-think-act: screenshot in, reasoning plus action out, execute via Playwright, new screenshot, repeat. The repo’s fara-cli runs exactly this loop against any OpenAI-compatible endpoint, and every run saves the full trajectory — per-step screenshots and a data_point.json with task, actions, observations, and outcome — which makes runs auditable and replayable after the fact.

The Benchmarks, with the Fine Print

Here is the table from the release, trimmed to the rows that matter:

Model	Size	WebVoyager	Online-Mind2Web	WebTailBench (Process)	WebTailBench (Outcome)
GPT-5 SoM	—	90.6	57.7	69.2	45.1
OpenAI Operator†	—	87.0	58.3	—	—
Gemini 2.5 Computer Use†	—	—	57.3	—	—
Yutori Navigator n1†	—	—	64.7	—	—
Fara-7B (prev. gen)	7B	73.5	34.1	48.8	24.1
Fara1.5-4B	4B	80.8	57.3	60.3	27.4
Fara1.5-9B	9B	86.6	63.4	64.5	32.3
Fara1.5-27B	27B	89.3	72.3	72.9	40.2
FaraGen1.5 Solver (GPT-5.4)	—	93.4	83.4	79.6	57.4

† marks numbers sourced from official releases rather than re-run by Microsoft. Fara numbers are averaged over three runs.

Three things to read carefully here.

First, the generational jump is enormous. Fara1.5-9B gains +29.3 points over Fara-7B on Online-Mind2Web, +13.1 on WebVoyager, +8.2 on WebTailBench outcome success. That is not an incremental revision; the 4B model beats the old 7B everywhere. Whatever changed — and the paper says it’s mostly the data pipeline — it changed a lot.

Second, Online-Mind2Web is where the proprietary systems are beatable. On WebVoyager, GPT-5 with Set-of-Marks prompting (90.6%) still edges out Fara1.5-27B (89.3%). WebVoyager tasks are relatively short-horizon. Online-Mind2Web’s live-web, multi-step tasks are where the frontier chat models sit in the high 50s and Fara1.5-27B clears 72 — specialization wins exactly where the tasks get harder.

Third, the outcome column is the honest one. WebTailBench splits scoring into Process Success (were the intermediate steps right) and Outcome Success (did the task actually end in the correct final state). Fara1.5-27B: 72.9 process, 40.2 outcome. The 9B: 64.5 process, 32.3 outcome. These agents take mostly-correct action sequences and still fail the task a majority of the time on WebTailBench’s tail distribution — the multi-step, cross-site, comparison-shopping tasks that look like real usage. Even the GPT-5.4 solver that generated the training data only reaches 57.4% outcome success. Browser automation on the live web remains genuinely unsolved, and Microsoft publishing both columns is more credible than a single blended number would be.

FaraGen1.5: The Data Pipeline Is the Real Product

The model weights are the artifact; FaraGen1.5 is the machine that makes the artifact. It’s a three-stage synthetic data pipeline, and each stage maps to a problem anyone training agents will recognize.

Environments. Two kinds. First, open-internet tasks on live websites — realistic but unverifiable, since you can’t know ground truth on a site you don’t control. Second, six synthetic FaraEnvs — Mail, Calendar, Stream, ML, Stay, Scheduler — which are functional UI clones of real application categories. Clones exist for a specific reason: they simulate domains that are gated by authentication (you can’t have a solver agent create real accounts at scale) or that require irreversible actions (you can’t have it actually book real flights or send real email). Because Microsoft owns the backend of each clone, every task gets execution-based ground-truth verification — the environment itself knows whether the final state is correct, no LLM judge required. This is the same trick as using a test suite instead of a reviewer in coding agents, and it’s the strongest verification signal available.

Solvers. A harness that rolls out tasks using strong frontier models — GPT-5.4 in the reported configuration — paired with a user simulator so rollouts are multi-turn. The user simulator is doing something subtle: it teaches the student model to interact — to ask when a task is missing information, to flag ambiguity, to pause for approval before irreversible actions. Pure single-shot task data can’t teach that behavior because single-shot data contains no clarification episodes.

Verifiers. Three filters over the raw rollouts: the Universal Verifier (an LLM judge for task correctness), an efficiency scorer that penalizes redundant actions, and a critical-point adherence checker that specifically scores the user-interaction behaviors above. Rollouts that fail any filter don’t make the training mix.

The result is roughly 2M training samples: ~60% web trajectories, 12.8% synthetic environments, 12.5% form filling, 8.8% grounding, 4.9% VQA, 0.8% GUI drag tasks, trained as supervised fine-tuning on Qwen3.5 base models. The FaraGen1.5 solver’s own benchmark scores (93.4 WebVoyager, 83.4 Online-Mind2Web) sit well above every Fara1.5 model — that’s the distillation gap, and it’s useful precisely because it shows the headroom: the teacher is still meaningfully better, so the pipeline has room to keep improving the student.

Two companion releases round out the evaluation story. WebTailBench is 609 tasks across 11 real-world task types that existing benchmarks underrepresent — shopping lists, comparison shopping, compositional cross-site tasks. CUAVerifierBench is the more unusual one: a human-annotated benchmark for evaluating the verifiers that score agent trajectories. Each row pairs a Fara trajectory with human reviewer verdicts alongside the Universal Verifier’s and legacy verifiers’ outputs, so you can compute verifier–human agreement (Cohen’s κ, accuracy, F1) against frozen ground truth. Meta-evaluation — measuring the judge, not just the agent — is where agent evaluation is heading, and shipping a public dataset for it is a genuine contribution.

Running It Yourself

The practical path has two branches.

Microsoft Foundry (no GPU). All three models are in the Foundry catalog. Deploy, get an endpoint URL and key, write a small config JSON, and run:

git clone https://github.com/microsoft/fara.git
cd fara
python3 -m venv .venv && source .venv/bin/activate
pip install -e .
playwright install

fara-cli --task "whats the weather in new york now" \
  --endpoint_config azure_foundry_config.json

Self-hosted with vLLM (your GPU). Weights are on Hugging Face. Serve with vllm serve <model> --port 5000 --dtype auto, install with pip install -e .[vllm], and point fara-cli at the local OpenAI-compatible endpoint. The repo notes two settings that matter: context length at least 15,000 tokens (trajectories accumulate screenshots and history fast) and temperature 0. A 9B model in a precision like FP8 or AWQ fits comfortably on a 24GB card; the 27B wants 48GB+ or aggressive quantization. The previous-generation Fara-7B also still has community GGUF builds for LM Studio and Ollama if you want the cheapest possible entry point.

For anything beyond throwaway tasks, use Magentic-UI — Microsoft’s sandboxed browser environment with auditable action logging and user prompts at critical points. Fara1.5 is explicitly a research preview: the team recommends sandboxing, monitoring execution, and keeping it away from sensitive data and high-risk domains. A model that clicks coordinates on your behalf will eventually click the wrong one; the question is whether the blast radius of a wrong click is a closed popup or a sent email.

Why This Release Matters Beyond the Benchmarks

The trajectory here is the story. Eight months ago the open-weight state of the art in computer use was Fara-7B at 34.1% on Online-Mind2Web — a research curiosity, clearly behind every proprietary system. Today an MIT-licensed 27B model beats Operator and Gemini 2.5 Computer Use on that benchmark, and a 9B you can run on a single GPU beats most of them. The gap between “computer use requires a frontier lab’s hosted model” and “computer use runs on your own hardware” is closing faster than almost any other capability gap in the field.

The reasons it matters for agent builders specifically:

Cost and privacy move to the edge. A 9B CUA on local hardware has zero per-call cost and zero data leaving the machine. For pipelines that touch internal tools, authenticated dashboards, or anything with credentials in the page, a local model isn’t a nice-to-have — it’s the only architecture compliance will sign.

Small models compose better in multi-agent systems. In a staged pipeline, you don’t want one expensive model doing everything; you want cheap specialists at the stages that don’t need frontier reasoning. A browser-driving stage powered by a local 9B Fara, feeding extracted results to a stronger reasoner upstream, is a pattern that was uneconomical when every screenshot round-trip cost frontier-model tokens. Fara1.5 makes the browser stage nearly free.

The data recipe is reusable. FaraGen1.5’s structure — synthetic environments with execution-based verification for gated domains, solver rollouts with a user simulator for interaction behaviors, triple verification before data enters the mix — generalizes to any agent domain where human demonstration data is expensive. Which is all of them. The paper (arXiv:2606.20785) documents the pipeline in enough detail to borrow.

Critical-point training is the underrated capability. A computer use agent that asks before it acts irreversibly is worth more than a few benchmark points, because irreversibility is what makes these systems scary to deploy. Training that behavior in — via the user simulator and the critical-point verifier — rather than bolting it on with prompt engineering is the right call, and it’s measurable because CUAVerifierBench-style evaluation exists.

The caveats are real: WebTailBench outcome success shows even the best of these models fails most genuinely hard web tasks, the Fara1.5 evaluation stack is still being updated for full reproducibility, and “research preview” is doing load-bearing work in the safety section. But the direction is unambiguous. Computer use is following the same curve as coding assistants and image generation before it: proprietary first, open-weight fast follower, local deployment within a year. Fara1.5 is what the fast-follower phase looks like when it arrives on schedule.