Vibium Review: AI-Native Browser Automation in 2026

When the person who started Selenium in 2004 and Appium in 2012 announces a new browser automation project, testers pay attention. Vibium is Jason Huggins’ third attempt at the same problem, and this time the primary user is not a human writing test scripts. It is an AI agent that needs to see a page, think about it and act on it.

This Vibium review looks at what the project actually shipped as of mid-January 2026, how it is built, how to install it, and where it fits next to the tools most teams already use. It builds on our earlier pieces on Playwright MCP servers for agentic testing and browser agents versus test automation, so I will try not to repeat the background on MCP itself.

What is Vibium?

Vibium describes itself in its README as “browser automation infrastructure built for AI agents” and, more casually, “browser automation without the drama”. The core is a single binary that handles the browser lifecycle, speaks the WebDriver BiDi protocol, and exposes a Model Context Protocol (MCP) server so that Claude Code or any other MCP client can drive a real browser.

The repository was created on 12 December 2025 under the VibiumDev organisation and is licensed under Apache-2.0. The JavaScript package landed on npm on 22 December 2025, and the Python package on PyPI on 31 December 2025. By the time Software Testing Weekly’s issue #298 went out on 12 January 2026, the headline was simply that “Vibium is officially out”, already with JavaScript and Python support.

The V1 promise: “vibium v1 ships by christmas”

In his V1 announcement on 11 December 2025, Huggins set a public deadline: “vibium v1 ships by christmas”. He also shared the pre-launch interest he had gathered, including more than 1,300 completed surveys, more than 1,000 mailing-list signups and more than 20 user listening sessions. That is unusually transparent product research for an open-source testing tool, and it shows in how narrowly V1 was scoped.

The announcement also mentions a sold-out TestGuild IRL event in Chicago and a Vibium subreddit, which tells you the interest came before the code. The longer-term design he described follows a sense, think, act loop:

• Retina is the sensing layer, planned as a Chrome extension that “records everything happening in the browser”.
• Cortex is the thinking layer, a memory layer that “builds a map of the app and plans navigation”.
• Clicker is the acting layer, the part that actually drives the browser.

Only Clicker and the client libraries shipped in V1. Retina, Cortex, a Java client, video recording and AI-powered locators are on the V2 roadmap. Keep that in mind when you read hype about Vibium being an “AI tester”. In January 2026 it is an agent-friendly browser driver, not an autonomous testing product.

How Vibium works: Clicker, BiDi and MCP

The architecture is easy to explain, which is a compliment. There are three moving parts.

Component	What it does	Interface
Clicker	Launches Chrome, proxies WebDriver BiDi, runs the MCP server, auto-waits, takes screenshots	CLI, stdio, WebSocket on port 9515
JS/TS client	Developer API with sync and async styles	npm install vibium
Python client	Same API shape for Python	pip install vibium

Clicker: one Go binary

Clicker is a single Go binary of about 10 MB with no runtime dependencies. It detects or launches Chrome with BiDi enabled, runs a WebSocket server that routes BiDi commands to the browser, provides an MCP server over stdio for LLM agents, polls for elements before interacting with them, and captures viewport screenshots as PNG.

The stated design goal is that “the binary is invisible”. A JavaScript developer runs npm install vibium, and the right platform binary comes along with it. On install, Vibium also downloads Chrome for Testing and a matching chromedriver. If you manage browsers yourself, for example in a locked-down CI image, the VIBIUM_SKIP_BROWSER_DOWNLOAD=1 environment variable skips that download.

Supported platforms in V1 are Linux x64, macOS on both Intel and Apple Silicon, and Windows x64.

Why WebDriver BiDi matters

Huggins has been explicit that Vibium is “standards-based”, built on WebDriver BiDi rather than “proprietary protocols controlled by large corporations”. That is a pointed contrast with tools built on the Chrome DevTools Protocol.

For testers this has practical consequences. BiDi is a W3C standard that browser vendors are implementing, which in theory means one protocol for Chrome, Firefox and others. In practice, V1 targets Chrome only. If cross-browser coverage is your main concern today, Playwright and Selenium remain far ahead. We covered the protocol landscape in Playwright vs Cypress vs Selenium and WebDriver BiDi.

Getting started with Vibium

There are two ways to use Vibium: from code, as a human, or through MCP, as an agent.

For humans: the JavaScript API

The JS client offers a synchronous API that is pleasant in a REPL, and an async API for real scripts.

const fs = require('fs')
const { browserSync } = require('vibium')

