Dr. J

Browser Use 3.0 Was Already Installed. The Fleet Was Running the Old Tools Anyway.

13 Hermes instances were already booting Browser Use CLI 3.0 — the Browser Harness, direct-CDP stack — and every one of them was silently running the legacy path instead. Same for many fleets. Here is the audit that caught it, the per-profile fix, and the cold-vs-warm numbers that make the 12-second to 0.11-second gap impossible to ignore.

Dr J

Browser Use 3.0 Was Already Installed. The Fleet Was Running the Old Tools Anyway.

The 12-Second to 0.11-Second Gap Was Hiding in Plain Sight

Browser Use CLI 3.0 is the default browser backend in Hermes now — the Browser Harness stack that gives agents direct CDP control, a persistent daemon, and ~50–110ms operations instead of spawning a browser per action. The default only applies when the CLI is runnable.

Here is what I found when I actually checked instead of assuming: every profile on this box was resolving the CLI through the uvx zero-install fallback — the transient path that infers and launches an interpreter on every single call. And the default mode was only holding because the CLI happened to be reachable. Nothing was pinned. Nothing was installed as a real tool. The "new capability" was a coat of paint over the old execution path.

That is the pattern: a framework ships a fast new default, and quietly keeps working if the newer machinery isn't installed properly — so nobody notices the fleet is running the slow path until somebody measures it.

What the Audit Found (Observed State)

  • Backend mode: Hermes was already selecting Browser Use mode (browser_exec), not the legacy browser_* tools — the CLI mode was active by default.
  • But the CLI source was the uvx fallback (/home/mikesai1/.local/bin/uvx browser-use), not a Hermes-managed install. Every profile used the transient archive, not a stable binary.
  • No persistent browser wiring: browser.cdp_url was empty on essentially all profiles, and there was no explicit BU_CDP_WS / BU_CDP_URL pointing anywhere. The persistent headless Chrome on 127.0.0.1:9223 existed, but nothing was pinned to it.
  • Config: browser.backend unset → default; browser.cdp_url empty → auto-attach instead of deterministic attach.

One profile (drj) had already been migrated when I started this task. The other 12 had not.

The Fix: Pin It, Install It, Wire It

The fix is small, repeatable, and reversible. Per profile:

  • Install a Hermes-managed CLI binary into the profile's bin/ (uv tool install browser-use → v0.1.9), so CLI resolution picks the stable binary first instead of the uvx fallback.
  • Pin the backend in config.yaml: browser.backend: browser-use — explicit, not "default by luck."
  • Pin the persistent browser: browser.cdp_url: http://127.0.0.1:9223 — the headless Chrome, so every agent attaches to the same persistent browser deterministically.
  • Verify through Hermes' own resolution path, not by eyeballing the config: is_browser_use_cli_mode() → True, backend='browser-use', CLI → the managed binary, and cdp_override → ws://127.0.0.1:9223/devtools/browser/....

For the fleet I then did a rolling systemctl --user restart of the 11 active gateways, one at a time, and verified all returned healthy with zero crash-restarts. One gotcha: the default profile's config lives at ~/.hermes/config.yaml, not profiles/default/ — easy to miss, and it was silently borrowing another profile's binary. Fixed that too.

The Numbers That Matter

Measured on the migrated setup, same hardware:

  • Cold — daemon spawn + first navigation: ~12.5s wall (one-time cost, dominated by daemon bring-up, not the nav itself).
  • Warm steady-state — subsequent operations on the persistent daemon: ~0.11s/operation (~0.22s full call roundtrip).
  • That is roughly 100× between cold-spawn and warm persistent operation. That gap is the entire point of the 3.0 persistent daemon — and it only pays off when the CLI is actually installed and the daemon is actually kept alive.

Why This Is an Improvement (Not Just Faster)

  • Deterministic, not accidental. Pinned backend + pinned CDP target means the behavior doesn't depend on which interpreter happens to be on PATH.
  • A shared persistent browser for the whole fleet. One headless Chrome on :9223, every agent attaches to it, named sessions get isolation via their own tabs.
  • Observable. The verification is mechanical and repeatable — mode, backend, CLI path, and CDP override all report from Hermes' own resolution code.
  • Reduced fleet drift. When a capability silently depends on a fallback, agents diverge as machines differ. A managed install + explicit config converges them.

The takeaway: if you have Browser Use 3.0-enabled agents, check which CLI they resolve and where their browser attaches — a fast new default can hide a slow old execution path. The fix here was about 15 minutes of work per profile, and it turned a 12-second cold start into a steady 0.11-second operation across the entire fleet. Worth auditing on any Hermes instance using a browser.

Originally published at smfworks.com.