The Vibium Roadmap for 2026

The Vibium roadmap for 2026 is best read as "most of the foundation is already in your hands, and the rest is demand-driven." Vibium — the AI-native browser automation tool created by Jason Huggins, co-creator of Selenium and Appium — reached a stable v1 in December 2025 and shipped a large 26.2 release in February 2026 with 168 commands at near-parity across six targets (JS async/sync, Python async/sync, MCP, and CLI). That means Chrome automation, auto-waiting, network mocking, tracing, cookies, a built-in MCP server, and Python and JS/TS clients are shipped today, not promised. What remains on the forward roadmap is broader browser support beyond Chrome, built-in video recording, AI-powered natural-language locators (page.do(), page.check()), and official Java and .NET clients. Crucially, Vibium uses calendar versioning and ships when ready — there are no fixed dates. This guide maps the shipped base against what is coming, and gives you a practical framework to plan adoption around reality.

What does the Vibium roadmap for 2026 actually cover?

The Vibium roadmap for 2026 splits cleanly into a shipped foundation and a demand-driven forward list. The single most useful mental model is a three-stage pipeline: features move from a shipped base, through the team's demand-driven prioritization loop, into a planned wave of releases — and your job as an adopter is to map your needs onto the right stage.

This matters because most confusion about Vibium comes from treating the roadmap as a wishlist. In reality, the "future features" list from the original v1 plan has already been overtaken — the Python client, network interception, and tracing all shipped ahead of schedule. So before you assume something is missing, check whether it already landed in 26.2. For the full picture of the current product, start with what is Vibium.

What has Vibium already shipped in 2026?

Nearly the entire practical toolkit for Chrome automation is shipped and stable as of the 26.2 release. If you are evaluating Vibium in 2026, this is your working feature set today, not a preview.

The headline number is worth repeating: 168 commands across 23 categories, at near-parity across six implementation targets. The same operation behaves the same way whether you call it from JS async, JS sync, Python async, Python sync, MCP, or the CLI — with camelCase in JavaScript and snake_case in Python.

Here is roughly what the shipped surface looks like in practice, using verified 26.2 APIs:

// JS — shipped today (26.2). Semantic find + network mock + tracing.
const { browser } = require('vibium/sync');
 
const bro = browser.launch();
const ctx = bro.newContext();
const vibe = ctx.page();
 
// mock an API before navigating
vibe.route('**/api/users', route => {
  route.fulfill({ status: 200, body: JSON.stringify([{ name: 'test' }]) });
});
 
ctx.tracing.start({ screenshots: true, snapshots: true });
vibe.go('https://example.com');
 
// find by role + text, not brittle CSS
vibe.find({ role: 'button', text: 'Submit' }).click();
 
ctx.tracing.stop({ path: 'trace.zip' });
bro.quit();

# Python sync — shipped today. Same capabilities, snake_case naming.
from vibium import browser_sync as browser
 
vibe = browser.launch()
vibe.go("https://example.com")
 
# CSS find still works; semantic find is available too
el = vibe.find("button.submit")
el.click()
 
vibe.screenshot()
vibe.quit()

If you assumed tracing, network mocking, or the Python client were still "coming," they are current. To get hands-on with the shipped base, follow install Vibium and the find element reference.

What is coming next on the Vibium roadmap?

Four items lead the forward-looking Vibium roadmap, and each is gated on user demand rather than a committed date. Reading them accurately keeps your adoption plan honest.

Will Vibium support Firefox and Edge?

Cross-browser support beyond Chrome is on the roadmap but not shipped. Vibium automates Chrome only today, via a pinned Chrome for Testing download that it fetches automatically. Firefox and Edge are planned as incremental work — Chrome covers the large majority of use cases, and because WebDriver BiDi implementations differ across browsers, each one is a separate effort. If cross-browser coverage is essential for you right now, pair Vibium with another tool until this lands. See how the single-browser trade-off compares in Vibium vs Playwright.

When will Vibium add video recording?

Built-in session video recording is planned but not yet shipped. The intended design captures frames and encodes them to a video artifact, exposed through start/stop controls, for failure debugging, demos, and audit trails. In the meantime, the shipped combination of screenshots plus the new tracing viewer (with screenshots, DOM snapshots, and a network waterfall) already covers most debugging needs. For current capture options, see take a full-page screenshot.

