Imagine fifty AI agents opening documentation pages at the same time.

None of them needs a toolbar. None cares about smooth scrolling. Most will not watch a video, use WebGL, or install an extension. They need the text, a few links and form controls, and enough state to decide what to do next.

Yet the usual solution is to start fifty copies of a browser designed for people.

This is not a criticism of Chromium. Its compatibility is extraordinary, and Playwright makes it one of the most practical automation targets available. But it made me wonder: if the workload is different, should the browser be different too?

That question led me to build h5i, an open-source headless browser for AI agents. The browser engine runs as a single Rust process. It does not launch Chromium, embed V8, or communicate through Chrome DevTools Protocol.

This post is about the design decisions behind it, what became possible after removing the human-browser assumptions, and where the approach still falls short.

The browser can be the booleneck in an agent loop

A browser session for an agent often looks like this:

1. Open a page.

2. Convert the page into something a model can understand.

3. Let the model choose an action.

4. Perform the action.

5. Send the resulting page back to the model.

When Chromium sits underneath this loop, several layers come along for the ride. The browser maintains renderer processes and a complete web platform. An automation client talks to it through a protocol. Another layer turns the DOM or accessibility tree into model input. Request interception and audit logging may be attached separately.

That architecture is justified when the target is the full modern web, that only humans care about. It is less obviously necessary when the task is “read this documentation page and follow the installation link.”

I wanted a much more optimized browser for three things that become important when browser sessions are created by agents rather than people:

• A small amount of state per session

• An interface that does not waste model context

• Network policy that is part of the browser, not an optional observer

These constraints shaped almost every implementation choice.

Building the engine from Rust components

h5i is not a browser wrapper. Its engine combines several Rust projects with a custom networking layer:

Together, these components support navigation, forms, cookies, JavaScript, screenshots, WebSockets, Server-Sent Events, and structured extraction.

The interesting part is not that each component happens to be written in Rust. It is that h5i owns the path from an agent action to the outgoing network request. There is no remote-controlled browser process in the middle.

That gives the project a much smaller scope, but it also forces an honest tradeoff. Boa does not behave like V8, and h5i does not implement the entire browser platform. Content-heavy pages and ordinary interactions are the primary target. A complex React application, nested iframes, DRM-protected media, or WebGL workload may require Chromium.

The reduced compatibility is not an accidental limitation hidden behind the word “lightweight.” It is the cost of choosing a smaller browser.

The page is a state machine

The first interface I wanted to reconsider was page observation.

A screenshot is natural for a person, but expensive and ambiguous for a model. A raw DOM contains more implementation detail than the agent usually needs. Even a useful accessibility tree can become large when it is serialized after every action.

h5i instead produces a compact snapshot with references attached to actionable elements:

h5i browser open https://docs.rs/ --allow docs.rs
h5i browser snapshot

The agent might see a link identified as @e3. It can act on the reference directly:

h5i browser click @e3

The reference belongs to the snapshot that introduced it. If navigation or JavaScript changes the page and the old identifier is no longer safe, h5i rejects the action as stale. This is preferable to silently clicking whatever happens to match an old selector.

The next observation can be a delta:

h5i browser snapshot --delta

Instead of serializing the page again, h5i reports what changed since the previous snapshot. In a long agent loop, that changes the cost model. The first read describes the page; later reads describe transitions.

When the agent already knows the desired shape, it can skip the general reading step and request structured data:

h5i browser extract '{"titles": ["h2"]}'

This is the interface I increasingly think agent browsers should expose: observable state, explicit actions, and compact transitions. Pixels can still be generated when visual information matters, but they do not need to be the default representation.

Making every request accountable

The second interface I wanted to reconsider was networking.

An agent does not merely visit the URL supplied by its user. A page can load subresources, open a WebSocket, submit a form, execute JavaScript, or redirect through several origins. Page content can also try to persuade the model to visit a private service or disclose information elsewhere.

For that reason, h5i treats each outgoing request as a policy decision.

Conceptually, the path is:

agent action -> construct request -> check policy -> record receipt -> send bytes

Redirects return to the policy check rather than inheriting approval from the initial URL. Allowed and denied requests are both visible in the session history. If h5i cannot write the receipt, it refuses to send the request.

The agent can inspect this state without leaving the browser workflow:

h5i browser requests
h5i browser audit

The audit output connects browser actions, network activity, human handovers, and the way the session ended. Content returned from a page is fenced and labeled as untrusted before it is shown to the model.

This does not solve prompt injection. A model can still make a bad decision. The narrower claim is that a hostile page should not be able to bypass the browser's network policy, and that the resulting behavior should be reconstructable afterward.

h5i vs Chromium

To measure the overhead that motivated the project, I tested a cold read of a documentation-style page.

h5i was about 3× faster and used 86% less peak memory.

The practical question is not “which browser wins?” It is “how often does my agent need the complete browser platform?”

For one long-lived session, Chromium's startup cost may be irrelevant. For a service that creates many short-lived sessions to read pages, tens or hundreds of megabytes per session determine how many agents fit on the same machine.

Reference

• https://h5i.dev/

• https://github.com/h5i-dev/h5i

• https://github.com/boa-dev/boa

• https://www.reddit.com/r/codex/comments/1w0trw7/i_built_a_headless_browser_for_ai_agents_entirely/

• https://www.reddit.com/r/vibecoding/comments/1w5ea1t/github\_h5idevh5i\_a\_headless\_browser\_purely/