Skyvern vs Browser Use, and the question both comparisons skip: where does the agent stop?

It comes down to how you want to ship. Browser Use is an MIT-licensed Python library you import into your own codebase and drive with your own LLM keys; it is the better fit when you are building agents into an application and want full control with the most permissive license. Skyvern is AGPL-3.0 and ships as a platform with a no-code workflow builder and a managed cloud, plus computer-vision page understanding that reads a page visually rather than only through the DOM; it is the better fit when non-developers need to record and run workflows without writing Python, or when you want a hosted runtime instead of self-managed browser infrastructure. The AGPL license matters if you plan to embed Skyvern in a closed-source product, because AGPL obligations reach networked use. Both are strong inside their lane. The lane is the browser tab.

Less than the marketing suggests. Both drive a real Chromium instance, both call an LLM to decide the next action, and both ultimately speak the Chrome DevTools Protocol to one browser context. Skyvern leans harder on computer vision to interpret the rendered page and bundles a workflow layer on top; Browser Use leans on the accessibility and DOM tree of the page and stays a lean library. But the transport is the same family, and so is the boundary. Neither can act on a window that is not the browser, because CDP has no concept of the desktop around the browser.

A browser agent can see and act on anything inside a browser tab: inputs, buttons, links, ARIA regions, the rendered pixels. The moment an interaction leaves the tab, it leaves the agent's world. Clicking Attach opens the native OS file picker, which is a separate window owned by the operating system, not a DOM node. Printing to PDF, an OS sign-in prompt, the downloads bar, a desktop policy-admin app, SAP GUI, a Citrix session, a mainframe terminal: none of these are reachable through CDP. For a workflow that lives entirely inside one modern web app, this never bites. For most enterprise back-office workflows, it bites on step three. That is why the edge, not the star count, is the dimension that decides which tool survives in production.

Mediar's open Terminator runtime binds to the operating system accessibility tree, the same interface a screen reader uses: Microsoft UI Automation on Windows. That tree exposes the browser DOM and the desktop around it through one selector schema. When a recorded step lands inside Chrome, the runtime dispatches it as a fast browser script (the prefer_browser_scripts flag defaults to true in apps/desktop/src-tauri/src/mcp_converter.rs). When the click target leaves the browser process, the same converter returns None at line 862 and the executor falls through to UI Automation on the same workflow line. One file, two execution layers, no second tool and no human hand-off. You can clone github.com/mediar-ai/terminator and grep for that fall-through yourself.

No, and we will say so on a call. If your highest-volume workflow runs entirely inside one or more web apps, never opens a file picker, never crosses to Excel for a calculation, never touches a desktop tool, and never logs into a thick client, then a browser agent is the lighter, faster choice. Browser Use is excellent for embedding in code; Skyvern is excellent for hosted no-code web workflows. Mediar earns its place the moment a workflow crosses the browser window edge even once, which is the common case in finance, insurance, banking, and healthcare back offices.

No. Computer vision changes how Skyvern interprets the rendered page, not what surface it can act on. The capture and the action both run through the browser context. A screenshot of the screen is not the same as having an automation handle on an OS window. To click an item in the native file picker you need an OS-level automation API (UI Automation on Windows), which is a different binding than anything a browser agent ships with. Vision helps Skyvern read messy pages; it does not extend the boundary past the tab.

Browser Use is MIT, which is the most permissive of the common open-source licenses and the easiest to embed in a closed-source commercial product. Skyvern is AGPL-3.0, whose copyleft obligations extend to software accessed over a network, so building a hosted product on a modified Skyvern can trigger source-disclosure obligations; many teams use Skyvern's managed cloud specifically to sidestep that. Mediar's Terminator runtime is open source at github.com/mediar-ai/terminator, and the commercial product is sold as a turn-key program rather than per-seat licensing. Read each license yourself before you build a business on it; this is a summary, not legal advice.

Yes, and some teams do exactly that during a migration. Mediar reaches the browser through the accessibility tree too, so it can run the whole workflow, but there is no rule that you rip out a working browser agent. A common pattern is to let the existing browser agent own the pure-web stretch and let Mediar own the steps that cross into the file picker, the desktop admin app, or the green-screen terminal, then consolidate once the desktop coverage proves out. We would rather you migrate the painful steps first than do a big-bang rewrite.