Browzie 0.1 is open source: MIT licensed, made for Windows 10 and 11.

Read the design

How it works

From a sentence
to a click.

A request leaves Claude Code, crosses a local pipe in about 2 ms and reaches your Chrome as real, trusted input. Here is every hop, and why it is built that way.

  • 2 ms round trip
  • 0 TCP ports
  • 0 dependencies
  • 0 API keys

The chain

Five pieces, one local pipe.

Slowed down a few thousand times so you can follow it. Tap a piece to read about it.

01 / 06

Claude Code

Your claude.ai login is the model. Browzie never calls a model itself, so there is no API key anywhere.

Each Claude Code session starts its own Browzie server over stdio, and gets its own Browzie window.

The control loop

One click, end to end.

Claude asks for click {ref: "e12"}. Eleven things happen before the answer comes back, most of them in a few milliseconds.

  1. 01

    Queue

    All input across all sessions goes through one queue, because there is one mouse and one keyboard focus. Reads like snapshot, find and read never wait for it.

  2. 02

    Gates

    Paused? A dialog open? A bot check on the page? Each one stops the action before any input is sent. Turnstile gets up to 8 s to pass by itself.

  3. 03

    Show, do not focus

    Browzie’s tab becomes the visible one in its own window, but the window never comes to the front. You keep typing wherever you are.

  4. 04

    Attach

    The debugger attaches if it is not already. On a new window Browzie waits for Chrome’s bar to appear before loading any page.

  5. 05

    Pace gate

    A log-normal gap since the last action, about 0.4 s median, which the model’s own thinking time usually covers. Plus reading time on a fresh page and the per-site caps.

  6. 06

    Locate

    The page agent returns a hit-tested aim point near the middle of the target, never in its outer fifth. Out of view? The wheel turns until it is in view.

  7. 07

    Move

    The path is planned, replayed on schedule every 7 to 17 ms, and mirrored by the overlay on your screen.

  8. 08

    Verify

    Is the target still under the pointer? If the page shifted, a short correction re-aims, twice at most, then the result names what is in the way.

  9. 09

    Act

    Press with a pressure of 0.5, hold for 48 to 190 ms, release. Or type, or turn the wheel.

  10. 10

    Settle

    Wait while the navigation and requests it started are in flight and the DOM keeps changing, until 150 ms of quiet. No fixed sleeps.

  11. 11

    Report

    A diff of the snapshot before and after, plus any warnings: a dialog opened, a bot check appeared, a new tab was followed.

Latency budget

The pipe is nearly free.

Browser agents are usually slow in the transport and in the number of model turns: screenshots, re-reads. Browzie makes those nearly free, so what is left is the input itself, and its speed is a setting.

Measured on Windows 11 with npm run bench and test/nav-bench.js. Medians.

  • Every hop, there and back2 ms
  • Snapshot of a form page4 ms
  • Snapshot through 3 iframes12 ms
  • Viewport screenshot58 ms
  • Navigate + snapshot, local page392 ms
  • Navigate + snapshot, vercel.com1.4 s
  • Navigate + snapshot, youtube.com2.7 s

transport and reads real sites loading

Human motion model

Bigger and nearer is faster.

Every move takes as long as Fitts’ law says a hand would, on a curve that speeds up early and slows down over a longer tail. Click anywhere in the field to move the target.

Claude

Click anywhere to place the target

Pixel precision

On the grid, to the pixel.

At 125% scaling a real mouse stands on physical pixels, so every position it reports is a multiple of 0.8. A plain DevTools click lands on whole numbers, off that grid four times in five. Browzie snaps every point onto it, and the overlay draws the arrow tip on exactly that pixel.

// one coordinate pipeline, CSS px to the physical grid
x' = (round((ox + x · Z) · S) / S − ox) / Z
// S = devicePixelRatio / zoom

0.00 px between the drawn tip and where Chrome delivers the pointer, at three positions. npm run lens-check

Why this shape

Four decisions, all measured first.

  1. 01

    An extension, not a relaunched browser.

    A debugging-port browser is visible to sites: bot.sannysoft.com reports WebDriver: present (failed) for it. chrome.debugger gives trusted input without navigator.webdriver and without a port.

  2. 02

    A named pipe, not a localhost port.

    Sites have been seen scanning local ports to fingerprint tools. A pipe is unreachable from a page, and native messaging is Chrome’s own channel at well under a millisecond per message.

  3. 03

    A hub host.

    Chrome starts the host, Claude Code starts the server. The host joins them and lets several Claude Code sessions share one browser, one window each, with input serialised and reads in parallel.

  4. 04

    A separate window for the cursor.

    A cursor drawn in the page is a DOM node any page can find. An OS window over Chrome is invisible to pages and absent from Chrome’s own screenshots. No Electron, nothing downloaded.

Read the full design document

Ready when you are

One browser.
Now, two cursors.

Clone it, run one installer, load the extension once, then ask Claude to open a page. You will see the purple cursor on its way.

Browzie for Claude Code

One installer, one unpacked extension, and Claude can use your Chrome.

Setup guide

Any MCP client stdio

Point any client that speaks stdio at server/server.js and it gets all 19 tools.

See the tools