Verdict: Microsoft's Fara 1.5-27B is the most capable open-weight browser automation agent you can run today. It scores 72.3% on the Online-Mind2Web benchmark (300 tasks across 136 popular websites), outperforming OpenAI Operator (58.3%), Google Gemini 2.5 Computer Use (57.3%), and Yutori Navigator n1 (64.7%) — all of which are larger or closed-weight. The 4B version fits on a single GPU and still beats Operator. If you need to automate repetitive web work without handing credentials to a third-party API, this is the model family to start with. The catch: it is English-only, misses long multi-step cross-site tasks ~60% of the time, and must run sandboxed to be safe.
Last verified: 2026-08-03
- Three sizes, all open-weight (MIT): Fara1.5-4B, Fara1.5-9B, Fara1.5-27B, built on Qwen3.5, trained with synthetic data from the FaraGen1.5 pipeline.
- 27B leads the leaderboard: 89.3% WebVoyager, 72.3% Online-Mind2Web, 72.9% WebTailBench process success (40.2% outcome success).
- Best for most people: the 9B model covers two-thirds of the 4B→27B accuracy gain at a fraction of the cost.
- Run it sandboxed: Microsoft strongly recommends the MagenticLite harness (Docker container, domain allow-list, watch mode, pause). Do not give it unrestricted browser access on a machine with anything sensitive.
- Volatile facts: model versions, benchmark scores, and deployment options change often — re-check before committing. Last checked 2026-08-03.
What is Microsoft Fara 1.5?
Fara 1.5 is a family of three computer use agent (CUA) models — Fara1.5-4B, Fara1.5-9B, and Fara1.5-27B — released by Microsoft Research AI Frontiers on July 22, 2026. They are built on the Qwen3.5 base model (4B, 9B, and 27B variants respectively) and fine-tuned with synthetic data from Microsoft's FaraGen1.5 pipeline — a multi-agent system that generates web tasks, solves them, and verifies the results before using the trajectories for training. All three models are released under the MIT license and their weights are on Hugging Face; they can also be hosted through Microsoft Foundry without touching GPU hardware.
What makes Fara different from a normal chat model is that it does not read the HTML or accessibility tree of a page. It is vision-only at perception time: it takes a screenshot of the browser, reasons about what it sees, and predicts the next action — a mouse click at specific pixel coordinates, text to type, a scroll, or a URL to visit. Microsoft calls this the observe-think-act loop. The 27B model holds a 262,144-token context window so it can carry long multi-step runs, but it only keeps the three most recent screenshots in context; the rest of the trajectory stays as plain text.
This pure-vision approach matters because pages built with custom widgets or non-standard layouts confuse DOM-based agents (the accessibility tree is missing or misleading), whereas a model that sees the page like a human simply clicks where you would. For a broader look at why chat-language models fall short for this kind of real-world action work, see our deep dive on large action models vs LLMs.
How does Fara 1.5 compare to OpenAI Operator and Gemini 2.5 Computer Use?
Fara 1.5-27B beats every closed, larger frontier browser agent on the two most established live-web benchmarks. Here are the numbers from the official Microsoft Research article and the arXiv paper (2606.20785), averaged over three independent evaluation runs:
Online-Mind2Web (300 tasks, 136 popular websites)
| Model | Size (params) | Org | Success rate |
|---|---|---|---|
| Fara1.5-27B | 27B | Microsoft | 72.3% |
| Fara1.5-9B | 9B | Microsoft | 63.4% |
| Fara1.5-4B | 4B | Microsoft | 57.3% |
| Yutori Navigator (n1)† | — | Yutori | 64.7% |
| OpenAI Operator† | — | OpenAI | 58.3% |
| Gemini 2.5 Computer Use† | — | 57.3% | |
| GUI-Owl-1.5-8B | 8B | Alibaba | 48.6% |
| Fara-7B (prev gen) | 7B | Microsoft | 34.1% |
WebVoyager (live-web task completion)
| Model | Success rate |
|---|---|
| Fara1.5-27B | 89.3% |
| Fara1.5-9B | 86.6% |
| Fara1.5-4B | 80.8% |
| OpenAI Operator† | 87.0% |
| Gemini 2.5 Computer Use† | not reported |
WebTailBench v1.5 (long-tail tasks — correct intermediate steps / correct final state)
| Model | Process success | Outcome success |
|---|---|---|
| Fara1.5-27B | 72.9% | 40.2% |
| Fara1.5-9B | 64.5% | 32.3% |
| Fara1.5-4B | 60.3% | 27.4% |
| GPT-5 SoM (baseline) | 69.2% | 45.1% |
| o3 SoM (baseline) | 69.5% | 35.0% |
| Fara-7B (prev gen) | 48.8% | 24.1% |
The † marks numbers Microsoft sourced from each vendor's own official release rather than re-running them. The honest takeaway: on "easy" visual single-site tasks (WebVoyager), the gaps are small — every system lands between 80–90%. On Online-Mind2Web (harder, more varied sites), the 27B model opens a clear lead. On WebTailBench (messy real-world cross-site work like form-filling and comparison shopping), even the best vision-only model still fails to reach a correct final state ~60% of the time — a point we expand on below.
For readers weighing this against another emerging strategy — favouring lower-priced, open-weight frontier models that put cost pressure on the closed labs — our guide on how China's open-weight models are forcing Anthropic and OpenAI to compete on price covers the macroeconomic side. Fara is a concrete illustration of exactly that trend in the browser-agent niche.
Which Fara 1.5 model size should you run?
Pick the 9B unless you have a hard accuracy ceiling or a hard latency ceiling.
- Fara1.5-4B — Start here to learn. It is the smallest and fastest, fits on a single ~24 GB GPU (it runs in bf16), and already scores 57.3% on Online-Mind2Web — above OpenAI Operator (58.3%). Use it for prototyping, quick iteration, and lightweight single-site tasks.
- Fara1.5-9B — The default for production. It scores 63.4% on Online-Mind2Web and 86.6% on WebVoyager — both new state-of-the-art for the 8–9B class. Microsoft's own scaling analysis shows the 9B already captures roughly two-thirds of the 4B→27B accuracy gain, so the marginal cost-per-point of going up to 27B is steep.
- Fara1.5-27B — Choose it only when raw accuracy outweighs deployment cost. It needs proper GPUs; the model card recommends sharding across at least two (A6000, A100, H100, and B200 have all been tested). The training compute alone was 64 × NVIDIA B200 over six days. On benchmarks (
72.3 ± 3.8on Mind2Web,40.2 ± 3.0on WebTailBench outcome), the confidence intervals are small relative to the gaps between sizes — the scaling trend here is not run-to-run noise.
Holding the training data fixed, going from 4B to 27B buys you +15.0 points on Online-Mind2Web (57.3 → 72.3) and +8.5 on WebVoyager (80.8 → 89.3). The 9B's training run was 32 × B200; the 27B's was a separate 64 × B200 run. So the jump from 9B to 27B is real but expensive — decide whether that last +8.9 points on Mind2Web is worth a 2× training and roughly 3× inference compute stack.
How do you deploy Fara 1.5 locally?
All three models share the same tooling. The two production paths are self-hosting via vLLM, or hosting on Microsoft Foundry.
Option A — Self-host Fara1.5-27B with vLLM (recommended for full control)
The GitHub repo ships a fara-cli client and a Fara-Agent reference class that drives a real Playwright browser session against any OpenAI-compatible endpoint.
Clone and install.
git clone https://github.com/microsoft/fara.git cd fara python3 -m venv .venv && source .venv/bin/activate pip install -e . playwright installServe the model with vLLM. The 27B in bf16 needs ~54 GB VRAM; shard across two GPUs with
--tensor-parallel-size 2.vllm serve microsoft/Fara1.5-27B \ --dtype bfloat16 \ --max-model-len 262144 \ --limit-mm-per-prompt image=10 \ --tensor-parallel-size 2For the 4B, a single 24 GB GPU is enough; drop
--tensor-parallel-size.Run a task.
fara-cli --task "find the cheapest direct flight from London to Lisbon next Friday and tell me the price" \ --base_url http://localhost:8000/v1 \ --model microsoft/Fara1.5-27BSet
temperatureto0and context length to at least 15000 tokens for reliable results; the repo README spells out the flags.
Option B — Host on Microsoft Foundry (no GPU hardware)
If you don't want to touch hardware, the same weights are hosted on Microsoft Foundry under the same MIT terms — you point fara-cli --base_url at a Foundry endpoint and get the same OpenAI-compatible API. Useful for spikes and demos; the economics and data-residency trade-offs matter once you are putting real credentials in front of the browser.
Small detail people miss — train at 1440 × 900
The models were primarily trained on screenshots rendered at a 1440 × 900 screen size. Matching that on your display makes a measurable difference in click accuracy. If you are constructing the harness yourself and can control resolution, render the page at 1440 × 900 and screenshot at that native resolution rather than a generic 1920 × 1080. Otherwise the model still works, but you are working at the edge of its distribution.
Can you try Fara 1.5 without installing anything?
Yes. There is a free interactive demo on Hugging Face Spaces — hugging-apps/fara-computer-use-27b — powered by ZeroGPU. You give it a start URL, write a goal in natural language, set the maximum number of agent steps (16 is a reasonable starting cap), and hit Run agent loop. The right panel updates with an annotated frame per step; the log underneath shows Fara's reasoning and the exact action it picked. When the loop finishes, the panel plays back the whole run as a slideshow, which is the clearest way to see the observe-think-act loop in motion.
One setting most first-time users leave switched off and then wish they had been warned about: the "allow irreversible actions" toggle. It is off by default — in the demo and in MagenticLite's local config — and you should leave it off until you trust the run. When it is off, the agent will stop and ask the moment it encounters a critical point (see below). The handful of extra approvals is a small price for never accidentally submitting a form, sending a message, or deleting something the model cannot undo.
How does the critical-points safety system work?
Fara 1.5 is specifically trained — not just prompted — to pause and ask at three kinds of what Microsoft calls critical points. Each is in the model card's system prompt verbatim.
- Missing user information. The task requires personal details the user never gave (email, phone, address, payment). Fara fills in what it has and stops to ask; it is explicitly trained not to fabricate the missing fields.
- Underspecified task. "Book me a flight" with no destination. Fara stops and asks instead of guessing.
- Irreversible action without prior approval. Anything that changes external state: submitting a form, sending a message, signing into an account, deleting something. Unless you explicitly authorised irreversible actions upfront, it halts.
This is not optional wrapping bolted on after training. The FaraGen1.5 data pipeline judges whether the synthesised trajectory navigated critical situations correctly — the model was rewarded for asking appropriately, and that behaviour is stable. This is a real design decision against blind UI-native autonomy, and it is the reason the model's WebTailBench process success (72.9 for 27B) is dramatically higher than its outcome success (40.2): when it can't legitimately complete a purchase without PII it was never given, the verifier counts the stop as correct action — the gap from there to a correct final state is the model being honest about what it doesn't know rather than hallucinating your credit card number.
Why must you run Fara 1.5 inside MagenticLite?
The model card is explicit: do not run Fara with unrestricted browser access on a machine with anything sensitive on it. Microsoft's recommended harness is MagenticLite — the browser agent layer of the Magentic-UI stack — which provides four guarantees you cannot easily replicate yourself:
- Sandboxing. The browser runs inside a lightweight VM (the project calls it Quicksand) with no access to your host files or environment variables. The model can't reach outside the container it's driving.
- Domain allow-lists. You decide ahead of time which sites the agent may visit. A misread instruction that sends it somewhere adversarial is stopped before it lands.
- Watch mode. Every step — the screenshot, the reasoning, the action — is logged in real time with full trace history. Auditable after the fact.
- Pause. A single button instantly halts every running agent. No "let me wait for the loop to finish."
You can integrate Fara1.5-27B directly without MagenticLite — the Hugging Face model card and the GitHub repo both support a direct transformers + Playwright path. If you do, all of those guarantees become your responsibility. For most readers and most tasks, sandboxing is not optional hygiene, it is the only path where the model's autonomy is appropriately bounded.
If you already have your own AI agent OS with file-system and browser access, Fara slots in cleanly inside the agent framework's sandbox layer — use MagenticLite as the browser layer and your existing orchestrator as the parent that delegates browser work to it, the same way Microsoft's MagenticBrain orchestrator does.
What does a real Fara 1.5 workflow look like?
Here is a concrete walkthrough of the kind of workflow that plays to Fara's strengths — multi-step, single-site, with an irreversible-action checkpoint — based on patterns Microsoft describes for its synthetic FaraEnvs. Imagine you want Fara to manage failed jobs in an experiment portal: it should find any failed jobs in a specific workspace, resubmit them, and report the final log status for anything that completed.
- You give it a start URL and a goal. "Visit the experiment portal → workspace
prod-stage→ find any failed jobs in the last 24 hours → resubmit them → tell me the final log status for anything that has already completed." You set the agent step cap at 20. - Fara opens the portal and takes a screenshot. It reads the page visually (no DOM) and finds the workspace selector. It clicks it, picks
prod-stage, and waits for the jobs table to render. - It looks for failures. If the table has a status column or filter control, it clicks the filter and scrolls through results. When it spots a failed job, it opens it and looks for a Resubmit control.
- Critical point triggers. Resubmitting changes external state. Because you did not pre-authorise irreversible actions, Fara stops here and asks: "This will resubmit job
XYZ. Proceed?" You confirm. - It tracks what it did. Before leaving that job, it stores the job name in its short-term text memory — so 10 steps later it still knows which job it just resubmitted rather than getting confused.
- It repeats for the next failure, then moves on to the completed jobs: opens each, finds the log view, reads the final status from the screen, stores it.
- When there's nothing left, it terminates and hands you a summary: which jobs it resubmitted (and you confirmed), which completed jobs it reports the logs for, and the exact text it saw on screen.
Things to notice in that loop that distinguish a vision-only agent from the script-based RPA it's competing to replace. The same workflow in classical RPA would break if the portal renamed its "Resubmit" button to "Retry" or moved it to a different tab. Fara looks at the page and picks what it sees, so it survives the kind of small UI churn that sinks brittle selectors. The cost of that resilience is the uncertainty: if a malicious page renders text instructing the agent to click something else, the same perception channel is how an adversarial page can try to redirect it. That's exactly why the sandbox and the irreversible-action toggle matter.
For people running small businesses who assess dozens of these automations per week, this trade-off is the same one our guide to building a no-code AI agent army for a one-person business covers: every agent you reach for has a per-task autonomy profile and a failure mode; the goal is to pick the scope where the failure mode is recoverable.
What are the honest limits of Fara 1.5?
Microsoft itself is candid about the failure surfaces, all documented in the model card's "Out of scope" and "Known limitations" sections. There are six worth knowing before you commit.
- English-only. The training data is English-only; Microsoft explicitly lists non-English use as out of scope. Quality of service is also uneven across English dialects.
- High-stakes domains are out. Legal, health, and financial advice — anywhere an inaccurate action causes harm — are explicitly out of scope. Allocation decisions that affect legal status, housing, employment, or credit are too.
- Long multi-step cross-site tasks are still hard. On WebTailBench v1.5 the 27B's outcome success is 40.2% with a 95% CI of ±3.0. In other words the model gets the final state right on maybe 37–43% of these messy real-world flows. Process success (it took the right steps, then honestly stopped at a critical point) is much higher at 72.9%. The gap between those two numbers is the model's honesty about its limits, not its skill on isolated steps.
- It can misread a page. A wrong click early in a long run snowballs. The paper's step-length analysis shows failures cluster at the longest trajectories and near the 100-step cap.
- Adversarial pages are a real risk. Because Fara reads whatever the page renders, hostile text on a visited page can try to redirect the agent. The mitigation is the MagenticLite domain allow-list, not the model itself.
- It can hallucinate, misattribute sources, or be misled by deceptive content. The model card says so plainly: verify before acting on its outputs.
These limits barely differentiate Fara from other vision-only CUAs — Operator and Gemini share the same failure shape. What does differentiate Fara is that the failure modes are documented in the model card with specific guardrails, instead of being a black box you reason about after a bad run.
What this means for you
If you are a developer or small-business operator who already runs an autonomous agent OS, the right framing is: Fara 1.5 is a drop-in browser perception layer for your existing stack, not a replacement for it. Use your orchestrator (Claude, MagenticBrain, OpenCode, whatever) to decide what to delegate to the browser, and put Fara inside a MagenticLite sandbox to actually drive the clicks. Review our guide to building an AI agent team with Hermes and OpenCode for the orchestration side.
If you are evaluating browser-automation tooling, the decision is between closed or open-weight. Closed agents (Operator, Gemini Computer Use) are easier to start with — no infrastructure, just an API call. Open-weight Fara gives you data residency (model weights on your GPUs and credentials in your container, never sent to a third party) and licence freedom (MIT, no per-call pricing). If you already own the GPU or want to run long credentialed sessions without paying per action, Fara is the cheaper long-run choice. If neither of those matter and you want to move fastest, the closed agents are still legitimately good.
If you are a researcher, the FaraGen1.5 synthetic-data pipeline paper is the more reusable artefact than the model weights themselves. The pipeline — environments that synthesise web tasks, a strong solver (GPT-5.4) that generates trajectories to solve them, and a verifier that filters them before SFT — is the recipe that produced the 9B's near-doubling over Fara-7B, and it generalises beyond the Fara model family.
FAQ
Q: Is Fara 1.5 free to use commercially? A: Yes, under the MIT licence. You can host it, fine-tune it, and ship it in commercial products without per-call fees. The only cost is the GPU to run it (or the Microsoft Foundry endpoint if you go that route).
Q: Can Fara 1.5 read the DOM or accessibility tree of a page? A: No. Fara is vision-only at perception: it sees screenshots, not the HTML or accessibility tree. That is why it survives custom UI widgets and broken DOM structure that confuse structure-based agents. Its action space covers mouse clicks (with predicted pixel coordinates), typing, scrolling, web search, URL visit, and context-management operations.
Q: What hardware do I need to run the 27B locally?
A: The 27B in bfloat16 needs roughly 54 GB of VRAM. The model card recommends sharding it across at least two GPUs — A6000, A100, H100, and B200 have all been tested — and running with vllm serve microsoft/Fara1.5-27B --tensor-parallel-size 2. The 4B fits on a single 24 GB GPU.
Q: How does Fara 1.5 decide when to stop and ask me? A: It is trained — not just prompted — to pause at three critical-point types: missing personal information, underspecified tasks, and irreversible actions without prior approval. The "allow irreversible actions" toggle in MagenticLite and in the Hugging Face demo is off by default; leave it off until you trust the run.
Q: Is Fara 1.5 better than OpenAI Operator? A: On the two most-cited live-web benchmarks the 27B model does score higher than Operator — 72.3 vs 58.3 on Online-Mind2Web and 89.3 vs 87.0 on WebVoyager (source). But "better" depends on what you value: Operator is a hosted API with no setup, Fara is open-weight and you run it yourself. They are not interchangeable deployment experiences.
Q: Does Fara 1.5 work with languages other than English? A: No. Microsoft explicitly lists non-English use as out of scope. The training corpus is English-only; quality degrades heavily on other languages and is also uneven across English dialects. If you need multilingual browser automation, this is the wrong tool for now.
Q: Was Fara 1.5 trained on 1440 × 900 screenshots only? A: The models were "mostly trained" at 1440 × 900 (Hugging Face model card). Matching that resolution makes a measurable difference in click accuracy; Fara still works at other resolutions but you are operating at the edge of its training distribution.
Discussion
0 comments