browser-use gehört zu den meistdiskutierten Browser-Agenten-Bibliotheken der letzten zwei Jahre: Man beschreibt die Aufgabe in einem Satz, und das Werkzeug öffnet selbst einen Browser, liest Seiten, klickt Schaltflächen und füllt Formulare aus, bis das Ergebnis vorliegt. Das klingt nach dem Endpunkt der Automatisierung. In der Praxis gleicht es einem klugen Praktikanten, der pro Schritt abrechnet: leistungsfähig, aber durchaus in der Lage, in jede Grube unterwegs zu treten.
Informationen zum offiziellen Repository
Das Projekt liegt auf GitHub, Organisationsname browser-use, Repository ebenfalls browser-use, MIT-Lizenz, in Python geschrieben und mit weit über hunderttausend Sternen. Darunter steuert Playwright einen echten Browser, während eine Agenten-Schleife die Seite versteht und den nächsten Schritt entscheidet. Anbindbar sind Modelle von OpenAI, Anthropic, Google und anderen, auch lokale Modelle gehen. Das Team verkauft zusätzlich einen gehosteten Cloud-Browser, das ist ein separates Angebot; das Self-Hosting der Bibliothek selbst kostet nichts.
Die Arbeitsweise ist die Abrechnung
Jeder Schritt läuft so: Die Struktur der aktuellen Seite wird als Text an das Modell gegeben, das Modell entscheidet, wohin geklickt oder was getippt wird, die Aktion läuft, und die Schleife betrachtet die neue Seite. Eine scheinbar simple Aufgabe, etwa Preise auf mehreren Seiten vergleichen und eine Tabelle füllen, verbraucht mühelos zwanzig bis dreißig Schritte, also zwanzig bis dreißig Modellaufrufe. Mit einem Spitzenmodell kann eine Aufgabe eine Größenordnung teurer werden als geschätzt; mit einem billigen Modell wächst die Schrittzahl durch schlechtere Entscheidungen gleich wieder mit. Ehrlich spart nur, wer die Kosten pro Aufgabe an einem echten Job misst, bevor er skaliert.
Bereitstellung: leicht installiert, schwer am Leben zu halten
Lokal ist der Einstieg anspruchslos: Python-Umgebung plus Playwright und Browser genügen, beim ersten Mal geht es vor allem um Downloads und Abhängigkeiten. Die Daueraufgabe ist der Betrieb: Headless-Browser auf Servern brauchen Umgang mit Schriften, Pop-ups, Zeitüberschreitungen und Speicher, und ein einziger Website-Umbau kann eine Aufgabe brechen, die gestern noch lief. Jemand muss also weiter hinschauen und reparieren. Als Einmal-Skript ist das alles egal, als Produktivsystem gehört Personal wie für einen Dienst dazu.
Vier echte Fallstricke
Erstens Login-Wände und Captchas. Seiten mit Anmeldung, SMS-Codes oder Menschenprüfung lassen den Agenten regelmäßig stecken; den eingeloggten Zustand des eigenen Browsers zu übernehmen umgeht einen Teil davon, setzt aber das Konto einem automatisierten Programm aus, auf eigenes Risiko. Zweitens Prompt-Injektion über Webseiten. Seitentext wird zum Kontext des Modells, und eine feindliche Seite kann es zu falschen Klicks oder zum Preisgeben anvertrauter Informationen verleiten; Zahlungs- und Kontoaufgaben gehören isoliert. Drittens schwankende Erfolgsquoten. Dieselbe Aufgabe läuft heute und scheitert morgen, was unbeaufsichtigte Durchläufe bei Bestellungen oder Anmeldungen ohne Wiederholung ausschließt. Viertens Tempo. Jeder Schritt wartet auf das Modell, Minuten pro Aufgabe sind normal, und im Stapel wachsen Zeit und API-Rechnung gemeinsam.
Es passt zu Arbeit, deren Ablauf sich ständig ändert und nicht als Skript einfrieren lässt: Wettbewerbsbeobachtung, Formularübertragungen, Seiteninhalte in strukturierte Daten verwandeln, mit einem Menschen, der Ergebnisse prüft. Für feste Abläufe sind ein handgeschriebenes Playwright-Skript oder klassisches RPA billiger und ruhiger.
