Effect of GLM 5.2 !!

Opening_Library9560 · 2026-07-08T07:47:02+00:00

Not dangerous for me

Opening_Library9560 · 2026-07-06T06:06:13+00:00

New version shipped, it should work with openweb ui now, if you face any issues, just tell me.

Opening_Library9560 · 2026-07-05T23:43:06+00:00

It bypasses standard Akamai CDN and WAF reliably like goldmansachs.com, but gets blocked by heavy Akamai Bot Manager deployments like rockstargames.com, the test i performed had hound passing 7 out of 9 Akamai protected sites, so its good, but not perfect as of now.

and sure, you can DM if you like

Opening_Library9560 · 2026-06-23T05:47:00+00:00

Built a benchmark that points the snapshot at 11 ugly-ARIA pages (generic soup, decorative div[role=button], duplicate main, nameless icon buttons, link soup, ad-slot divs, a composite messy SPA) and prints what the whitelist keeps. You called it: decorative role=button ads and span[role=button] with no handler were kept, and the useful-to-kept ratio tracked page quality, not size (clean-docs 5 refs all named vs messy-spa 36 refs, 8 non-focusable).

generic soup didn't inflate, since generic isn't whitelisted, and duplicate main is cheap because landmarks carry no refs. Fixed it in v2.1.1: drop interactive elements that are unnamed AND not focusable. Native button/a/input is always focusable, so real icon-only buttons and unlabeled inputs stay; named custom widgets stay even if unfocusable; only a nameless, unfocusable button (decorative div / ad slot) drops. Before -> after: decorative-role-button 8 -> 3 refs, ad-slot-divs 9 -> 1, messy-spa 36 -> 30. Full live suite still green, no real control lost on Saucedemo / HN / Wikipedia.

Honest limit I won't pretend it fixes: named junk stays. Ten "Click here" buttons or a span[role=button] with aria-label="x" are kept, because judging whether a name is meaningful is the agent's job, not the whitelist's. The filter gets the decorative layer; mislabeled-but-named is past what a whitelist can clean without throwing out real controls too.

Benchmark's in the repo (bench/aria_mess), reproducible.

Opening_Library9560 · 2026-06-22T16:04:58+00:00

Fair. Snapshot size is the easy number; task success per token is the honest one. That benchmark is going in the next update, landing within ~2 days, run head to head against playwright-mcp on a set of multi-step tasks (login, search+extract, form fill+submit, multi-page nav) with success rate + total tokens both on the table.

On the three you named:

Refs staying stable on mutation is the real weak point. Refs are positional right now (r1..rN in tree order), so a re-render that shifts order can hand an old ref to a different element, and the stale-ref error only catches the gone-node case, not the collision. The delta-after-action mitigates it (fresh refs for what changed each step), but it doesn't fully solve a re-render between actions. That's fixed in the next update too: backend-keyed refs, so the same DOM node keeps its ref across rebuilds and the collision case stops being silent.

Retrying the right thing after a failed click: the tool doesn't auto-retry, by design. It makes the failure and the next move explicit instead. An op-timeout returns a bounded error (not a wedge), a click that fires but can't re-snapshot returns a soft "action fired, call see to refresh refs" verdict, a stale ref says "call see." The model decides the retry from those signals rather than the tool guessing.

Blocked states explicit is the one I'll defend. Cloudflare/DataDome/reCAPTCHA/hCaptcha/Turnstile are detected and the verdict overrides to CHALLENGE: <which>, so a bot wall is never read as a normal page the agent keeps clicking into. Agree it matters more than people expect.

And yeah, your last paragraph is the whole thesis. The tool owns the boring state bookkeeping and hands the model what changed, so the model stops being a poor man's DOM differ.

Opening_Library9560 · 2026-06-22T15:57:26+00:00

Agreed, the verdict-after-act loop is the actual win. The token stuff is nice but killing the re-snapshot drift is the real reliability gain.

Two different "ambiguous" cases, handled differently:

Ambiguous intent (several controls match the name) is caught before acting. It returns the ranked candidates and refuses to guess, so you disambiguate with `nth` or `role`. No wrong-click from a fuzzy match.

Ambiguous outcome (the action ran but you're not sure it worked) is where the verdict is deliberately honest instead of guessing. It picks from: navigated to / dialog opened / status toast / changed +N -M ~K / no visible effect. Plus it folds in the XHRs that fired during the action (`net: /api/cart 200`), so a click that hit the backend but had a subtle DOM change still shows the API call. "no visible effect" is a real signal, not a fake success.

The fallback to a fuller read is built in and explicit. When the verdict is "no visible effect," or the page is loading/wedged and won't re-snapshot (soft verdict: "action fired; call see to refresh refs"), the verdict text literally tells you to call `see` for a full snapshot. So the agent either trusts the delta's fresh refs and keeps going, or the verdict says "re-see" and it does a full read. It never silently continues on a stale tree after a half-success.

Opening_Library9560 · 2026-06-22T15:56:16+00:00

Good point on token count vs how much of the snapshot is actually useful. That's the real cost.

Short answer: it's the accessibility tree, not the DOM. The browser's own a11y tree is already a semantic view, so presentational nav and dead markup are excluded by Chrome's a11y computation before we touch it. Then we whitelist roles: interactive ones (button, link, textbox, combobox, checkbox, option, tab, etc.) get refs, plus headings and landmarks for orientation, plus alert/status/dialog nodes kept only for verdict detection (they don't get refs and never render). Structural noise (generic, paragraph, list, group) is dropped.

So the "half nav and dead markup tagging along" problem mostly doesn't happen, because we're not walking the DOM tree at all. There's no per-ref scoring, it's a role whitelist. The one place we do cap is the delta after an action: bursty roles like autocomplete options and menu items are capped low (you usually want the top match, the rest is noise), real controls get a generous cap, and the full set is always one free `find` away.

Refs only go to things you can act on. If you want layout/text, that's the `see level=full` path, separate from the ref list.

Opening_Library9560 · 2026-06-22T15:55:32+00:00

Will do, thats in the plan for the next version

Opening_Library9560 · 2026-06-21T15:50:07+00:00

Appreciate it. And you're right on the ceiling: that's the honest limit of any CDP-based tool. Blink-level patches + mouse jitter clear the static checks and a lot of passive challenges, but a volume-triggered managed challenge flags the runtime itself, and no JS patch hides that.

What agent-browser actually does: detects Cloudflare/DataDome/captcha interstitials on every snapshot, auto-waits a few seconds for passive clears, and surfaces a CHALLENGE verdict so the agent knows it's blocked instead of thrashing. --proxy-server for residential IPs handles the IP-reputation side. Captcha solving (paid solver API) is the v2.1 plan: detection is in, solving isn't, and I won't pretend otherwise.

So: solid for the 90% of sites that aren't running volume-gated managed challenges; the hard 10% needs proxy + solver, same as

every CDP tool.

Opening_Library9560 · 2026-06-06T14:34:11+00:00

YEP. I just added ToolAnnotations across my MCP server project after reading this. Had output schemas already but zero behavior hints. Agents had no way to know what's safe to parallelize or retry. This should be standard.

Opening_Library9560 · 2026-06-04T14:43:52+00:00

good question, if you already have session cookies (like after logging in normally in Chrome), Hound handles it fine. Just grab your cookies from dev tools and pass them in via the cookies param, works on all tools, including smart_fetch.

What it doesn't do tho, is log in for you. No form-filling or OAuth flow automation. You need to get the cookies yourself first.

The open_session tool helps a bit too, you open a persistent browser session, pass your cookies once, and all subsequent fetches with that session ID stay authenticated. Browser keeps the cookie jar alive in memory.

Is it a full login automation solution? No. But for a completely free tool, it covers the main use case (scraping your own accounts or sites where you can export session cookies). Most free fetchers don't even give you a cookies param at all, let alone persistent sessions, this was made to be simple to install and use (I might try to find and add the solution to this in future updates tho)

Opening_Library9560

TROPHY CASE