vibatchium

vibatchium

The browser layer for an always-on box. Many logged-in identities, running unattended, all at once — on real Chrome, with stealth on by default, and with a security model for letting an AI near the credentials.

One daemon, N persistent Chrome sessions, a vb CLI and an MCP server. Self-hosted, free, Apache-2.0.

pipx install 'vibatchium[all]'

patchright install chrome vb setup # register the MCP server + agent skill (Claude Code, Codex, Cursor) vb explore https://example.com

Is this for you?

That last row is the whole wedge. Supervised agents hand control back to you at every login wall and CAPTCHA; a library leaves the fleet — sessions, budgets, crash recovery, credentials — for you to build. vibatchium is that fleet layer.

How it compares

As of 2026-10-06, from each project's own README, source and release notes (the MCP-cost row is our own measurement¹). Rows where we lose are included on purpose.

¹ bytes/4 of tools/list plus server instructions, measured over stdio. Clients without tool search load every tool: vb mcp --caps min is 12 tools, ~3.8k tokens. bladebro's own README says ~1.9k.

Where the others are genuinely better: CloakBrowser's engine-level patches go deeper than any CDP-level layer can — and vb start --browser-binary will drive a Chromium build you bring. bladebro has a stealth benchmark number and we don't; until we do, read our stealth claims as measured on scoreboards, below, not on production walls. Both run on more operating systems.

What only vibatchium does

1. A fleet of logged-in identities on one box. Each session is its own Chrome and profile, with its own proxy, timezone and GPU node, and — opt-in with vb persona set — its own screen and window, because by default every headless session on one machine reports the same 800×600 screen. vb fleet-check measures how alike your sessions still look. They run in parallel on one daemon that keeps them alive: a crashed renderer is relaunched on the same profile, parked sessions have their renderers stopped and thawed on the next call, leases stop two agents clobbering one session, and goals give a task a step/spend/time budget that survives a daemon restart.

vb --session alice start && vb --session alice go https://x.com      # log in once, stays logged in

vb --session bob start && vb --session bob go https://x.com vb --session alice act "open notifications" & vb --session bob extract & wait vb fleet-check --sessions alice,bob # how twinned are they?

2. Credentials an agent can use but never see. The vault fills a password or a live TOTP code into the page without the value reaching the model's context, a screenshot or a log — and only into the site it belongs to. Over MCP, a prompt-injected agent can't type your GitHub password into a lookalike page, can't read it back with value or eval while it sits in the field, and can't edit the vault or pull a code. An agent with a *shell* is the operator — the CLI has deliberate escape hatches — so give agents MCP, not Bash, if that boundary matters to you.

printf %s "$GH_PASSWORD" | vb secret set github.com password --stdin

printf %s "$GH_TOTP_SEED" | vb secret set github.com totp-seed --stdin vb --session work fill @e7 --use-secret github.com:password vb --session work fill @e9 --use-secret github.com:totp vb wait-email-code github.com # operator CLI: polls IMAP and prints the code; refused over MCP

3. Page text is treated as untrusted. Every session scans the page text it returns for instructions aimed at the agent and flags them by default; wrap fences them off and redact removes them. Caller-supplied file paths are confined too, so an injected agent can't upload ~/.ssh or write into .git/hooks.

4. A browserless lane on the same identity. vb fetch reuses a session's cookies and proxy with Chrome's TLS fingerprint and client hints — JSON endpoints behind your login at curl speed, and it tells you when it can't match the browser. vb search finds URLs with no API key and no per-session budget.

vb --session work fetch https://api.example.com/v1/me

vb search "site reliability postmortem" -n 20 --urls

Status: alpha, active development. 2,331 tests green in CI (Linux, Python 3.11–3.14). Coding agents: read AGENTS.md first — the one-call recipes and the traps worth skipping.

