WebBrain: an AI agent that lives in the browser side panel
Open-source AI browser agent for Chrome and Firefox (monorepo) 🧠
At a glance
- What is it?
- WebBrain is a GPL-3.0-or-later browser extension for Chrome, Firefox and Edge that reads pages through the accessibility tree and runs multi-step tasks against a model you choose. Its real constraint is the model, not the extension: local setups need a 16k-token context window to work outside the Compact tier.
- Who is it for?
- Adopt WebBrain if you want an agent inside the browser you already use, and you are willing to run a local server or supply a cloud API key. Do not adopt it if you need unattended, headless automation in CI, or if your only hardware cannot serve a model with a 16k-token context window.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap WebBrain fills between a chatbot tab and a script
Most people who want AI help with a web page end up copying text into a chat window. That works for summarising an article and fails for anything with state: a form that needs filling, a table that needs reading across pagination, a download that needs triggering. The other end of the spectrum is a scripting framework such as Playwright or Selenium, which is powerful but requires you to write selectors and maintain them as the site changes.
WebBrain sits between those two. It is a browser extension that opens a side panel next to your tabs, reads the current page, and can act on it. The README describes it as an agent for "chatting with pages, automating tasks, and running multi-step workflows with your choice of LLM". The audience is someone who already has a browser open and wants the agent there, not in a separate terminal or a hosted dashboard. The three modes make the permission boundary explicit: Ask is read-only and can fetch URLs, Act can click, type, navigate, upload, download and fill forms, and Dev adds page source, styles, console, network and reversible page edits. That split is the product's main design decision. It means a user can keep the agent in a strictly observational role and only widen it when a task genuinely needs to change page state.
Accessibility tree instead of selectors, and a tool-use loop on top
The README states that WebBrain reads pages "via the accessibility tree rather than brittle selectors". That is the mechanism that separates it from scripted automation. A Playwright script targets a CSS or XPath selector; when the markup changes, the script breaks. The accessibility tree is the browser's own model of what is on the page in semantic terms, which is what screen readers consume. Reading through it means the agent sees a button as a button rather than as a div with a particular class. It is not a guarantee of stability, since accessibility trees vary in quality across sites, but it removes one common failure mode.
On top of that sits an autonomous tool-use loop. The README gives the ceiling as "configurable up to 195 steps (default 130), with a Continue button when it hits the limit". That number is worth pausing on. A 130-step default implies the agent is expected to run long sequences of tool calls, and the Continue button is an admission that the limit will be reached. For Act and Dev, there is a planning stage: the agent can generate a structured plan, show it for approval, and pin the approved plan to the scratchpad before any tool runs. That is a sensible ordering, because it means the user sees the intended sequence before the browser starts changing state.
Context management is handled by token-aware auto-compaction, tool-result limits and what the README calls emergency overflow recovery. For local servers, WebBrain auto-detects the real context window for llama.cpp, Ollama and LM Studio, and reads native server metadata before adding screenshots. When the optional Model field is left blank, the loaded-model capability is rechecked on every user turn, so a server-side model swap takes effect without restarting the extension.
Install paths: store, unpacked build, and the model server you point it at
There are two ways in. The store route covers Chrome, Firefox and Edge, with links to each listing in the README. The source route is documented in a collapsed section: clone the repository, then for Chrome open chrome://extensions/, enable Developer mode, 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 is explicit that temporary add-ons are removed when Firefox restarts, and that permanent installation requires signing through addons.mozilla.org. That is a Firefox platform rule, not a WebBrain limitation, but it shapes how you would use an unpacked build day to day.
The model side is where most of the configuration lives. WebBrain Compass 1.0 is the default and needs no API key or local setup. Local models also need no key; you point WebBrain at an OpenAI-compatible server. The README lists the commands: llama-server -m your-model.gguf --port 8080 for llama.cpp, ollama serve for Ollama on :11434/v1, vllm serve your-model --port 8000, and python -m sglang.launch_server --model-path your-model --port 30000. LM Studio on :1234/v1, Jan on :1337/v1, LocalAI on :8080/v1 and GPT4All on :4891/v1 are described as working the same way. A generic Local OpenAI-compatible Proxy card covers authenticated loopback gateways such as CLIProxyAPI.
The hard requirement is stated plainly: load a model with at least a 16k-token context window. 8k works only with the Compact tier, and 4k is too small for the system prompt plus tool schemas. That single sentence rules out a large number of small local models, and it is the first thing to check before installing. Cloud APIs are the other route, and the README lists OpenAI, Anthropic Claude, Google Gemini, Azure OpenAI, AWS Bedrock, Mistral, DeepSeek, xAI Grok, MiniMax, Kimi, Qwen, z.ai GLM, Groq, Together, Cloudflare, Nvidia NIM, Hugging Face, Fireworks and OpenRouter among others. Settings ships 106 built-in provider cards on Chromium and 105 on Firefox.
Where WebBrain is the wrong tool
The extension runs in a browser you are using. That is the point, and it is also the boundary. If you need automation that runs on a schedule with no human present, in a container, or as part of a CI pipeline, a browser extension is the wrong shape. WebBrain has /schedule and /watch commands for later and for polling a page, but the README does not describe a headless mode or a server-side runner. A Playwright or Puppeteer script deployed on a machine you control does that job without a desktop browser session.
The second boundary is hardware. The 16k-token context requirement is not a soft suggestion. A machine that cannot serve a model of that size locally has to fall back to a cloud API or to the managed default, and both of those mean your page content leaves the machine. For someone whose reason for choosing WebBrain was the offline-LLM topic tag, that is a real trade-off rather than a footnote.
The third is step count. A default ceiling of 130 steps with a Continue button suggests that long tasks will sometimes stall and need a human to resume them. That is a reasonable design for an interactive tool, and a poor fit for anything you wanted to run unattended. The README does not describe what happens to a half-completed task when the limit is hit beyond the Continue button, so the recovery behaviour is something to observe in your own use rather than assume.
How this differs from Playwright and from hosted browser agents
Playwright is the obvious comparison for anyone doing browser automation today, and the difference is in who defines the task. A Playwright script is deterministic: you write the steps, you own the selectors, and the same input produces the same sequence of actions. WebBrain inverts that. You describe the outcome and the model decides the steps, which is why the accessibility tree matters and why the step limit exists. The trade-off is reproducibility. A Playwright test that passes today will pass tomorrow unless the site changes; an agent run may take a different path each time. For verification and regression testing, that is a disadvantage. For one-off tasks on sites you do not control, it is the reason the tool exists.
Hosted browser agents take the opposite approach again: they run the browser for you, usually in a cloud environment, and you interact through their interface. WebBrain keeps the browser on your machine and the model configurable, which is what makes the local llama.cpp and Ollama paths possible at all. The cost is that you are responsible for the model server, its context window, and its availability. The README's note that a blank Model field triggers a capability recheck on every user turn is a small but telling detail: it assumes the server underneath may change while the extension is running.
Maintenance, release cadence and the licence question
The repository shows recent releases v36.0.4 and v36.0.1 on 2026-09-10 and 2026-09-09, with v34.1.6 on 2026-09-04. The version numbers move in large jumps, and the release history visible here covers only a few days, so the cadence over a longer period cannot be judged from this material alone. What can be said is that the project is not archived and the last push matches the most recent release.
The licence needs attention before adoption. The README links to LICENSE with the label GPL-3.0-or-later, while the repository metadata reports NOASSERTION. Those two signals disagree, and the difference matters if you plan to redistribute the extension or bundle it into a product. Read the LICENSE file itself rather than relying on either label. This is not legal advice, and if the distinction affects a commercial plan, it is a question for a lawyer.
Upgrade cost is mostly on the model side rather than the extension side. Because WebBrain supports OpenAI-compatible endpoints generically, swapping the model behind it does not require changing the extension. The friction is in the context window: a model that fits the 16k requirement today may be replaced by one that does not, and the Compact tier is the fallback when it does not. The provider catalog is large and changes between Chromium and Firefox (106 cards versus 105), which suggests per-browser capability differences worth checking before you assume a given provider is available on your browser.
Who should install it, and what to check first
WebBrain suits someone who wants an agent in the browser they already use, on a machine that can serve a model with a 16k-token context window, or who is willing to pay for a cloud API instead. The Ask mode alone is useful and carries no write risk, so a cautious first install can stay read-only while you judge whether the page reading is good enough on the sites you care about. The saved workflows feature, which turns a successful run into a reusable and exportable workflow, is the natural next step once a task has worked once.
It does not suit anyone who needs headless execution, container-based automation, or unattended runs in CI. Those requirements point at Playwright or Puppeteer, where you write the steps and control the environment.
Before installing, check three things. First, confirm your local model's context window is at least 16k, because 8k limits you to the Compact tier and 4k will not fit the system prompt plus tool schemas. Second, read the LICENSE file directly, since the README says GPL-3.0-or-later while the repository metadata says NOASSERTION. Third, if you are pointing WebBrain at a local server, verify the port matches what the README lists for your runtime (8080 for llama.cpp, 11434 for Ollama, 1234 for LM Studio) and that the server exposes an OpenAI-compatible endpoint, because that compatibility is the only integration contract the extension relies on.
Editorial conclusion
Adopt WebBrain if you want an agent inside the browser you already use, and you are willing to run a local server or supply a cloud API key. Do not adopt it if you need unattended, headless automation in CI, or if your only hardware cannot serve a model with a 16k-token context window. Before installing, verify the licence file, because the repository reports NOASSERTION while the README links GPL-3.0-or-later, and check that your chosen local server exposes an OpenAI-compatible endpoint on the port WebBrain expects.
Community notes