FAI Browser
Give your coding agent one browser tab you approve, with compact page summaries,
action approvals and verified outcomes.
Website · Install · Measured comparisons
FAI Browser lets a coding agent work in one Chrome or Firefox tab you approved, in your own signed-in browser.
Your agent drives: fai_browser_open asks for your approval and returns a compact
page digest with the actions your granted level allows; your agent picks one with fai_browser_act
and gets the next page back, until an expectation verifies the outcome. No key, no provider calls,
and every action passes the same guardrails: levels, origins, forbidden labels, and explicit
approval for payments. Login is restricted to your configured test environments.
Why
- Your agent drives. Each result contains a compact page digest and allowed actions. The agent
chooses the next action and checks the outcome against an expectation.
- Less page text per turn. On twelve captured public pages replayed locally, opening results
used a median 1,147 tokens versus 11,787 for full accessibility snapshots (rounded, o200k_base).
This measures output size, not task success; see the method and results.
- You stay in control. The agent gets one task tab by default, only after you approve its request: the page opens in
a new tab in the existing browser window by itself. Click Approve in its request modal, allowing browser site
access when asked, or click the FAI Browser toolbar icon on that tab (a request for
full or
testing shows the FAI Browser window first, where you pick the level and Open the page).
You can pause or stop at any time. Screenshots on either browser may still need the toolbar click;
modal approval requests host access, which does not itself grant screenshot access.
- Results are receipts, not guesses.
completed means an independent expectation passed. Each
result carries a trusted verdict and next {kind, text}: answer, choose, observe, relay to the
user, approve or stop.
- Invite an agent to a tab you are on. The toolbar popup's Invite an agent to this tab hands the current
tab to a live Claude Code, Codex or OpenCode session at the level you pick. Approve and Resume wake that session,
so it continues without you typing "done" (other hosts get a copy-paste line).
- Several browsers, one service. The Firefox add-on and Chromium-family builds can be paired at the same time;
each browser holds its own task tab, and a request opens in the browser you used last (or the one the agent names).
- Frames you approved are readable. A cross-origin frame inside the page (an admin portal's content blade, say) is
read and acted on when its own origin is one you approved; other frames are never read and are boxed in screenshots.
- Everything is local. The FAI service, extension and traces stay on your machine, outside the
checkout; FAI makes no model or provider calls.
Demo
Watch the demo · Download MP4 · 30-second cut
Real Firefox development-build UI on local test sites, with scripted clicks and edited presentation.
The demo shows payment approval, verified confirmation, secret redaction, and approved secret reuse.
Capture provenance.
Benchmarks
Two measurements answer different questions: how much page text reaches the agent, and how
Agent direct (your agent driving) completes a workflow compared with Playwright MCP. All figures are local fixture runs with their limits stated next
to the numbers.
Page output size
Twelve captured public pages, replayed locally with 0.3.1. Median opening output with o200k_base:
| FAI Agent direct | Full accessibility snapshot |
|---|
| Observed text tokens | 1,147 | 11,787 |
90.3% fewer tokens in the ratio of corpus medians (snapshot median rounded from 11,786.5).
This compares full Playwright-style accessibility snapshots with FAI opening results. It measures
output size, not task success or billed model usage. Current Playwright MCP may return snapshot-file
references; the task benchmark below includes the contents actually read.
Method, per-page data and limits.
Model-driven task comparison
Measured 2026-11-06 on local fixtures, two repeats per task. Values are per-task averages of
per-task medians. Wall time is host spawn to exit. Host tokens are full vendor usage; cost is
host-only pricing from bench/prices.json, not a subscription invoice. Lower time, token and cost
are better; higher pass counts are better. Text workflows ran on Sol 6.1 medium, visual workflows on
Claude Sonnet 5.5 medium.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
