# OTTO: Give your AI agent a real browser without running a browser farm

> Source: <https://dev.to/sebivaduva/otto-give-your-ai-agent-a-real-browser-without-running-a-browser-farm-3dk5>
> Published: 2026-06-16 10:02:47+00:00

Otto controls real Chrome tabs from your CLI or your LLM over a secure relay — no headless farm, no cloud-browser rental. Here's how it works and why interaction should be code, not tokens:

Every time I needed an agent (or a test, or a monitor) to touch a real website, I hit the same wall: the browser. Not the automation logic — the *infrastructure* under it. You end up choosing between two bad options, and I got tired of both, so I built a third. It's open source and it's called **Otto**.

**Option one: run a headless farm.** Spin up Docker, manage a pool of Puppeteer/Playwright instances, keep them patched, scale them, and pray your IPs don't get flagged. It works, but it's a standing operational cost, and headless Chrome is *not* the same as the browser you actually use. Different fingerprint, different behavior, no logged-in session. Plenty of sites quietly serve headless traffic a worse — or broken — experience.

**Option two: rent cloud browsers.** Pay a per-session or per-minute fee to a hosted-browser service. Convenient until the bill scales with your usage, and you're still not running in *your* real session with *your* cookies.

What I actually wanted was dumb and simple: drive the real Chrome tab already sitting on my machine — logged in, warmed up, indistinguishable from me — from a script or an agent running somewhere else. No farm. No rental. Just the tab.

Otto is three pieces connected over authenticated WebSocket:

```
Controller (otto CLI / script)
        |  WebSocket (authenticated)
        v
  Relay daemon  (:8787)
        |  WebSocket (authenticated, node)
        v
  Extension node (Chrome)
        |  chrome.tabs / chrome.scripting
        v
  Browser tab (managed, site-scoped)
```

A lightweight Chrome **extension** turns a live tab into a *node*. A **relay daemon** authenticates connections, authorizes commands by scope, and routes them to the right node. A **controller** — the `otto`

CLI, a script, or an agent — sends command envelopes to the relay.

The nice consequence: the controller and the browser don't have to live on the same machine. Your agent can run on a server and drive a Chrome tab open on your laptop, because the relay handles routing and auth in between. Execution is serial per tab and parallel across tabs, with replay protection on every command.

This is the design decision I care about most, so let me be blunt about it.

If you wire an LLM directly to a browser and let it perform *every* interaction — "find the button," "click at these coordinates," "type this character" — you pay for all of that in tokens and latency. The model becomes a very expensive mouse.

Otto splits the responsibilities. **Deterministic code** handles the mechanics: opening tabs, navigating, querying the DOM, extracting text/markdown/clean HTML, screenshots, clicking, typing, intercepting network traffic. The **model** only decides *what to do next*. It calls a command, gets a structured result, and reasons about strategy — not about pixel coordinates.

Concretely, the surface looks like primitives plus site-scoped commands:

```
# universal primitives
otto extract-content https://news.ycombinator.com   # → markdown
# tab open / close / navigate / query
# extract_text / extract_markdown / extract_clean_html / screenshot

# site-scoped command bundles, e.g.
otto commands list --site reddit.com
# → getPosts, getUserInfo, sendChatMessage, commentOnPost, ...
```

Those site command bundles are versioned, shareable, and testable — you author a reusable command for a domain once instead of re-deriving the DOM dance on every run. And because there's an **MCP server**, an agent (Claude, an OpenAI tool-use loop, whatever speaks MCP) can call these directly as tools.

Requirements: Node.js 20+, Chrome, npm.

```
# 1. install the CLI
npm install -g @telepat/otto

# 2. guided setup (prints the extension path to load)
otto setup

# 3. load the unpacked extension into Chrome at the printed path

# 4. register and log in a controller identity
otto client register --name "my-laptop" --description "Local controller"
otto client login

# 5. verify the stack
otto commands list
```

For headless/CI use, `otto setup --non-interactive`

emits deterministic JSON with no TTY prompts, most commands take `--json`

, and `otto logs follow --source all`

streams structured events by `requestId`

so you can correlate relay, controller, and node in real time while debugging an agent run.

Handing automation a *real* logged-in browser is powerful, so the defaults are conservative:

Otto is built for developers and automation teams who need *real* browser context — integration tests against logged-in flows, uptime/monitoring on pages that gate headless traffic, scraping that has to look human, and agent workflows that read and act on live sites. If your use case is genuinely fine with headless, you may not need this. If headless keeps lying to you, this is the alternative.

It's MIT-licensed and on npm as [ @telepat/otto](https://www.npmjs.com/package/@telepat/otto). Repo and docs:

It's early. I'd genuinely rather hear where the design is wrong than collect polite stars — so if you run it and something feels off (the relay model, the security assumptions, the command-bundle approach), tell me in the comments. What would you point it at first?