Browser Use teilt sich in einen Agenten und einen gemieteten Browser
Zusammenfassung
Die eine Hälfte nimmt eine Aufgabe und liefert ein Ergebnis, die andere vermietet dem eigenen Playwright-Code einen entfernten Browser mit getarntem Profil. Die offene Bibliothek steht unter MIT-Lizenz, abgerechnet wird pro Stunde und pro Verbrauch statt im Abo.
Empfehlen- Name
- Browser Use
- Version
- 0.02
- Open Source
- Open Source
- Betriebssystem
- WebLinuxmacOSWindows
- Webseite
- https://browser-use.com/
- Aktualisiert
- 2026-10-06 21:19
Einem Agenten den Browser zu überlassen ist eine Idee, die Browser Use früh aufgegriffen hat, und das Projekt ist weiter gekommen als die meisten. Der Slogan ist so schlicht wie möglich: Agenten, die den Browser benutzen. Danach teilt sich das Produkt. Browser Use Agents nimmt eine Aufgabe und gibt ein Ergebnis zurück. Browser Infrastructure vermietet einen entfernten Browser an den eigenen Agenten. Die zwei Knöpfe oben folgen dieser Teilung, einen Agenten starten und einen Browser öffnen, dazu eine Sternenzahl von 115 000 in der Ecke.

Ein Maßstab, der Erfolg und Kosten zusammen misst
Die auffälligste Zahl stammt aus einem selbst gebauten Maßstab. Über 106 Aufgaben meldet das Projekt eine Erfolgsquote von 82 Prozent bei 17 Cent pro Aufgabe. Die Vergleichszeilen nennen drei Spitzenmodelle bei 62, 59 und 59 Prozent, mit Kosten je Aufgabe von 3.40, 1.55 und 2.20 Dollar.
Entscheidend ist, was hier gemessen wird. Die Seite nennt es Erfolg über 106 Aufgaben zusammen mit den Kosten pro gelöster Aufgabe, und das ist eine andere Frage als der Preis eines einzelnen Aufrufs. Ein billiges Modell, das die Hälfte verfehlt, ist teuer, und ein Maßstab, der das ignoriert, ist eine Preisliste, die sich als Bewertung ausgibt.
Die Seite des entfernten Browsers hat eigene Zahlen: Bei einer Reichweitenmessung über 71 geschützte Seiten meldet das Projekt 81 Prozent gegen 77, 67 und 47 Prozent bei drei anderen Diensten. Beide Sätze stammen aus selbst gebauten Maßstäben mit eigener Auswahl an Stichproben und Vergleichen, und die vernünftige Lesart ist deshalb, dass ein Käufer gegen die eigenen Zielseiten testen sollte.
Die Vorführung ist konkreter. Die Seite spricht von 42 Aufzeichnungen echter Läufe, mit Aufgaben wie zwei nebeneinanderliegende Kinoplätze finden, einen Abholwagen in einem Baumarkt füllen, Ergebnisse eines Portals als CSV ausgeben, eine Qualitätsprüfung über eine Website laufen lassen, nach einem laufenden Brett Schach spielen, Browseraufgaben in einem Chat-Arbeitsbereich ausführen und 100 Zeilen Tetris abräumen.
Drei Wege hinein, von der Cloud bis lokal
Die Anleitung teilt die Nutzung in drei. Vollständig verwaltete Cloud, wo man den gehosteten Agenten aufruft und er den Browser führt, mit getarntem Browser, Profilen, Aufzeichnungen und einer Datenrichtlinie darunter. Ein Weg über die Kommandozeile, bei dem man eine Anweisung in den eigenen programmierenden Agenten gibt, der das Werkzeug einrichtet und den eigenen Browser verbindet. Und die Python-Bibliothek, die den offenen Agenten im eigenen Code laufen lässt, Python 3.11 oder neuer verlangt und nur eine Installation und einen Modellschlüssel braucht. Die Beispielaufgabe ist, die Sternenzahl eines Repositories nachzusehen; danach öffnet der Agent einen Browser, findet die Antwort und gibt sie aus. Das Modell darf von Dritten oder vom Projekt selbst kommen, der Browser lokal oder in der Cloud laufen.

