WebBrain: an open source AI browser agent that runs on the model you choose

What WebBrain does that a chat tab cannot

A chat window can tell you what a page probably says. It cannot click the Search button on it. WebBrain is built for that gap: the README describes it as a web browser extension that puts an AI agent in a side panel next to your tabs, so the agent reads the page you are already looking at and, when you allow it, acts on that page. The intended user is someone who spends the day in a browser and wants the agent to share the same session, cookies and login state rather than a scraped copy of the DOM. The README gives four example prompts: summarizing a page, finding links about pricing, filling a search box and clicking Search, and navigating to github.com to find trending repositories. Those examples set the scope. This is a tool for reading and operating pages a person is already looking at, not a scraping framework and not a headless test runner.

Ask, Act and Dev: the permission model is the architecture

WebBrain splits capability into three modes, and the split is the most consequential design decision in the project. Ask is read-only: it reads the page, answers questions and fetches URLs. Act adds clicks, typing, navigation, uploads, downloads and form filling. Dev adds page source, styles, console, network, and reversible page edits. That ordering means a user can get value from the extension without ever granting it the ability to submit a form. The README also states that Act and Dev can generate a structured plan, show it for approval, and pin the approved plan to the scratchpad before any tool runs, and that consequential actions trigger per-site permission prompts.

Perception runs through the accessibility tree rather than CSS selectors, according to the README, which is why it claims to read text, links, forms, tables, PDFs and interactive elements with the same code path. The agent loop itself is a tool-use loop, configurable up to 195 steps with a default of 130 and a Continue button when the limit is reached. Context is managed rather than assumed: the README describes token-aware auto-compaction, tool-result limits and emergency overflow recovery. Each tab keeps its own conversation history, with optional local user memory for stated preferences.

Installing WebBrain from source and running a first task

The README lists three store links, for Chrome, Firefox and Edge. Loading from source is documented as a separate path, and it is a plain clone with no build step mentioned for the extension itself.

git clone https://github.com/webbrain-one/webbrain.git

For Chrome, the README says to open chrome://extensions/, enable Developer mode in the top right, click Load unpacked, and select the webbrain/src/chrome folder. For Firefox, open about:debugging#/runtime/this-firefox, click Load Temporary Add-on, and select src/firefox/manifest.json. The README warns that temporary add-ons are removed when Firefox restarts and that permanent installation requires signing through addons.mozilla.org, so the source path is a development workflow on Firefox rather than a deployment one.

Once the panel is open, click the WebBrain icon and type a request such as summarizing the current page, or asking it to fill in the search box with a phrase and click Search. The README documents slash commands for the longer-running behaviours: /schedule for later and /watch to poll a page and act when a condition is met. A successful run can be turned into a saved workflow that you can re-run, export and share, which the README describes as value-free, meaning the recorded workflow does not carry your specific values with it.

Pointing WebBrain at a local model

The default is WebBrain Compass 1.0, which the README says needs no API key or local setup. The alternative is any OpenAI-compatible server, and the README gives the launch commands for several of them.

llama-server -m your-model.gguf --port 8080          # llama.cpp
ollama serve                                          # Ollama  → :11434/v1
vllm serve your-model --port 8000                     # vLLM    → :8000/v1
python -m sglang.launch_server --model-path your-model --port 30000

The README also names LM Studio on :1234/v1, Jan on :1337/v1, LocalAI on :8080/v1 and GPT4All on :4891/v1 as working the same way, plus a generic Local OpenAI-compatible Proxy card for authenticated loopback gateways. The constraint that matters is context: the README states you should load a model with at least a 16k-token context window, that 8k works only with the Compact tier, and that 4k is too small for the system prompt plus tool schemas. WebBrain auto-detects the real window for llama.cpp, Ollama and LM Studio and auto-compacts as the conversation fills. For those same servers plus LocalAI it reads native server metadata before adding screenshots, with Auto, Force on and Off overrides in Settings. If the optional Model field is left blank, the loaded-model capability is rechecked on every user turn, so a server-side hot swap takes effect without restarting the extension. There is also a preview handoff documented as ollama launch webbrain --model <model>.

Where WebBrain is the wrong tool

The extension model is also the limitation. WebBrain runs where a browser runs, so anything you want to happen without a person present, on a server, in CI, or across hundreds of pages in parallel, sits outside what the README describes. The scheduled and watched tasks are a partial answer for recurring checks inside a browser session, not a replacement for a job runner.

Local inference has a hard floor. The README is explicit that a 4k-token context is too small for the system prompt plus tool schemas, which means small models that look attractive for a laptop will not complete a tool-use turn no matter how fast they are. The step ceiling is real too: the loop is configurable up to 195 steps, default 130, and the README's answer when the agent hits that limit is a Continue button, which is a human in the loop by design. If you want an agent to grind through a long workflow unattended, that button is a stopping point, not a feature. And on Firefox, loading from source gives you a temporary add-on that vanishes on restart, so the source route is not a stable daily driver there.

How WebBrain differs from Playwright-style automation

The closest comparison is a browser automation library such as Playwright. The difference is where the instruction lives. With Playwright you write a script that encodes each step, and the script is the source of truth; when the page changes, the script breaks and you fix the selector. WebBrain inverts that. The instruction is a sentence in a side panel, the agent decides the steps at run time, and the accessibility tree gives it a representation of the page that survives markup changes better than a CSS selector does. The trade-off is determinism. A script does the same thing every time and can be reviewed line by line before it runs; an agent's path is chosen per run. The README's answer to that is the plan approval step in Act and Dev, the per-site permission prompts, and the saved workflow, which converts one successful run into something repeatable. If your task is stable and your environment is headless, Playwright is still the right tool. WebBrain is for tasks where the target page is unknown in advance or changes often enough that writing selectors is the expensive part.

Licence, maintenance and the cost of upgrading

The repository metadata reports the licence as NOASSERTION, while the README links to LICENSE under the label GPL-3.0-or-later and the repository carries a LICENSES/ directory alongside LICENSE. That mismatch is worth resolving before you build on the code, and it is a question for whoever handles licensing in your organisation rather than one this article can settle. The practical shape of GPL-3.0-or-later, if that is what applies, is that distribution of a modified version carries source obligations, and since WebBrain is a browser extension that users install, distribution is easy to do by accident.

On maintenance, the last push to the default branch was on 2026-09-10, and the most recent release listed is v36.0.4 from the same day, with v36.0.1 the day before and v34.1.6 on 2026-09-04. The version in package.json is 36.2.0. The release cadence visible in those three entries is fast, and the CHANGELOG.md at the repository root is the place to read what changes between them. Upgrading a browser extension is mostly automatic for store installs, but the parts that can break are the ones you configured: a provider card, a local server port, or a model whose context window no longer satisfies the 16k requirement. The test scripts in package.json, including test:provider-limits and test:security, indicate the project tests provider limits and prompt injection, but the README does not document a rollback path for a bad extension update.

Editorial conclusion

Adopt WebBrain if you want an agent that lives in the browser side panel and you care about which model answers, whether that is a local llama.cpp or Ollama server or a cloud API. Skip it if you need unattended automation on a headless machine, since the README describes a browser extension and not a server-side runner, and temporary Firefox add-ons disappear on restart. Before rolling it out, verify that your chosen model reports at least a 16k-token context window, because the README states 4k is too small for the system prompt plus tool schemas, and check the LICENSE and LICENSES/ directory, since the repository metadata reports NOASSERTION while the README links GPL-3.0-or-later.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. webbrain-one/webbrain on GitHub