Control a browser with an LLM, over a local API

A browser you can program

LLM Browser is a normal desktop browser with a built-in AI assistant, but it is also a browser you can control with an LLM from the outside. Turn on the Bridge Server in settings and the browser starts listening on a local port, ready to take commands from any client you authorise. That makes it a solid target for an agent that needs a real, signed-in browser to act in, rather than a headless shell.

JSON-RPC 2.0 over HTTP and WebSocket

The control server speaks JSON-RPC 2.0 over two transports on a local port, 9224 by default:

• HTTP for simple request and response calls, ideal for one-off actions from a script.
• WebSocket for long-lived sessions and streaming, ideal when an agent drives the browser through many steps in a row.

Because it is standard JSON-RPC, you can call it from any language that can make an HTTP request or open a WebSocket. There is no special SDK to learn first.

Bearer-token authentication

The server runs locally and is protected by a token. In settings you enable the control server, set the port, and copy the bridge token. Every request must then carry an Authorization: Bearer <token> header, so only clients you have authorised can drive the browser. You can change the port, regenerate the token, set the server to auto-start on launch, or turn it off entirely, all from the Bridge Server tab.

What external clients can do

Over the control API, your scripts and agents can:

• Navigate the browser to any URL.
• Read page content back, so an agent can reason over what is actually on screen.
• Take screenshots of the current view for logging, vision models, or human review.

That covers the core loop an external agent needs: send the browser somewhere, read what loaded, and capture proof of state, all against real pages you are signed in to.

A typical request and response loop

Driving the browser comes down to a small, predictable cycle. A client opens a connection on the control port, includes its bearer token, and sends a JSON-RPC request to navigate somewhere. The browser loads the page and the client then asks to read the page content back, reasons over it, and decides on the next move, perhaps navigating again or grabbing a screenshot for a record. Over the WebSocket transport this loop can run for many steps in a single session, which is the natural fit for an agent working through a longer task without re-authenticating each time.

Built for agents and multi-agent systems

A standard JSON-RPC surface with token auth makes LLM Browser easy to slot into larger setups:

• Language-agnostic: any stack that can make an HTTP call or open a WebSocket can drive it, so you are not locked into one ecosystem.
• A real browser to act in: agents get genuine, signed-in pages rather than a stripped-down headless context.
• One browser, two ways in: the in-window assistant and external clients share the same browser, so a human and a script can use it interchangeably.
• Local and controllable: the server is on your own machine, on a port and token you set, and you can turn it off the moment you do not need it.

When to drive it from code instead of chatting

The in-window assistant is perfect for hands-on work you watch happen. Reach for the control API instead when you want repeatable, unattended automation, when you are wiring the browser into a larger multi-agent system, or when the model lives in another process entirely. The two approaches share the same browser, so you can prototype a flow by hand in the bridge panel, then script it once it works.

Where to go next

If privacy matters for your automation, pair the control API with an AI browser running a local LLM, so both the model and the browser stay on your own machine. And for the most common scripted chore of all, see how it works as an AI browser that fills forms.