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

A developer built Otto, an open-source tool that lets AI agents control real Chrome tabs from a CLI or LLM over a secure WebSocket relay, eliminating the need for headless browser farms or cloud-browser rentals. Otto splits responsibilities between deterministic code for browser mechanics and the model for high-level decisions, reducing token costs and latency. The tool includes an MCP server for agent integration and supports site-scoped command bundles.

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?