notte: Cloud-Browser und SDK für Web-Agenten, mit SSPL als Preisfrage

Welche Lücke notte im Werkzeugkasten schließt

Wer heute einen Agenten baut, der echte Websites bedient, steht vor zwei unangenehmen Optionen. Entweder schreibt man jeden Schritt als Selektor-Skript, das bei der nächsten Layout-Änderung bricht. Oder man überlässt dem Modell die komplette Steuerung und zahlt für jeden Klick einen Token-Betrag, inklusive der Fehler, die das Modell dabei macht. notte positioniert sich zwischen beiden Lagern. Der README beschreibt das Ziel als Kombination aus KI-Agenten und traditionellem Skripting, wobei deterministische Teile als Skript laufen und das Modell nur dort eingesetzt wird, wo es gebraucht wird. Die Zielgruppe sind Entwickler, die wiederkehrende Web-Aufgaben in eine Python-Anwendung einbetten wollen: Formulare ausfüllen, Listen extrahieren, Konten anlegen. Wer nur eine einzelne Seite scrapen will, braucht das Framework nicht.

Session, Agent und Modell: der Datenfluss im SDK

Das Modell ist eine Session, in der ein Agent läuft. Eine Session kapselt einen Browser, wahlweise headless oder mit sichtbarem Fenster, und der Agent bekommt diese Session zusammen mit einem reasoning_model übergeben. Der Agent erhält eine Aufgabe in natürlicher Sprache und eine Obergrenze für Schritte, im Beispiel max_steps=30. Aus der README-Beispielstruktur ergibt sich der Ablauf: Session öffnen, Agent konstruieren, run mit task aufrufen, Antwort entgegennehmen. Die Antwort ist ein Objekt mit einem answer-Feld. Für die Datenextraktion lässt sich run zusätzlich ein response_format mitgeben, das eine Pydantic-Klasse ist. Der Agent liefert dann Werte in genau dieser Struktur, im Beispiel eine Liste von Hacker-News-Beiträgen mit Titel, URL, Punkten, Autor und Kommentarzahl. Das ist der architektonisch interessanteste Teil: Die Modellausgabe wird nicht als Freitext zurückgegeben und anschließend mit regulären Ausdrücken zerlegt, sondern gegen ein Schema validiert. Wer schon einmal versucht hat, aus einer Modellantwort verlässlich eine Zahl zu ziehen, weiß, warum das relevant ist.

Lokaler Modus gegen gehosteten Dienst

notte lässt sich auf zwei Wegen betreiben, und der Unterschied ist nicht nur eine Zeile Import. Im lokalen Modus importiert man notte und öffnet eine notte.Session. Laut README braucht man dafür eigene LLM-API-Schlüssel, als Beispiel ist gemini/gemini-2.5-flash genannt. Der Browser läuft auf der eigenen Maschine, die Installation erfolgt über pip install notte und patchright install --with-deps chromium. Der gehostete Modus nutzt notte_sdk und einen NotteClient mit NOTTE_API_KEY aus der Umgebung. Die README nennt als zusätzliche Leistungen dieses Dienstes Stealth-Sessions mit CAPTCHA-Lösung, Proxies und Anti-Detection, Vaults für Zugangsdaten, Personas mit eigenen E-Mail-Adressen und Telefonnummern sowie automatisierte 2FA. Der Umstieg soll laut README durch Umbenennen der Objekte möglich sein: notte-Objekte werden zu solchen des Clients. Diese Aussage stammt aus der Projektdokumentation, nicht aus einem eigenen Test. Wer den lokalen Modus als Entwicklungsweg nutzt und später auf den Dienst wechselt, sollte die beiden Pfade früh gegeneinander prüfen, weil die Premium-Funktionen im lokalen Modus nicht existieren.

Zugangsdaten und Identitäten als eigene Objekte

Zwei Bausteine fallen aus dem üblichen Rahmen. Der Vault ist ein Kontextmanager, dem über add_credentials URL, Benutzername und Passwort übergeben werden. Der Agent erhält den Vault beim Konstruktor, und laut README verwendet er die hinterlegten Daten automatisch, wenn er sie braucht. Das Beispiel zeigt eine Anmeldung bei x.com mit anschließendem Aufruf der Nachrichten. Die Persona ist ebenfalls ein Kontextmanager, erzeugt laut Beschreibung digitale Identitäten mit eigener E-Mail-Adresse und optionaler Telefonnummer und übernimmt 2FA. Beide Konstrukte lösen ein Problem, das beim Bauen von Agenten regelmäßig auftaucht: Anmeldedaten und Einmalcodes gehören nicht in den Prompt und nicht in den Aufgaben-Text. Sie werden stattdessen als Objekt übergeben. Ob das im Einzelfall ausreicht, hängt davon ab, wie der Dienst die Daten speichert. Die README beschreibt das nicht im Detail, und dazu sollte man die Dokumentation unter docs.notte.cc heranziehen, bevor produktive Konten angebunden werden.

Die Lizenz ist kein Nebensatz