Detector scores quoted below (bot.sannysoft, CreepJS, Cloudflare cold-launch) are manual observations, not CI-asserted — no test in the suite gates on them, and they are only as current as the last hand-run. The generated block under Measured scores is the one to trust.

Install

pipx install vibatchium             # core: browse / extract / screenshot / N parallel sessions

pipx install 'vibatchium[all]' # + fetch/search lanes, credential vault, VLM read, REST shim

(or pick extras: [fetch], [secrets], [llm], [rest])

patchright install chrome vb setup # register MCP + an auto-discoverable skill (idempotent) vb install # report which optional lanes are available

On a uv venv (no pip), add an extra with uv pip install --python /bin/python curl_cffi. Bleeding edge from master: pipx install 'git+https://github.com/trueoriginlabs/vibatchium#egg=vibatchium[all]'.

Install as a skill / plugin

vb setup wires up the agents on *this* machine. To pull just the agent skill into any agent skills.sh supports (Claude Code, Codex, Cursor, Gemini CLI, Copilot, …), or to install skill + MCP server as one Claude Code plugin:

npx skills add trueoriginlabs/vibatchium                  # skill only, any agent

/plugin marketplace add trueoriginlabs/vibatchium # Claude Code: skill + vb mcp /plugin install vibatchium@vibatchium

Both still need the vb CLI on PATH (pipx install 'vibatchium[all]') — the skill drives it and the plugin's MCP server *is* vb mcp. On Claude Code, pick the plugin or vb setup, not both, or you register the server twice. The skill file is generated from vibatchium/setup_cmd.py; edit there and run python scripts/sync_skill.py.

Quick start

vb explore https://example.com                      # one call: text-first, auto-closes

vb research --target https://example.com \ # parallel fan-out, N intents --intent "pricing model" --intent "customers" --intent "tech stack"

Real Chrome vs fake Chrome

A wave of "headless browser for AI agents" tools rebuild the browser from scratch (Rust + V8, no Blink/Skia) to hit tiny memory and sub-100ms page loads. The catch is structural: with no rendering engine, they can't produce a real device's fingerprint — they synthesize one. And synthetic fingerprints don't hold still.

vibatchium drives *real* Google Chrome, so its fingerprints are real — and, more to the point, stable. The single test that separates the two is fingerprint stability across navigations. Run the same canvas + WebGL probe on two pages in one session:

¹ Chrome's own software renderer (SwiftShader) by default — still a coherent, deterministic Chrome value, not a stub. A hardware-GPU string (e.g. ANGLE (Intel …)) needs the opt-in --gpu flag.

A real device returns the same fingerprint every page load; a fingerprint keyed off Date.now() does not — and *that inconsistency* is exactly what lie-detection fingerprinters (CreepJS and friends) flag. Measured: vibatchium's canvas hash and WebGL readback are byte-identical across navigations, and CreepJS reported 0 % stealth-tampering (no synthetic-environment signatures) when last run by hand. That figure is not regression-tested — treat it as an observation, not a guarantee.

This is not a claim of invisibility. The moat is fingerprint *authenticity*, not hiding that a browser is automated — vibatchium still reads as headless on the headless-specific tells (see Honest limits), and real-GPU WebGL (--gpu) is opt-in. But real, consistent fingerprints pass the consistency tier that synthetic ones fail *by construction* — and that tier is what stands between you and a login wall.

Multi-session in 10 lines

vb session new work

vb --session work start vb --session work go https://github.com # log in by hand once vb session new banking vb --session banking start vb --session banking go https://bank.example.com vb --session work click @e3 & # truly parallel — vb --session banking fill @e5 hi & # separate Chromes, no cookie bleed wait vb session list

Active-session resolution: --session FLAG → $VIBATCHIUM_SESSION env → ~/.config/vibatchium/active-session → default. Cap via VIBATCHIUM_MAX_SESSIONS=8 (default 8).

Multi-agent: shared sessions vs a private daemon

On one s