Fara1.5, wrangled — a computer-use agent on our own GPU

microsoft's open computer-use agent · Fara1.5-9B-FP8 · run entirely on our own hardware · 2026-07-28 · MIT license · $0 cloud

Fara is a vision-only browser agent: it looks at a screenshot of the page — no DOM, no accessibility tree — thinks in text, and answers with one concrete action (click these pixels, type this, scroll, visit this URL). Our harness executes that action in a real browser, takes a fresh screenshot, and loops until the model says terminate with a final answer. The model runs on one GPU in our rack; the browser can run anywhere — including attached to your own logged-in session.

53s
HN task, end-to-end ✓
~3s/step
warm action latency
16.8GB
pinned VRAM slice
$0
cloud / quota spend
9B FP8
86.6 webvoyager tier
80s
cold start → first answer
01 Where each piece runs

The model server and the browser are decoupled — an OpenAI-compatible HTTP seam connects them. Screenshots go up, actions come back.

flowchart TD
  subgraph ORCH["THE ORCHESTRATOR — any box"]
    CLI["fara-cli harness
microsoft/fara + our patches"] PW["Playwright controller
executes actions, takes screenshots"] end subgraph BROWSERS["THE BROWSER — pick one"] SB["Sandbox chromium
fresh profile, no auth"] CDP["Your own logged-in browser
CDP attach :9222"] end subgraph GPU["THE GPU BOX — one card"] VLLM["vLLM server
Fara1.5-9B-FP8 · ~17GB slice"] end CLI --> PW PW -->|"drives"| SB PW -.->|"--cdp_url"| CDP CLI -->|"screenshot + history"| VLLM VLLM -->|"next action"| CLI classDef gold stroke:#d4a73a,stroke-width:2px class CDP,VLLM gold
02 The observe → think → act loop
sequenceDiagram
  participant U as You
  participant H as Harness
  participant B as Browser
  participant F as Fara 9B (GPU)
  U->>H: task — "find X on this site"
  H->>B: screenshot (1440x900 PNG)
  B-->>H: pixels
  H->>F: goal + last 3 screenshots + action history
  Note over F: thinks in text, then emits ONE action
  F-->>H: chain-of-thought + tool_call
  H->>B: playwright executes click / type / scroll
  Note over H,B: loop repeats ~3s per step until done
  F-->>H: terminate (final answer)
  H-->>U: answer + full trajectory + screenshots
  Note over F: critical point? sign-in, payment, submit → PAUSES and asks the human first
    
03 Anatomy of one step
OBSERVE

Screenshot in

The harness captures the viewport at 1440×900 — the resolution Fara was trained on. Only the last 3 screenshots ride along; older ones drop out of context.

THINK + DECIDE

Model output

Reasoning first, then exactly one grounded action:

The top story is the first
row under the site header...
<tool_call>{"name": "computer_use",
 "arguments": {"action": "left_click",
  "x": 342, "y": 187}}</tool_call>
ACT

Playwright executes

The harness parses the XML, clicks those exact pixels in the real browser, waits for the page to settle, and the loop begins again with a fresh screenshot.

04 Two ways to give it a browser
default · safe

Sandbox launch

The harness spawns a fresh headless chromium — empty profile, no cookies, no auth. This is what the smoke test used. Can't touch your accounts even if it wanted to.

one command
fara-cli --task "..." \
  --endpoint_config endpoint_configs/vllm_config.json
our patch · authed sessions

CDP attach — drive your real session

Attach to your already-logged-in browser over the DevTools protocol. No stored credentials, no automation login to get flagged, and you watch every click live.

two commands
# 1 — relaunch your browser with a debug port
brave --remote-debugging-port=9222

# 2 — point Fara at it
fara-cli --task "..." --cdp_url http://localhost:9222 \
  --endpoint_config endpoint_configs/vllm_config.json
Why this matters: a huge share of real admin work lives in consoles and portals with no API. CDP-attach plus a local model means those flows can be automated with zero cloud spend — and no screenshot of an authed console ever leaves your network.
05 The action space
ActionWhat it doesGroup
left_click right_click double_click triple_clickMouse clicks at predicted (x, y) pixel coordinatesmouse
mouse_move left_click_dragCursor positioning and drag operationsmouse
type keyKeyboard input — text entry and key comboskeyboard
scroll hscrollVertical / horizontal page scrollingnavigate
visit_url history_back web_searchDirect navigation and searchnavigate
pause_and_memorize_factPins a fact so it survives even when old screenshots fall out of the windowused in our smoke run to hold the headline it readmemory
ask_user_questionStops and surfaces a question to the humanhuman gate
wait terminateSleep N seconds / end the task with the final answercontrol
06 Guardrails & the honest capability read
Task typeVerdictWhy
Read / navigate / report"list the users", "check this setting", "find the price" good today WebVoyager-tier work — the 9B scores 86.6% here. Our smoke run was this class: flawless.
Multi-step writes on dense admin UIswizards, multi-page config changes watch it Harder-benchmark tier (63.4% Online-Mind2Web). Misclicks compound. Run headful, human watching. Fara's critical-points training makes it pause before sign-ins, payments, and submits — but a watcher still catches the fumbles.
Anything with an APIofficial SDKs, CLIs, admin APIs… use the API Deterministic beats vision-clicking. Fara's lane is the long tail of UIs with no API.
High-stakes records (legal / medical) not this The model card marks legal/high-stakes domains out of scope — and that matches our own hard rules for records that matter.
Standing caution — prompt injection. Fara reads page content through its eyes. A malicious page can embed instructions aimed at the agent. On an authed session that's a real surface: keep CDP-attach runs to allow-listed destinations (admin.google, known consoles), the same defense-in-depth posture we apply to everything an agent reads.