Das Repository trägt die Lizenzkennung NOASSERTION, die README zeigt das Badge SSPL 1.0. Die SSPL verlangt nach verbreiteter Lesart, dass Anbieter, die den Code als Dienst betreiben, den eigenen Dienstcode offenlegen. Für ein Unternehmen, das notte intern zur Automatisierung eigener Abläufe einsetzt, ist das in der Regel unproblematisch. Für jemanden, der notte in ein gehostetes Produkt einbettet und Kunden Zugriff darauf verkauft, ist es die zentrale Frage vor der Adoption. Ich bin kein Anwalt und gebe hier keine Rechtsberatung. Der Hinweis ist trotzdem nötig, weil die Kombination aus SDK, gehostetem Dienst und Lizenz die Entscheidung stärker prägt als jede technische Einzelheit. Wer den Code nur lokal als Bibliothek nutzt, hat einen anderen Fall als wer ihn weiterverteilt. Diese Unterscheidung sollte vor dem ersten Commit geklärt sein, nicht danach.

Was die README nicht beantwortet

Die README ist ein Einstiegsdokument und verhält sich auch so. Sie zeigt den kürzesten Weg zu einem laufenden Agenten, aber sie erklärt nicht, wie eine Session mit dem Browserprozess kommuniziert, wie der Agent Beobachtungen der Seite in Schritte übersetzt oder was passiert, wenn ein Schritt fehlschlägt. Auch zu Wiederholungsversuchen, Timeouts und Kostenkontrolle steht dort nichts. Die Benchmark-Tabelle nennt für notte 86,2 Prozent Selbstauskunft, 79,0 Prozent LLM-Bewertung, 47 Sekunden pro Aufgabe und 96,6 Prozent Zuverlässigkeit, jeweils gegen Browser-Use und Convergence. Diese Zahlen stammen aus dem Repository des Projekts, konkret aus dem verlinkten open-operator-evals. Ich habe sie nicht nachgerechnet und kann nicht sagen, wie die Aufgaben verteilt waren oder wie viele Läufe hinter den Prozentwerten stehen. Wer die Zahlen als Auswahlkriterium nutzen will, muss die Evaluationsmethodik selbst lesen. Ein weiterer offener Punkt: Die Lizenzkennung NOASSERTION im Repository-Metadatensatz weicht vom SSPL-Badge in der README ab. Das kann ein Metadatenproblem sein, ist aber genau die Art Unstimmigkeit, die man vor der Adoption klärt.

Alternative: browser-use und der Unterschied im Ansatz

Die README nennt browser-use als Vergleichspunkt, und der Vergleich ist aufschlussreich. browser-use ist ebenfalls ein Python-Framework, das einen LLM-Agenten einen Browser steuern lässt. Der Unterschied liegt in der Arbeitsteilung: notte bewirbt ausdrücklich den Hybrid aus Skript und Agent, bei dem deterministische Schritte als Code laufen und nur der unklare Rest an das Modell geht. browser-use tritt stärker als Agenten-Framework auf, bei dem das Modell die Seiteninteraktion übernimmt. Dazu kommt die Betriebsform. notte liefert einen gehosteten Dienst mit Stealth-Sessions, Vault und Persona; browser-use ist ein Framework, bei dem der Betrieb beim Nutzer bleibt. Wer CAPTCHA-Lösung und Proxy-Rotation nicht selbst bauen will, hat bei notte einen kürzeren Weg. Wer keine Daten an einen Fremddienst geben darf, hat bei einem rein lokalen Framework einen kürzeren Weg. Die Benchmark-Zahlen in der README sprechen für notte, aber sie kommen vom Projekt selbst, und der Vergleich in der Tabelle ist kein unabhängiger Test.

Wartung, Versionen und der Preis der Aktualisierung

Das Projekt veröffentlicht häufig. Die drei jüngsten Releases v1.8.39, v1.8.40 und v1.8.41 liegen laut Repository-Daten an aufeinanderfolgenden Tagen im September 2026. Diese Taktung bedeutet für Betreiber, dass die Versionsnummer im eigenen Lockfile schnell veraltet und dass Breaking Changes zwischen Patch-Versionen nicht ausgeschlossen sind, auch wenn die Nummerierung anderes suggeriert. Wer notte produktiv einsetzt, sollte die Version festnageln und die Release Notes vor jedem Sprung lesen. Der lokale Modus bindet zusätzlich an patchright, eine Playwright-Variante, die als eigener Installationsschritt mit --with-deps chromium auftaucht. Diese Abhängigkeit bringt eigene Wartung mit sich, weil Browser-Binaries und Systempakete aktualisiert werden müssen. Der gehostete Modus verschiebt diesen Aufwand zum Anbieter, kostet aber Geld und setzt einen API-Schlüssel voraus. Die Entscheidung ist damit keine reine Technikfrage, sondern eine Frage der Betriebsverantwortung.

Redaktionelles Fazit

Wer Web-Automatisierung mit LLM-Agenten im eigenen Python-Stack braucht und die SSPL-1.0-Bedingungen für sein Geschäftsmodell geprüft hat, findet in notte ein Framework mit klarer Trennung zwischen Open-Source-Kern und gehostetem Dienst. Wer den Code in ein eigenes kommerzielles Produkt einbetten will, ohne die Lizenzfrage zu klären, sollte zuerst den Lizenztext und die eigenen Vertriebswege abgleichen. Vor dem Rollout würde ich prüfen, ob der lokale Modus ohne NOTTE_API_KEY mit den eigenen Modell-Endpunkten die Aufgaben abdeckt, die später im gehosteten Modus laufen sollen, und ob die Antwortstruktur über response_format stabil genug für die eigene Pipeline ist.

Offizielle Quellen

1. Issues
2. nottelabs/notte on GitHub
3. Project website
4. README
5. Releases