Read timestamps, not landing pages
I have a habit: on every release day of the big headless browsers, I read their issue trackers. Not to gawk — because a project's self-filed engineering tickets are the most honest browser-spec checklist anywhere. Star counts measure attention. Landing pages measure copywriting. The date a corner of the spec actually got closed is the only thing that measures engineering.
Today a 35k-star Zig headless browser shipped 0.4.1. Reading the release notes against our own git log, a pattern showed up: several things they filed tickets for — or shipped — this week, we had already shipped days earlier. No adjectives below. Timestamps, and links. Verify everything.
The receipts
| Capability | Them | Us | Delta |
|---|---|---|---|
Click dispatches the full pointer/mouse event sequence, not one bare click |
Shipped in 0.4.1, Sep 15 | ab2baa7, Sep 6 | 9 days |
| A redirect rewrites POST→GET: the body and its headers must go (fetch redirect semantics) | #3526, filed Sep 15 — open | 3d5f0bc + 48fa1ec, Sep 11 | 4 days, open vs shipped |
Which box actually scrolls when <body> has overflow — css-overflow-3 §3.3 propagation to viewport |
#3523, filed Sep 15 — open | 4f26dec, Sep 14 | 1 day, open vs shipped |
| CSS custom properties | "Basic support" in 0.4.1, Sep 15 | 208518a, Sep 4 — var() substitution + CSSOM readback |
11 days |
Fetch Referrer Policy — document header, <meta>, per-request override |
#3485, filed Sep 10 — open | cb0c34e + 42deef0, Sep 14–15 | They filed first; we shipped |
| Storage state on context creation | #1550, open since Feb 14 | v0.2.7, Sep 4 — session export/import incl. localStorage | 7 months open |
Note the fifth row: on Referrer Policy they filed the ticket four days before we shipped ours. We include it anyway, because the point of a scoreboard is that it survives scrutiny. The scoreboard was never "who files first" — it's who ships. Five of six corners are shipped here and open (or just-shipped) there.
Why these collisions happen
Two teams grinding through the same specs hit the same corners in the same order — fetch redirect semantics, overflow propagation, pointer events. That's exactly why timestamps are a fair benchmark here: nobody is copying anybody; the spec is public, and the date you closed the corner is public.
And credit where due, with scope kept precise: their 0.4.1 shipped an experimental full CORS implementation (--experimental-features cors). Ours covers CORS preflight enforcement. On breadth, they lead there. Races like this one are good for everyone building agents on top.
The things that aren't races
Three lines where the projects aren't competing on the same axis at all:
- Pixels. They deliberately render zero pixels ("no rendering overhead" —
--dump pngis a text dump). We ship real screenshots, PDFs, and video from the Rust layout/paint stack we maintain: a full page costs 532 ms and 227 MB in our pipeline where Chrome needs 4053 ms and 2.1 GB. - Fingerprint. Their network stack is libcurl, and it fingerprints as libcurl. Ours impersonates Chrome 145 at the TLS layer — because half the production web answers "wrong JA3" with a wall.
- License. AGPL-3.0 vs Apache-2.0. If your legal team has opinions, this one is decided before the demo.
Steal this
This post is a method, not a dunk. If you're evaluating an agent browser, don't read landing pages — pick the five corners of the web platform your agents actually touch, and go read the dates. Ours are all public; every link above resolves.
This page is a snapshot. The living scoreboard — same method, expanded to the whole agent-browser field (browser-use and Kitesurf included), re-audited every release cycle — lives in the repo: docs/RECEIPTS.md.
And it's Apache-2.0. If you're building your own and any of the commits above would save you a week — take it.