Chromeflow vs Browser Use
Two different bets about how AI agents should read a webpage. Chromeflow queries the DOM. Browser Use takes a screenshot and asks a vision model. The trade-off shows up in your token bill.
Capability matrix
| Chromeflow | Browser Use | |
|---|---|---|
| How it reads the page | DOM queries (cheap, deterministic) | Screenshot → vision-model reasoning (expensive, probabilistic) |
| Per-action token cost | ~200–600 chars per call | ~10–30K tokens per step (screenshot + vision) |
| Per-action latency | Chrome render time (~100–300 ms) | +1–3 s for vision-model round trip |
| Determinism / reproducibility | DOM queries are stable | Vision misreads, page re-layouts shift everything |
| Runs in your real Chrome with sessions intact | Yes | No — fresh profile, Playwright under the hood |
| Native MCP plugin for Claude Code & Codex CLI | Yes (28 tools, one-command install) | Standalone agent — runs its own LLM client |
| Brings its own LLM | No — agent's LLM (you choose) | Yes (multi-provider) |
| Human-in-the-loop for 2FA / payment | Yes (highlight + wait_for_click) | No native pause-for-human |
Captures credentials → .env | Yes | No |
| Privileged fetch (bypasses page CSP, uses Chrome cookies) | Yes | No |
| Handles deliberately obfuscated DOMs / heavy anti-bot | Falls back to coordinates + execute_script | Vision reads pixels regardless of DOM |
| License & cost | Free, MIT | Free, MIT |
The DOM-vs-vision trade-off
Browser Use's pitch is real: vision models are getting good enough that "look at the screen and decide what to click" works on more sites every month. The cost is the cost — every step requires a screenshot (often 0.5–2 MB encoded as base64), shipped to a vision model, which returns a few hundred tokens of reasoning, which the agent then translates to a click coordinate. Even a 20-step workflow can cost more in vision-model tokens than your code-generating LLM cost for the whole session.
Chromeflow's pitch is the inverse: the DOM is already a structured representation of the page. find_text("Save") returns the matched element's selector, surrounding context, and click coordinates in 300 chars. get_form_fields() returns a typed inventory of every input on the page in 1–2 KB. The agent doesn't need to "reason about pixels" because the DOM has already done that work.
Where Browser Use genuinely wins
Sites where the DOM is intentionally junked. Some sites (Cloudflare-protected, heavy anti-bot, deliberately-obfuscated CAPTCHAs, canvas-rendered apps like Figma or Notion's whiteboard mode) produce a DOM that's useless to query — class names are random hashes, structure is intentionally meaningless, content lives in <canvas> elements. Vision models can still read these screenshots. Chromeflow can fall back to coordinates plus execute_script, but Browser Use is more ergonomic for pure-pixel reading.
Demos and prototypes where the model is the point. Browser Use is a fantastic showcase for what frontier vision models can do. If you're building a demo to impress someone with "look, the model just reads any website", Browser Use is the right choice.
Where Chromeflow wins
Cost-sensitive production workflows. If a workflow runs daily across a team, the screenshot tax compounds. 50 steps × 30K tokens × 100 runs/month = a substantial monthly bill for vision-model calls that DOM queries handle for ~1/100th the cost. Chromeflow makes long-running agents economically viable.
Tasks behind a login. Browser Use launches Playwright under the hood — fresh profile, no inherited sessions, no 2FA story. Setting up Stripe, grabbing API keys from Supabase, downloading Canvas attachments — none of these work without your existing login. Chromeflow drives your actual Chrome, so the agent inherits everything.
Determinism for CI / scheduled runs. Vision-model reasoning is probabilistic. A page re-layout, a font change, or a new banner can cause the model to misclick. Chromeflow's until_* clauses on click_element verify post-conditions deterministically — the click either landed on the URL/selector/text you expected, or you get success=false and can recover.
Integration with the AI coding agents people actually use. Chromeflow is an MCP plugin for Claude Code and Codex CLI — install once, use everywhere. Browser Use is its own thing with its own LLM client; integrating it into an agentic workflow means shelling out from your main agent or running it as a sidecar.
The actual cost benchmark
A representative "set up Stripe Connect for a new SaaS" workflow involves ~25 interactions: dismiss a cookie banner, open product creation, fill a name and price, click Save, navigate to API keys, reveal the secret, click Copy, paste into .env, configure webhook URL, send a test event, verify the response, and back-and-forth across a few tabs.
- Chromeflow: ~25 tool calls × 400 chars/call = 10 KB total ≈ 2.5K input tokens to the agent. Cost: cents.
- Browser Use: ~25 steps × 20K tokens/step (screenshot + vision reasoning) = 500K tokens. At GPT-4o vision rates that's $1.25 per run; at Claude vision rates higher.
The 50–100× cost ratio holds for any DOM-readable site. For DOM-junked sites (Figma canvas, Cloudflare-rendered, heavy-obfuscation anti-bot pages) Browser Use's cost looks more reasonable because Chromeflow can't read them either.
What about reliability?
Browser Use's vision model can hallucinate click coordinates on dense pages — it confuses "Save" with "Save and continue" or clicks an ad it thought was the primary CTA. Chromeflow's DOM queries return exact selectors with verifiable text match — there's no probabilistic element. v0.9.5 added expect_submit=true on click_element which watches for URL change / toast / modal / aria-live region appearance after the click, returning success=false when the submit silently fails (common on anti-bot social platforms).
The decision rule
Try Chromeflow first. It's cheaper, faster, more deterministic, and works on 90%+ of real-world sites. Reach for Browser Use only when the DOM is genuinely unreadable (canvas-rendered, intentionally obfuscated, heavy anti-bot) — and even then, evaluate whether execute_script with a fallback CDP approach in Chromeflow can do the job.