const vibe = browserSync.launch()
vibe.go('https://example.com')
const png = vibe.screenshot()
fs.writeFileSync('screenshot.png', png)

const link = vibe.find('a')
link.click()
vibe.quit()

The async form is the same calls with await, imported from vibium as browser rather than browserSync. The browser is visible by default, which is the opposite of most test runners and a deliberate choice for people who want to watch what an agent is doing.

For humans: the Python API

from vibium import browser_sync as browser

vibe = browser.launch()
vibe.go("https://example.com")
png = vibe.screenshot()
with open("screenshot.png", "wb") as f:
    f.write(png)

link = vibe.find("a")
link.click()
vibe.quit()

The Python package is split into several distributions, including platform-specific binaries, so pip install vibium pulls the right Clicker for your machine.

For agents: one MCP command

This is the headline feature. To give Claude Code a browser:

claude mcp add vibium -- npx -y vibium

V1 exposes a deliberately small set of MCP tools:

MCP tool	Purpose
browser_launch	Start a browser (visible by default)
browser_navigate	Go to a URL
browser_find	Find an element by CSS selector
browser_click	Click an element
browser_type	Type text into an element
browser_screenshot	Capture the viewport
browser_quit	Close the browser

Seven tools is tiny compared with the dozens in Microsoft’s Playwright MCP server. That is both Vibium’s strength and its limitation, which brings us to the review part.

Vibium review: strengths

1. Simplicity you can explain to a manager

The whole system fits on one slide. One binary, one protocol, one MCP server, two client libraries. When something goes wrong, there are few places to look. For teams that have struggled to debug agent setups with several layers of proxies and plugins, this is refreshing.

2. A small tool surface for agents

Every MCP tool definition costs context. A small, predictable set of verbs makes it easier for a model to choose the right action and harder for it to wander. If your agent only needs to navigate, find, click, type and capture evidence, Vibium’s surface is close to ideal.

3. Standards first

Building on WebDriver BiDi aligns Vibium with the direction of browser automation standards. That matters for the long term, especially for organisations that remember Selenium’s role in creating the WebDriver standard in the first place.

4. Zero-config install

The automatic Chrome for Testing download, platform binaries bundled with npm and PyPI, and a visible browser by default make the first run very quick. That matters for adoption among developers who are trying agentic workflows for the first time.

5. Credible maintainership

The project’s author has created two of the most widely used automation tools in the industry. That does not guarantee success, but it does mean the design decisions are informed by twenty years of seeing what breaks.

Vibium review: limitations

1. It is not a test framework

Vibium V1 has no test runner, no assertions library, no fixtures, no reporters, no parallelism model and no trace viewer. If you want to write a regression suite, you will still reach for Playwright Test, WebdriverIO or Cypress. Vibium is closer to a driver plus an agent bridge.

2. CSS selectors only

browser_find takes a CSS selector. There are no role-based locators, no accessibility-tree snapshots and no text-based queries in V1. Agents generally do better with structured, semantic views of the page, which is why Playwright MCP leans on accessibility snapshots. Vibium’s roadmap mentions AI locators, with examples like vibe.do("click login") and vibe.check(), but those are not available yet.

3. Chrome only

V1 is Chrome only. That is fine for agent exploration and many internal tools, but not for cross-browser regression testing.

4. Very early

No tagged GitHub release had been published as of this writing. The npm and PyPI packages are only weeks old. Expect breaking changes, missing documentation and rough edges, and pin versions if you experiment in CI.

5. The “AI” is still yours

Vibium does not think for you. The model, the prompt and the judgement about whether a behaviour is a bug all come from your agent and your team. That is not a criticism, but it is an important correction to some of the social-media framing.

Vibium vs Playwright MCP: a practical comparison

Most readers will be choosing between Vibium and Microsoft’s Playwright MCP server, so here is how they compare as of January 2026.

Question	Vibium (V1)	Playwright MCP
Protocol	WebDriver BiDi	Playwright’s own protocol over CDP and browser patches
Browsers	Chrome	Chromium, Firefox, WebKit
Page model for agents	CSS selectors, screenshots	Accessibility snapshots with element refs, screenshots
Tool count	7	Dozens
Test runner	None	Playwright Test, separate package
Languages	JS/TS, Python	JS/TS for MCP; Playwright also has Python, Java, .NET
Install	npx -y vibium	npx @playwright/mcp@latest
Maturity	Weeks old	Released in 2025, widely adopted