Zwei Cloud-Wege, und eine Art, Geld zu verbrennen
Die Dokumentation trennt die Cloud-Seite in zwei Produkte, beide auf der vierten Version der API. Browser Use Agents ist der Fall, in dem man die Aufgabe liefert und es den Browser führt. Browser Infrastructure ist der Fall, in dem vorhandener Playwright- oder Puppeteer-Code über CDP an einen gehosteten Browser andockt, was zu Teams passt, die schon Automatisierungscode haben und nur ändern wollen, wo er läuft.
Eine Falle verdient Wiederholung, weil sie echtes Geld kostet: Das Trennen der CDP-Sitzung stoppt den gehosteten Browser nicht. Die Sitzung muss am Ende ausdrücklich beendet werden, sonst läuft der Zähler weiter. Das Cloud-SDK braucht Python 3.10 oder neuer; mit Schlüssel sind Aufgabe anlegen, auf Abschluss warten und Ergebnis holen drei Zeilen Kerncode.

Preise: nach Verbrauch, kein Abo
Guthaben beginnen bei 5 Dollar, es gibt kein Abo, und sie verfallen nicht. Ein Browser kostet 0.02 Dollar pro Stunde plus Verkehr. Browser Use Agents berechnet die Modellkosten plus 20 Prozent und legt Browserzeit und Verkehr obendrauf. Neue Anmeldungen, die die Bedingungen erfüllen, erhalten 15 Dollar Guthaben.
Liest man die Struktur statt der Zahlen, erscheinen zwei Produkte. Wer den gehosteten Browser nur nutzt, um eigenen Playwright-Code laufen zu lassen, zahlt ungefähr das, was eine stundenweise gemietete Maschine mit Tarnung und Vermittler kostet. Wer den Agenten arbeiten lässt, kauft Modellmarken mit zwanzig Prozent Aufschlag. Beides ist kein Abo, was bedeutet, dass ruhige Monate nichts kosten und ein geschäftiger Monat teurer werden kann als ein Tarif.
Die offene Seite hat eigene Zahlen: rund 115 000 Sterne, 23,1 Millionen Downloads im Monat, MIT-Lizenz, 366 Mitwirkende und 137 Veröffentlichungen, fast vollständig in Python. Das Projekt sagt ausdrücklich, dass es in der Cloud oder auf der eigenen Maschine läuft, und die Lizenz ist der Grund, warum dieser Satz glaubwürdig ist.
Für wen es passt
Drei Gruppen. Kleine Teams, die wiederkehrende Web-Abläufe automatisieren müssen und die eigene Arbeit an Bot-Abwehr und Captchas lieber vermeiden, was genau das ist, was die Reichweitenzahl verkauft. Engineering-Teams mit bereits geschriebenen Playwright-Abläufen, die nur die Ausführungsumgebung in die Cloud verschieben wollen und deshalb den Infrastrukturweg mit minimaler Änderung nehmen. Und Entwickler, die Browsersteuerung als Werkzeug für den eigenen Agenten anbieten wollen, wofür Kommandozeile und MCP-Richtung Einstiege haben.
Was die zwei Glanzzahlen sagen können und was nicht
Beide Zahlen sind selbst berichtet, auf Maßstäben, die der Anbieter entworfen hat. Das macht sie nicht falsch, begrenzt aber, was sie beweisen. Eine Erfolgsquote über 106 Aufgaben sagt, dass das Projekt bei der Art von Aufgabe kompetent ist, die seine Autoren gewählt haben. Sie sagt nicht, was auf der Seite passiert, die einen wirklich interessiert, mit dem Konto, das man wirklich hat, in dem Moment, in dem eine Bot-Prüfung auftaucht.
Dieselbe Vorsicht gilt für die Kosten pro gelöster Aufgabe, und die ist die interessantere der beiden, weil sie Misserfolge in den Preis einrechnet. Diese Rechnung ist richtig, heißt aber auch, dass die Zahl mit der Aufgabenmischung wandert: eine Reihe leichter und eine Reihe feindlicher Aufgaben ergeben aus demselben System sehr verschiedene Werte.
Zwei ehrliche Anmerkungen
Erstens stammen beide eindrucksvollen Vergleiche aus eigenen Maßstäben des Projekts, also vor der Entscheidung gegen die eigenen Zielseiten testen. Zweitens ist die Falle bei der Abrechnung das praktische Risiko der Cloud-Produkte: Eine verlassene Sitzung rechnet weiter, deshalb sollte die Arbeit in etwas eingewickelt sein, das sie auch bei einem Fehler im Code beendet.
Die eigentliche Schwelle für einen Browser-Agenten ist nie, ob er einen Knopf drücken kann, sondern ob er nach einer Sperre durch die Zielseite noch zurückfindet.