Author here. I built this because I got tired of my coding agent claiming a page was "pixel-perfect" when it had never rendered it.

hwatu is a warm WebKitGTK daemon plus a thin client, split the way emacs/emacsclient are. The daemon owns the engine, a compiled adblock ruleset, and a prewarmed WebView that has already loaded about:blank, so its web process and GPU compositor path are hot before any request arrives. Opening a window is: take the warm view, put it in a GtkWindow, start the navigation, warm the next view during idle time. Median 13 ms for a focused window, 14 ms headless, measured over 20 runs (scripts/bench-spawn.sh).

The part I actually care about is verification, not automation. The agent-facing primitives are things like:

- `hwatu check <url> --eval <js> --shot`: open headless, wait for load, eval, screenshot, close, one command, one JSON reply, ~35-39 ms median warm. Same pass through a kept-warm Playwright server with a fresh client per check (the shape every shell-driven agent has) is 341 ms, mostly Node startup and WebSocket connect.

- `hwatu diff --id 2 --other 1`: pixel match percent + diff regions + heatmap between two live windows. A score an agent can climb, not a golden-file pass/fail. We ran an agent against a clone of stripe.com and watched it go 85.1% -> 98.8% match.

- `hwatu motion`: animations as numbers (duration, easing, velocity), and `seek`/`clock` to pin all animations at time t so two screenshots are byte-identical.

- `hwatu focus <id>`: headless is a window property, not a launch mode. When the agent hits a CAPTCHA or a judgment call, focus materializes the same live session (cookies, scroll, half-filled form) in your tiling WM. You act, it takes back over.

Honest caveats, since HN will find them anyway: Linux-only (Wayland best), renders WebKit not Chromium so you still want a Playwright matrix in CI for engine bugs, Playwright wins cold start (190 vs 435 ms, paid once per boot) and memory, and the click/type events are synthetic JS events today (isTrusted false, cross-origin iframes unreachable); trusted GTK-level input is on the roadmap.

It speaks MCP (`hwatu mcp`, stdio, no SDK, translates tool calls onto the same Unix-socket protocol), plain CLI, or one newline-delimited JSON line over the socket. One static binary (~624 KB client, 1.1 MB daemon) plus your distro's webkitgtk-6.0; no Node, no 170 MB browser download.

All benchmark methodology and every caveat: https://github.com/hongnoul/hwatu/blob/main/docs/benchmarks....

Happy to answer anything about the WebKitGTK internals, the prewarm pool, or where the milliseconds go.

1.	Show HN: A verification browser for AI agents – 13ms windows, one-call checks(github.com) 10 points by hongnoul_ 3 hours ago \| 1 comment
2.	Show HN: Hwatu – verification browser for coding agents (WebKit, one binary)(github.com) 2 points by hongnoul_ 4 days ago \| 0 comments
3.	Hwatu: A daemon-based WebKit browser with 13ms window spawns(github.com) 3 points by hongnoul_ 7 days ago \| 0 comments

user:	hongnoul_
created:	July 22, 2026
karma:	7