Are AI-powered locators shipped yet?

This is the headline future feature, and it is not in 26.2. The plan is natural-language finding and assertions:

// Roadmap (not yet shipped) — illustrative API only.
// await vibe.do("click the login button");
// await vibe.check("verify the dashboard loaded");
// const el = await vibe.find("the blue submit button");

It is also the hardest item on the list. It raises open questions the team is deliberately researching: which vision model to use, whether to run it locally or via API, how to manage latency and cost, and how to resolve ambiguity when "the button" matches five elements. Until it ships, Vibium's AI-native angle is its MCP server for Claude Code plus semantic finds by role, text, label, and testid — which already let agents target elements by intent rather than by CSS.

When are the Java and .NET clients coming?

Official Java and .NET clients are planned but gated on enterprise demand. A community .NET implementation already exists (by @jimevans) but is not officially supported. For 2026, the officially supported clients remain Python and JavaScript/TypeScript. If your stack is JVM- or .NET-first, treat this as a "watch the roadmap" item rather than a reason to adopt today.

What does a realistic 2026 timeline look like?

There is no official quarter-by-quarter Vibium roadmap, because the project ships when features are ready rather than on a calendar. But you can still reason about likely sequencing from the team's stated tentative priority order and from what each feature depends on. The following is an interpretation of that priority order, not a set of promises — read it as "probable direction," and always confirm against the live roadmap and release notes.

The reason video recording and network parity sit earlier is that they build on infrastructure Vibium already has — the screenshot pipeline and the shipped network module — so they are lower-risk, moderate-effort additions. Cross-browser support sits in the middle because each browser's BiDi implementation diverges and needs its own work. AI locators sit last not because they are unimportant, but because they carry the highest uncertainty: they need a dedicated research spike on vision models, latency, and cost before a design is even locked.

This sequencing logic is more durable than any date. If you are budgeting a project around Vibium, plan against dependencies and confidence, not against a guessed release month.

How can I track the Vibium roadmap myself?

You do not have to take a third-party summary's word for what is shipped — the roadmap is verifiable, and checking it yourself takes minutes. This is especially worth doing because the surface grew significantly between v1 and 26.2, so older articles can be out of date.

The most reliable signals, in order of authority:

• The official release notes and ROADMAP.md on github.com/VibiumDev/vibium. Release notes tell you exactly what shipped in each CalVer drop; the roadmap file states the forward list. This is ground truth.
• The changelog / commit history. Because Vibium is demand-driven, watching which issues get closed shows you what is actively moving, not just what is planned.
• Your installed version. The fastest check of all is to ask your own install what it can do:

# Confirm which version (and therefore which capabilities) you actually have
vibium version
 
# List every CLI command your install supports — the surface IS the roadmap-so-far
vibium --help

// Programmatically confirm a capability exists before you rely on it
const { browser } = require('vibium/sync');
const bro = browser.launch();
const ctx = bro.newContext();
 
// tracing shipped in 26.2 — this will exist on a current install
console.log(typeof ctx.tracing.start); // "function" on 26.2+
bro.quit();

If a method exists on your installed version, it is shipped for you — no roadmap interpretation required. When in doubt about an API detail, prefer the official documentation over blog posts, since the parity work in 26.2 changed a lot of the surface at once.

How does the demand-driven roadmap process work?

Vibium's roadmap is explicitly demand-driven: the team's stated principle is to "build what's requested, not what we assume is needed." This is not marketing — it is visible in the release history, where originally-deferred items like the Python client and network tracing were pulled forward because users asked for them.

Two mechanics shape how features move:

• Calendar versioning (CalVer). A release like 26.2 simply means February 2026. There is no semantic-version promise and no fixed date for the next drop — it ships when it is ready. This is why you should plan around capabilities, not release numbers.
• Feedback channels drive priority. GitHub issues on github.com/VibiumDev/vibium and the community Discord are where demand is registered. A concrete request with a real use case ("we need Edge for enterprise SSO testing") carries more weight than an abstract vote.

The practical takeaway: if a roadmap item would unblock you, the most effective move is to file a specific issue describing the use case. Because the order is tentative and demand-sensitive, that feedback genuinely shifts priority.

What is the longer-term Vibium vision beyond 2026?

