Nanobrowser: A Chrome Extension That Runs Multi-Agent Web Automation on Your Own API Keys

The Gap Nanobrowser Fills: Browser Automation Without a Subscription or a Cloud Round Trip

Hosted browser agents generally work the same way. You hand a task to a vendor, the vendor drives a browser in its own infrastructure, and you pay a monthly fee for the privilege. Two things follow from that arrangement. The first is cost, which the README frames bluntly by contrasting itself with the price tag it attributes to OpenAI Operator. The second is custody of credentials. If the automation needs to reach a page behind a login, the session either lives with the vendor or gets replayed into the vendor's browser.

Nanobrowser inverts that. It ships as a Chrome extension, so the automation runs inside the browser you are already signed into. The README states that everything runs in the local browser and that credentials are never shared with a cloud service. The only external call is to whichever LLM provider you configured, and you pay that provider directly at its own rates. There is no Nanobrowser account layer in the described flow.

The audience is narrow and specific. It is engineers and technical operators who are comfortable pasting API keys into an extension settings panel, who want to choose a different model per agent, and who would rather read TypeScript than file a support ticket. It is not aimed at people who want a finished product with a billing relationship attached.

Planner and Navigator: How the Two-Agent Loop Is Described

The mechanism the README puts forward is a two-role split. A Planner handles reasoning and task decomposition. A Navigator handles the actual page interaction. The demo caption describes the Planner self-correcting when it hits an obstacle and then instructing the Navigator to adjust its approach, which tells you the two roles exchange information mid-task rather than running a fixed script.

That division has a practical consequence for cost. The README's model guidance assigns a stronger, more expensive model to the Planner and a cheaper one to the Navigator, on the reasoning that planning benefits from better reasoning while navigation is comparatively mechanical. The recommended pairings are explicit: Claude Sonnet 4 for the Planner with Claude Haiku 3.5 for the Navigator under the performance configuration, or Claude Haiku and GPT-4o as Planner with Gemini 2.5 Flash and GPT-4o-mini as Navigator under the cost configuration. The README also warns that the cheaper Planner may need more iterations on complex tasks, which is the honest way of saying you trade tokens for dollars.

What the README does not document is the message format between the two agents, the retry policy when a step fails, or how the Planner's self-correction is bounded. Those details live in the source, not in the README, and anyone evaluating this for production work will need to read them there. The extension also keeps conversation history and supports follow-up questions about completed tasks, which implies state persists across turns within a session.

Installing It: Store Build, Manual Zip, or Build From Source

There are three paths, and they differ in how current the code is. The Chrome Web Store listing is the stable channel, and the README warns directly that it may lag behind because of the review process. If you want the newest features, the README points you at the manual install instead.

The manual path is the standard unpacked-extension routine. Download the latest nanobrowser.zip from the GitHub release page, unzip it, open chrome://extensions/, enable Developer mode in the top right, click Load unpacked, and select the unzipped nanobrowser folder. Upgrading means downloading the new zip, replacing the existing files, and clicking the refresh icon on the Nanobrowser card in chrome://extensions/.

Building from source needs Node.js v22.12.0 or higher and pnpm v9.15.1 or higher. The commands are git clone https://github.com/nanobrowser/nanobrowser.git, cd nanobrowser, pnpm install, then pnpm build. The output lands in the dist directory, which you then load the same way as the manual install. There is also a pnpm dev script for development mode.

Configuration is the same in every path. Click the Nanobrowser icon in the toolbar to open the side panel, click the Settings icon in the top right, add your LLM API keys, and assign a model to each agent. The README lists OpenAI, Anthropic, Gemini, Ollama, Groq, Cerebras, Llama, and custom OpenAI-compatible providers as supported. Ollama is the notable entry there, since it means the whole loop can run against a local model with no external API call at all.

The Browser Support Boundary Is Harder Than It Looks

Chrome and Edge get full support. Firefox, Safari, and other Chromium variants including Opera and Arc are listed as not supported. The README softens this slightly by noting the extension may function on other Chromium-based browsers, but recommends Chrome or Edge for guaranteed compatibility.

Take the softener seriously as a warning rather than a reassurance. The extension depends on Chrome extension APIs and a side panel surface, and those are exactly the areas where Chromium derivatives diverge. An unsupported browser that mostly works is a worse position than one that clearly does not, because failures will appear as flaky agent behaviour rather than as an obvious incompatibility. If your team standardises on Firefox, Nanobrowser is simply not an option, and no amount of source patching changes that without a substantial port.