If you are building a test suite, Playwright wins on almost every axis today. If you want the smallest possible browser tool for an agent, with a standards-based protocol and a maintainer with a long track record, Vibium is worth a trial.

Where Vibium fits in a testing strategy

I find it useful to think in three layers, which we have used in earlier essays such as agentic QA goes mainstream.

Layer 1: deterministic regression checks

These are your scripted end-to-end, API and unit tests. They must be fast, repeatable and reviewed. Vibium is not a replacement here. Keep your Playwright, Cypress or Selenium suites.

Layer 2: agent-assisted authoring and debugging

Here a coding agent reads code, opens a browser, reproduces a bug, and proposes a test or a fix. Vibium’s MCP server is a good fit because the agent mostly needs to navigate, click, type and screenshot. The output you want is still a deterministic test committed to the repo, written in your regular framework.

Layer 3: exploratory, goal-driven sessions

An agent is given a goal, such as “sign up and change the billing plan”, and explores. This is where the sense, think, act vision matters most, and where Vibium V2’s Retina and Cortex could make a real difference. In V1, you will supply the reasoning and memory yourself.

How to evaluate Vibium on your own app

If you want to trial Vibium in January 2026, here is a small, honest evaluation plan.

1. Pick three flows. One simple (log in), one medium (search and filter), one hard (a multi-step form with validation).
2. Run them through your agent with Vibium and with Playwright MCP. Use the same model and prompt.
3. Record outcomes. Did the agent finish? How many tool calls? How many retries? Did it need you to intervene?
4. Inspect the evidence. Screenshots are the main evidence Vibium produces. Decide whether that is enough for your bug reports.
5. Convert the best run into a real test. Ask the agent to write a Playwright or WebdriverIO test from what it learned, then review it as you would any pull request.
6. Pin the version. Note the package version in your notes so you can repeat the comparison when V2 arrives.

This is the same discipline we recommend for any AI testing tool in our 2025 roundup of AI testing tools. Measure outcomes on your app, not the demo app.

Risks and guardrails for agent-driven browsers

Giving an agent a real browser raises the same risks whatever driver you use.

• Credentials. Never let an agent see production secrets. Use test accounts and seeded data.
• Destructive actions. Point agents at staging or ephemeral environments. An agent that can click “Delete workspace” eventually will.
• Prompt injection. Pages can contain instructions aimed at the agent. Treat page content as untrusted input. We covered this in MCP security and the OWASP LLM Top 10.
• Evidence. Keep screenshots and logs from agent sessions. If an agent claims a flow works, you want proof.

Verdict

Vibium V1 does a small number of things well. It gives AI agents a clean, standards-based way to drive Chrome, it installs with almost no friction, and its maintainer has an exceptional track record. It is not a test framework, it does not yet have the semantic page model that agents benefit from, and it is only weeks old.

My recommendation for January 2026: try it for agent-assisted exploration and bug reproduction, keep your regression suite where it is, and watch the V2 roadmap closely. If Retina and Cortex arrive as described, Vibium could become the first browser tool designed end to end around how agents perceive and remember applications.

Frequently asked questions

Who created Vibium?

Vibium was created by Jason Huggins, who started Selenium in 2004 and Appium in 2012. The project lives at github.com/VibiumDev/vibium under the Apache-2.0 licence.

Is Vibium a replacement for Selenium or Playwright?

Not in V1. Vibium is a browser driver with a built-in MCP server for AI agents. It has no test runner, assertions or reporters, and supports Chrome only. Use it alongside a test framework, not instead of one.

How do I connect Vibium to Claude Code?

Run claude mcp add vibium -- npx -y vibium. Chrome for Testing downloads automatically the first time, and the agent gets tools such as browser_navigate, browser_find, browser_click and browser_screenshot.

Which languages does Vibium support?

As of January 2026, JavaScript/TypeScript (npm install vibium) and Python (pip install vibium). A Java client is on the V2 roadmap.

What protocol does Vibium use?

WebDriver BiDi, the W3C bidirectional successor to classic WebDriver. Clicker runs a BiDi proxy on WebSocket port 9515 and launches Chrome with BiDi enabled.

Does Vibium have AI locators?

Not yet. V1 uses CSS selectors. AI locators such as vibe.do("click login") and vibe.check() are listed on the V2 roadmap.

Further reading on CheckOps

• Playwright MCP servers and agentic testing
• Browser agents vs test automation
• Playwright vs Cypress vs Selenium and WebDriver BiDi
• Best AI testing tools 2025: the agentic shift
• Testing vs checking: why your software needs both