i started the selenium project 21 years ago. vibium is what i'd build if i started over today with ai agents in mind. go binary under the hood (handles browser, bidi, mcp) but devs never see it. just npm install vibium. python/java coming. for claude code: claude mcp add vibium -- npx -y vibium v1 ships today. ama.
Sorry, I kind of have a dumb question here. So we have a bunch of legacy selenium scripts that do end to end user testing, and occasion they break (either because of a network error, or devs committed something that breaks a test).
We were looking at seeing if a model could look at the screenshot of the failure, some of the original website source code, and try to fix the failing test.
My question is with vibium, would it make more sense to port the legacy tests over to vibium, and if a test fail, use its capabilities to try to self-heal?
Does it allow you to inject js, modify the DOM, and most crucially monitor/modify network requests? I do those things in probably 95-99% of the time I reach for playwright mcp in claude, and from the "For Agents" part of the README, it seems like all this can do is click/type/screenshot?
Interesting, I've been using this skill https://github.com/SawyerHood/dev-browser to save on context and get some more speed. Will try this out!
As someone who's made a good living primarily in UI automation for over a decade, thank you.
It's been an interesting journey.I do think Playwright is the defacto standard now, but Selenium was the original browser driver.
Anyway, how does Vibium compare to Playwright ? Playwright's main advantage is it has official support for multiple languages.
If an agent gets a copy of the screen using browser_screenshot and then wants to click somewhere on that screen, how is it meant to find the right css selector to pass to browser_click?
There's a browser_find method, but that assumes you already know what type of element it is. But I can't always tell what type of element something is just by looking at a screenshot.
What have I missed or misunderstood?
I'd love to be able to lock down the browser to only allow certain URLs (e.g. localhost) so I can give Claude (and other tools) carte blanche to use browser automation (rather than manually approving each command). Is this something on your radar / roadmap?
This is very cool. We were thinking about doing something very similar with Skyvern
What was the reason you went down this path instead of extending selenium with AI features?
How does it handle context bloat between the browser and the llm?
Any plans of exposing more of the browser? For instance playwright is able to store tracing files the agent may decide to read to understand some requests / payloads…
Any plans on allowing the agent to run an arbitrary js script?
I wasn’t able to gather the future state plans beyond what’s noted in the V2 plans:
https://github.com/VibiumDev/vibium/blob/main/V2-ROADMAP.md
What’s next 5 years look like given that you are very good at building long-term projects that last and evolve through time? And for a very specific example, what’s the plan for incorporating new standards like Agent Skills as they quickly evolve and launch?
Aside from the project itself, I am learning a lot just from reading the commits. Mostly about the process when one knows how they'd do it.
https://github.com/VibiumDev/vibium/commits/main/?after=ffc3...
My number one question would be how it compares to Playwright -- differences in design goals, capabilities, advantages and disadvantages.
And this handles login sessions, cookies, etc.? So much of the modern web is now hidden behind login sessions.
Nice. I was just thinking of building this very thing. Glad to see I won’t have to. I’ll check it out after the holidays.
entirely possible I’m just really bad at this stuff but I can’t get browser agents to do simple report pulls without running into a captcha or a dropdown menu that breaks its brain. hopefully this is the one!
Neat. Any reason why the MCP server doesn't expose a JavaScript/eval tool? Current models excel at writing JS to drive and inspect the DOM. They aren't great at driving browsers via screenshots.
Is this something you use to generate static browser tests that no longer use the LLM? Or would you need to use the LLM every time you run the tests?
Any plans to support local models through llama.cpp or similar?
Cool. Can this currently be used with codex in the same way?
Since it's in go, wouldn't it be great if it also expose go api?
What is the benefit of using this instead of playwright?
Hi this looks really valuable, thanks for developing and sharing. Would you share some use cases and how you or your users use it personally? would love to see some examples and feel the aha "That's how I'd like to use it too!" and it would help me drive and se the problems I have as being solvable by this too rather than seeing a tool/solution looking for a problem. (not implying you're that, but without examples/use cases that's the default way I think)
Anyone attempting something similar for Qt/QML based apps?
How do you install it into Claude Desktop? I tried the following, but it fails.
"vibium": {
"command": "npx",
"args": [
"-y",
"@vibium/mcp@latest"
]
}[dead]
[flagged]
Hey man, just wanted to say thanks for Selenium - it was a game changer and had a big impact on my professional life.
I’m interested in checking out Vibium - I’ve been a reluctant adopter of Playwright and hopeful for a new approach.