Why Browser Use's Founder Just Open-Sourced an Anti-Framework

On April 18, 2026, Gregor Zunic posted four lines that effectively retired his own product.

Introducing: Browser Harness. A self-healing harness that can complete virtually any browser task. We got tired of browser frameworks restricting the LLM. So we removed the framework.

Greg is the co-founder of Browser Use, the company whose name became a verb in the agent ecosystem. “Use Browser Use” is how people on X described half the AI shopping bots, research assistants, and account-creation scripts shipped in 2025. The framework was the category.

Then the founder open-sourced the thing that replaces it.

This wasn’t a feature launch. It was a public bet that the architecture that built the company is the wrong architecture for what comes next.

What Browser Use Was

To understand the pivot, you have to understand what Browser Use was solving for in 2024.

Models at the time couldn’t be trusted to drive a browser end-to-end. They lost the page state. They hallucinated selectors. They tried to click elements that weren’t visible. The whole agent space was scaffolding around model limitations.

Browser Use was the cleanest version of that scaffolding. A structured Agent class. An action registry. A planner-executor split. Vision-based recovery for when DOM selectors failed. Retry policies, timeout handling, browser context management — all wrapped in a Python SDK you could pip install and use in an hour.

It worked because it carried the burden the model couldn’t. The framework knew what a browser was. The model just had to fill in the high-level steps.

That trade-off is what made Browser Use the default. And it’s what made it suddenly obsolete.

What Changed in 18 Months

Three things shifted, fast.

Tool use got reliable. Claude 4 and GPT-5 follow tool schemas without the validator layer that 2024 frameworks needed. The model returns well-formed calls. You don’t need a parser catching malformed ones.

Context windows blew open. A 1M-token window means the agent can load the entire page, the entire helpers file, the entire conversation history — and re-read. The pre-chunking and state-management gymnastics that framework code did all evaporated.

Models learned to recover from errors. When a click misses, a 2026 model edits the helper, writes a new selector strategy, or just changes approach. That recovery logic used to be hand-coded framework behavior. Now it’s emergent from the model.

Once those three are true, every abstraction layer between the LLM and the browser is a liability. It’s framework code you have to maintain, that the model has to work around, that breaks when the task drifts off-pattern.

Greg saw it before his customers did. Probably because he was using Claude Code every day to write Browser Use itself, and watching what a real harness felt like from the inside.

What Browser Harness Actually Is

Browser Harness is roughly a few hundred lines of Python. There is no Agent class. There is no action registry. There is no planner.

There is a websocket to Chrome via the Chrome DevTools Protocol. There is a helpers.py file the LLM is allowed to edit. There is a CLAUDE.md or AGENTS.md describing how to use the helpers.

That’s the whole product.

You drop it into a Claude Code or Codex session. The LLM reads the helpers file, figures out what’s available, calls the helpers via the harness’s tool interface, and edits the file when something doesn’t work. When a selector breaks, the LLM rewrites the helper. When a flow doesn’t exist, the LLM writes one. The codebase grows as the agent encounters new sites.

This is what Greg means by “self-healing.” There’s no error handler. The error is the trigger. The model is the handler.

Compare the shapes side by side:

Browser Use (framework)	Browser Harness (harness)
Agent class with planner + executor	LLM in Claude Code / Codex
Action registry of pre-defined ops	helpers.py, LLM-editable
Vision fallback when DOM fails	LLM edits selector strategy
Retry logic baked in	LLM decides whether to retry
~100k LOC	A few hundred LOC
Maintained by the framework team	Maintained by the LLM, at runtime

The shift isn’t subtle. It’s the inversion of who owns the logic. In the framework world, the framework owns it and the model fills in the variables. In the harness world, the model owns it and the harness just exposes the tool.

Why the Founder Killed His Own Framework

Most companies don’t kill their flagship while it’s still growing. They milk it until a competitor forces the issue.

Browser Use didn’t have that competitor yet. The market was still mostly framework-shaped. Greg shipped the anti-framework anyway.

The explanation isn’t strategy. It’s product instinct. Once you’ve used a real harness — Claude Code, Codex agent mode — going back to a framework feels like driving a car with the parking brake on. The framework’s “helpfulness” becomes the bottleneck. You can feel the model wanting to do the thing the framework won’t let it do.

You can’t unsee it. So you ship the thing that replaces it, even if the thing it replaces is yours.

There’s also a defensive angle. If Browser Use doesn’t ship the harness, someone else does — probably a hobbyist forking the framework’s CDP code and gutting the rest. Better to be the company that made the transition than the one that resisted it.

The Bigger Pattern: Framework to Harness

Browser Use isn’t the first. It’s the most visible.

• Anthropic built Claude Code with no framework. Just Bash, Read, Edit, Write, Grep. The framework didn’t exist; the harness was the whole product.
• OpenAI shipped Codex on the same shape. Tools, sandbox, the model figures it out.
• Cursor added agent mode, which is functionally a harness layered over the editor.
• Karpathy did it with research — his autoresearch pattern is just program.md + Claude Code, no agent framework anywhere.
• Browser Use is the latest. The first major framework company to publicly retire its own framework in favor of the harness shape.

The pattern is now obvious enough to name. Framework-to-harness migration is the dominant architectural move of 2026 in AI tooling.

Which means the harness shape is everywhere by end of year:

• Coding harnesses (already here)
• Browser harnesses (just arrived)
• Research harnesses (Karpathy)
• Data harnesses (DB + shell, emerging)
• Design harnesses (Figma + LLM, early)
• Ops harnesses (kubectl + LLM, early)

If you’re building an AI tool in 2026 and your product is a framework — Greg just gave you the playbook for the next 12 months.

What Builders Should Take From This

Three things.

Stop building frameworks. If you’re writing scaffolding around an LLM, you’re writing the thing the next model release will make obsolete. Build the tool surface, not the orchestrator.

Invest in the working directory. A harness is only as good as the files it can read. CLAUDE.md, AGENTS.md, helpers, reference docs, knowledge folders — these are where the actual advantage lives. The harness is free. The context library isn’t.

Watch where the agent edits. When a model in Claude Code starts editing helpers.py, you’ve crossed from “AI using a tool” to “AI maintaining its own toolchain.” Browser Harness institutionalizes that loop. Every harness shipped in 2026 will too.

The framework era was about building the rails the model couldn’t lay itself. That era ended quietly somewhere in early 2026. Greg just made it official.

---

Where Save Fits

Every harness reads Markdown from disk. The helpers it edits, the docs it consults, the reference pages it grounds against — all sitting in a folder the agent can grep.

Save is the one-click converter from any webpage to clean Markdown. Documentation pages, GitHub READMEs, API references, Stack Overflow threads, Greg’s blog posts about why he killed his own framework — whatever the next harness you run will need to read.

The harnesses are open source. The context library is what makes one agent better than the next.

---

Save turns any webpage into Markdown your AI harness can read — install the extension and start building the library that makes your agents smarter.