Beyond the 2026 feature list, Vibium is framed as a robotics-style "Sense → Think → Act" control loop — but only one layer is built, and the other two are exploratory.

Cortex (a datastore that builds an "app map" and plans navigation) and Retina (a Chrome extension that records human and agent sessions) are deliberately deferred. The team is candid that they may be premature — agents driving Vibium through Claude Code already carry their own conversation context, so persistent navigation graphs and session replay might add little. These will be built only if users report needing them. Treat Sense and Think as direction, not commitments — the concrete 2026 roadmap is the four features above.

How does Vibium's roadmap approach compare to Playwright and Selenium?

Vibium's roadmap philosophy is genuinely different from the incumbents, and understanding that difference helps set expectations fairly. This is not a claim that Vibium is "better" — the older tools are more mature — but the way each project evolves affects how you should plan.

The honest reading: Playwright and Selenium already have the cross-browser and multi-language coverage that sits on Vibium's roadmap. What Vibium offers in exchange is a fresher, AI-native design — a single Go binary, a built-in MCP server, and one unified find() — from a creator who has built browser automation twice before. If broad coverage today is the priority, the mature tools win; if a lean, agent-first engine on the WebDriver BiDi standard is the priority, Vibium's shipped base is compelling and its roadmap is closing the gaps. For a full side-by-side, see Vibium vs Playwright.

The gotcha to plan for: because Vibium is younger and demand-driven, some features you might expect from a mature tool are still ahead. That is a reason to scope your first project to Chrome and Python/JS, not a reason to avoid the tool — the shipped 26.2 surface is already broad enough for real work.

How should the 2026 roadmap shape my adoption decision?

Adopt Vibium for what is shipped, and let the roadmap tell you whether to wait. The cleanest way to decide is to match your situation to a lane.

A useful rule of thumb: if your requirement appears in the "Shipped" table above, you are safe to build today. If it appears only in the "coming next" section, either pair Vibium with another tool or file a demand signal and track the roadmap.

For a deeper maturity assessment that complements this roadmap, read is Vibium production-ready. If you are weighing Vibium against the incumbents while the roadmap fills in, Vibium vs Selenium covers the ecosystem-maturity trade-off honestly.

Migration and gotchas: planning around a moving roadmap

Because the roadmap moves, a few practical cautions keep your project safe. First, pin your reasoning to shipped capabilities, not to roadmap items — never write a plan that assumes Firefox support or AI locators will arrive by a certain date, since there are no committed dates. Second, the 26.2 API is broad but young; the sync APIs are first-class and match the async method count, but the ecosystem (plugins, Stack Overflow answers, third-party integrations) is smaller than Selenium's or Playwright's, so budget time for reading official docs over community shortcuts.

Third, if you are coming from another tool, the semantic find() and Playwright-compatible tracing make migration approachable, but remember Vibium is Chrome-only — a cross-browser Playwright or Selenium suite will not port one-to-one until browser support expands. When you do adopt, structure tests with a page object model so that if roadmap features (like AI locators) change how you target elements later, the churn stays isolated to your locator layer.

Finally, verify API details against the official documentation rather than older blog posts, since the surface grew significantly between v1 and 26.2. The Vibium glossary is a quick reference for the terms used across this roadmap.

The bottom line on Vibium's 2026 roadmap

For 2026, Vibium's roadmap is unusually reassuring: the foundation an adopter needs — Chrome automation, auto-waiting, semantic finds, network mocking, tracing, a built-in MCP server, and Python plus JS/TS clients — is already shipped and at near-parity across six targets. The forward list (cross-browser, video recording, AI locators, Java/.NET) is real but demand-driven and dateless, which is exactly why you should plan around today's capabilities and treat the roadmap as a signal for when to expand, not a promise to bank on. If your work is Chrome-and-Python/JS with AI agents in the loop, there is no reason to wait. If you need what is still ahead, the most productive step is to register your use case and track the 45-day roadmap and release notes.

Next steps

• What is Vibium — the shipped product in one page
• Install Vibium — get the single binary and auto-download Chrome
• Find element — CSS and semantic finding, the core skill
• Vibium MCP in Claude Code — the AI-native path that ships today
• Is Vibium production-ready — maturity check alongside this roadmap
• Page object model — structure tests to absorb future roadmap changes
• Follow the learning course — a guided path through Vibium from zero