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.
The two options that annoyed me
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.
The idea: turn a real tab into a node
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.
The part that matters for agents: code drives, the model decides
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.
Quick start
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.
Security was a first-class goal, not a footnote
Handing automation a real logged-in browser is powerful, so the defaults are conservative:
- Token auth with client-secret exchange; secrets go in the OS keychain when one is available.
- Per-node ACL grants — a controller can't route commands to a node until that node grants it.
- Replay protection via a nonce plus a timestamp window.
- Pre-ingress log redaction — sensitive fields are stripped before logs are persisted or streamed.
- No credential automation, on purpose. Otto never types your passwords. You authenticate manually, then rerun. That's a deliberate line: it keeps the tool out of the "automated account takeover" business.
Where it fits
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.
Try it / break it
It's MIT-licensed and on npm as @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?