The second boundary is architectural. This is a browser extension driving a visible browser session. Nothing in the supplied material describes a headless mode, a server-side runner, or a way to schedule tasks. If your requirement is a nightly job that runs on a build machine with no human present, this is the wrong shape of tool regardless of how well the agent loop performs.

Where It Sits Against Playwright and Hosted Agent Products

Playwright is the obvious comparison point, and the README itself lists playwright among the repository topics. The difference is where the decision-making lives. A Playwright script encodes the path in advance: selectors, waits, click order. When a page changes, the script breaks and a human fixes the selector. Nanobrowser hands the decision to a model at runtime, so a layout change may be absorbed by the agent without a code change, at the cost of a non-deterministic run and a token bill per execution.

That trade is not universally favourable. For a stable internal form that you submit the same way every day, a Playwright script is faster, free after you write it, and reproducible. Nanobrowser earns its place when the target is a page you do not control, when the steps vary between runs, or when the value is in the reasoning rather than the clicking. Against hosted agent products, the difference is custody and cost model: they run the browser for you and charge a subscription, while Nanobrowser runs in your browser and charges you only what your provider charges for tokens. The README's own framing of that contrast is the price tag it attributes to OpenAI Operator.

Maintenance, Licence, and What the Release History Suggests

The licence is Apache-2.0, which permits commercial use, modification, and redistribution provided you preserve the licence and notices. That is a permissive arrangement, and for an extension you load unpacked into your own browser it removes most of the questions a legal review would raise. It does not remove them all. The README solicits sponsorship and links to a sponsor page, and the Chrome Web Store listing is under the project's control. If you fork and redistribute, you carry your own obligations around attribution. None of this is legal advice; read the licence text.

The release history is sparse and slightly irregular. v0.1.11 and v0.1.12 both landed on 2025-09-03, roughly two and a half hours apart, which reads like a quick follow-up fix rather than a planned pair. v0.1.13 followed on 2025-11-22, close to three months later. The repository shows a push in August 2026, well after the last tagged release, so commits are landing without a corresponding version bump. For an extension you install from the store, that gap matters less, since the store build tracks its own review cycle. For anyone building from source and pinning to a tag, it means the tagged code and the default branch have diverged for a long stretch.

The maintenance cost you should budget for is not the extension itself but the model configuration. Provider model names change, deprecate, and get repriced. The README's recommended pairings name specific models, and those names will age faster than the extension will. Plan to revisit the Settings panel when a provider retires a model, and prefer the custom OpenAI-compatible provider path if you want to point at a gateway you control rather than chase upstream naming.

Who Should Adopt It, and What to Check Before You Do

The case for adoption is strongest when three conditions hold at once. The automation target sits behind a session you are already authenticated into. You hold API keys for a provider the extension supports, or you run Ollama locally and want no external calls. And you are willing to treat the agent loop as code you own, reading the TypeScript when the README runs out of detail.

The case against is equally clear. Cross-browser requirements rule it out. Unattended or headless execution rules it out. Teams that need a support contract and a defined failure path should look at a hosted product instead, and accept the subscription as the price of that.

Before you commit, verify three things in the repository rather than the README. First, confirm which provider adapter your chosen model routes through, since the README lists providers but not the per-model mapping. Second, read the agent prompts and the Planner-to-Navigator message handling in the source, because that is where the self-correction behaviour described in the demo caption is actually implemented, and it is the part most likely to surprise you in a long run. Third, check whether the tag you intend to build from matches the default branch, given the gap between the last release and the most recent push. If you are installing from the Chrome Web Store, that third check is the store's problem, not yours.

Editorial conclusion

Adopt Nanobrowser if your automation targets live behind a logged-in browser session, you already hold API keys for a supported provider, and you want to read or patch the agent loop rather than rent it. Do not adopt it if you need Firefox or Safari, unattended headless runs, or a vendor SLA. Before committing, verify three things in the repository: which provider adapters your chosen model routes through, whether the agent prompts under the extension source are pinned to a version you can audit, and how the release cadence lines up with the API-key rotation policy on your team.

Official sources

1. License: Apache-2.0
2. nanobrowser/nanobrowser on GitHub
3. Project website
4. README
5. Releases