that makes sense. the error flagging is a nice touch — silent failures are usually the worst part of these tools. i've also run into the “random class name” problem on a lot of modern frontends. have you experimented with more semantic selectors (text anchors, attributes, etc) as a fallback, or do you try to keep it simple on purpose?

Yeah, semantic anchors are definitely the right direction — [data-testid], aria-label, or text proximity tend to survive rebuilds much better than class paths. The picker leans towards CSS right now but that's something I want to improve.

The harder problem is auth-gated content — Instagram feeds, dashboards, paywalled pages. Browser Steps handles it today (you can script login flows), but honestly I think the real fix is AI-assisted interaction. A small cheap model that can find what you care about without needing a brittle selector at all. That's where I want to take this — less "maintain a CSS path", more "here's what I'm interested in, figure it out...

that direction makes a lot of sense. selectors always end up turning into maintenance work sooner or later.

the idea of a small model just identifying “the thing that looks like a price / status / headline” feels much closer to semantic detection than DOM-path tracking

curious though — would you run that model on every check, or only when the selector fails? seems like a nice hybrid approach to keep things cheap.

Yes! Exactly this direction — the hybrid fetch is already live: plain HTTP first, Chromium if the content looks off. LLM semantic targeting is the next step, but only triggered when a selector breaks, not on every check — too expensive otherwise.