Jev Ultrafast im Check: Was hinter dem 7-Sekunden-Browser-Agent steckt

Was ist Jev Ultrafast?

Jev Ultrafast ist ein quelloffener Browser-Agent von Browser Use. Statt einen großen multimodalen Agenten wiederholt Screenshots interpretieren und freie Aktionen formulieren zu lassen, reduziert das Projekt jede Entscheidung auf eine kleine Menge beobachteter Bedienelemente und erlaubter Operationen.

Die Policy übernimmt TypeSafe Jev. Jev ist kein klassisches Textmodell für lange Antworten, sondern bewertet typisierte Entscheidungsoptionen. Ein separates kleines Sprachmodell wird nur dann aufgerufen, wenn der Agent Text in ein Feld schreiben muss. Der Browserzugriff läuft über Browser Harness und ein vorhandenes Chrome-Profil.

Kerndaten zum Projekt

Merkmal	Stand
Repository	browser-use/jev-ultrafast
Paketversion	`0.1.0`
Sprache	Python, mindestens Version 3.12
Lizenz	MIT
GitHub-Snapshot	16.892 Stars und 1.067 Forks am 22. September 2026, 10:06 CEST
Öffentliche Historie	Drei Commits und keine Tags am 22. September 2026
Cloud-Angebot	Waitlist statt allgemein verfügbarer Dienst

Die hohe Zahl an GitHub-Stars zeigt Aufmerksamkeit, nicht Produktreife. Das Repository wurde laut GitHub am 16. September 2026 erstellt und hatte beim Snapshot weder Releases noch Tags.

Wie funktioniert die Architektur?

Der relevante Unterschied zu vielen Browser-Agenten liegt nicht in einem einzelnen Modell, sondern in der kontrollierten Pipeline. Jev Ultrafast trennt Beobachtung, Entscheidung, Textgenerierung und Ausführung klar voneinander.

Der DOM-Snapshot begrenzt die sichtbare Welt

Ein JavaScript-Snapshot liest sichtbare Standard-HTML- und ARIA-Bedienelemente atomar aus der Seite. Jedes erkannte Element erhält einen Index. Aus einer komplexen Website wird dadurch eine kompakte Tabelle, etwa mit einem Abflugfeld, einem Zielfeld und mehreren Schaltflächen.

Das reduziert Kontext und Browser-Roundtrips. Gleichzeitig ist es die zentrale Fähigkeitsgrenze: Was der Snapshot nicht indexiert, existiert für die Policy praktisch nicht. Screenshots steuern den Standardloop laut Repository-Dokumentation nicht; sie werden nur für Inspector und Demo-Video genutzt.

Acht Operationen ersetzen freie Tool-Aufrufe

Der Agent wählt ausschließlich zwischen den im README dokumentierten acht Operationen:

Operation	Aufgabe
`CLICK`	Indexiertes Element anklicken
`TYPE_TEXT`	Generierten Text in ein kompatibles Feld schreiben
`SELECT`	Beobachtete Option eines nativen Auswahlfelds wählen
`SCROLL_UP`	Nach oben scrollen
`SCROLL_DOWN`	Nach unten scrollen
`WAIT`	Auf einen veränderten Seitenzustand warten
`DONE`	Ziel als erreicht melden
`BLOCKED`	Keine unterstützte Folgeaktion melden

Jede Zielauswahl ist an die Operation gekoppelt. Ein Click-Kopf sieht nur anklickbare Elemente, ein Text-Kopf nur beschreibbare Felder. Modellausgaben werden nicht als CSS-Selektoren, Koordinaten, Shell-Befehle oder JavaScript ausgeführt.

Speculative fan-out spart einen Modell-Roundtrip

Operation und mehrere kompatible Zielköpfe werden in einem TypeSafe-Request parallel bewertet. Wählt Jev `CLICK`, wird nur das Ergebnis des Click-Kopfs verwendet. Dadurch benötigt der Agent nicht erst eine Anfrage für die Operation und anschließend eine zweite für das Ziel.

Dieses Verfahren passt zum Jev-Kontextmodell: Der State wird einmal verarbeitet, anschließend werden mehrere Fragen parallel dagegen ausgewertet. Jev 1.13 unterstützt dabei einen Gesamtkontext von 64.000 Tokens pro Request, wobei für State plus längste Frage eine Grenze von 32.000 Tokens gilt.

Text bleibt ein separater Datenpfad

Bei `TYPE_TEXT` entscheidet Jev nur, welches Feld beschrieben werden soll. Den konkreten Wert erzeugt ein OpenAI-kompatibles Textmodell. Das offizielle Beispiel nutzt laut README `inception/mercury-2.5`; auch andere kompatible Anbieter lassen sich konfigurieren.

Diese Trennung hält die Entscheidungs-Policy klein, erzeugt aber einen zweiten Modellprovider. Neben Ziel, URL, Seitentitel, sichtbarem Text und Elementtabelle kann bei Texteingaben zusätzlicher Seitenkontext an den Text-Helper gehen. API-Endpunkt, Modell und Schlüssel sollten deshalb nie impliziten Defaults überlassen werden.

Guards prüfen die Ausführung, nicht das Ziel

Vor einem Klick prüft der Executor unter anderem, ob der Snapshot noch aktuell ist, ob das Element weiterhin zum Dokument gehört, welche Geometrie es aktuell hat und ob es von einem anderen Element verdeckt wird. Das verhindert viele technisch ungültige Aktionen.

Es verhindert aber keine semantisch falsche Aktion. Auch `DONE` ist nur eine Modellentscheidung. Der Performance-Report verlangt deshalb ausdrücklich eine unabhängige Ergebnisprüfung.

Warum ist Jev Ultrafast so schnell?

Vier Entscheidungen reduzieren die Latenz: kein Vision-Modell im Standardloop, ein atomarer Snapshot statt vieler einzelner Browserabfragen, parallele Operations- und Zielbewertung sowie kurze, ereignisbasierte Wartefenster nach Aktionen.

Im aufgezeichneten Flights-Lauf gab es 17 Jev-Requests, zehn Interaktionen, ein explizites `WAIT` und zwei Textmodell-Aufrufe. Die mediane Jev-Latenz lag bei 178 Millisekunden, der Suchvorgang startete nach 5,217 Sekunden und das verifizierte Ende wurde nach 7,073 Sekunden erreicht.

Was die Optimierung tatsächlich verbessert hat

Metrik	Original	Optimiert	Veränderung
Median-Laufzeit	9,450 s	7,092 s	−24,95 %
TypeSafe-Requests	22	17	−22,73 %
Browser-Protokollaufrufe	1.092	101	−90,75 %
Verifizierte Läufe	3/3	3/3	unverändert

*Quelle: Matched Runtime Comparison von Browser Use, abgerufen am 22. September 2026.*

Die auffällige Reduktion um 90,75 Prozent betrifft Browser-Protokollaufrufe. End-to-End sank die mediane Laufzeit um 2,358 Sekunden beziehungsweise 24,95 Prozent. Wer aus den Protokollaufrufen eine allgemeine Geschwindigkeitssteigerung von rund 91 Prozent ableitet, vermischt zwei verschiedene Metriken.

Wie belastbar ist der 7-Sekunden-Benchmark?

Der Lauf ist als technische Messung brauchbar. Er enthält Modellaufrufe, Textgenerierung, Browserarbeit, verworfene Entscheidungen durch veraltete Snapshots und Ladezeiten. Browser-Setup, Initialnavigation und die frische unabhängige Nachprüfung nach dem Lauf liegen laut Messdefinition außerhalb der Stoppuhr.

Als allgemeiner Browser-Agent-Benchmark reicht das nicht. Der Vergleich umfasst sechs alternierende Läufe, also nur drei Paare, auf einem Task und einem bestehenden Chrome-Profil. Google, Netzwerk, Routing und Cache blieben live. Der Report nennt selbst einen zweiseitigen Sign-Test mit p = 0,25. Das ist keine belastbare Evidenz für eine allgemeine Überlegenheit.

Die zusätzlich dokumentierten Läufe auf Wikipedia mit 2,798 Sekunden und einem lokalen Hotel-Fixture mit 1,896 Sekunden sind Smoke-Checks. Sie wurden nicht als kontrollierte Vergleichsbenchmarks angelegt.

Für eine belastbare Bewertung braucht es standardisierte Aufgaben, feste Erfolgsprüfungen und wiederholte Läufe über breitere Web-Umgebungen. WorkArena und BrowserGym zeigen den passenden Rahmen: WorkArena liefert 33 Aufgaben mit 19.912 eindeutigen Aufgabeninstanzen auf der ServiceNow-Plattform; BrowserGym stellt standardisierte Aktionen sowie HTML-, Accessibility-Tree- und Pixel-Beobachtungen bereit.

Was kostet ein Lauf?

TypeSafe listete Jev 1.13 am 22. September 2026 mit 0,042 US-Dollar pro Million Input-Tokens; Output-Tokens waren laut Preisseite kostenlos. Auf die im Performance-Report genannten 90.558 Input-Tokens angewandt, ergibt das rechnerisch 0,003803436 US-Dollar. Der Report selbst weist für TypeSafe keinen abgerechneten Dollarbetrag aus.

Addiert man die von OpenRouter ausgewiesenen 0,00006272 US-Dollar für zwei Text-Helper-Aufrufe, liegt die Schätzung zum damaligen Listenpreis bei 0,003866156 US-Dollar, also rund 0,0039 US-Dollar. Browser- und Infrastrukturkosten sind nicht enthalten.

Der niedrige Einzelpreis darf nicht mit stabilen Gesamtkosten verwechselt werden. Wiederholungen, veraltete Snapshots, fehlgeschlagene Aktionen und zusätzliche Ergebnisprüfungen erhöhen Requests und Tokenverbrauch. Gerade längere Aufgaben können den Vorteil eines günstigen Einzelentscheids schnell aufzehren.

Was zeigt der lokale Codecheck?

Der lokal gepinnte Commit `1231850a0bf1a0c0341fe408ef1668dbbfdfac46` ließ sich reproduzierbar installieren und bauen. Alle 31 Offline-Tests bestanden, Ruff meldete keine Fehler, beide JavaScript-Dateien bestanden den Node-Syntaxcheck und sowohl Wheel als auch Source-Distribution wurden erzeugt.

Die untersuchte Codebasis ist überschaubar: 1.186 Python-Codezeilen und 3.704 Codezeilen über 38 Dateien einschließlich Mess-JSON, JavaScript, HTML und CSS. Das ist positiv für Lesbarkeit und Auditierbarkeit. Es beweist aber weder die Zuverlässigkeit auf realen Websites noch die Qualität der Modellentscheidungen, weil ohne TypeSafe- und Textmodell-Schlüssel kein kostenpflichtiger Live-Lauf durchgeführt wurde.

Wo scheitert Jev Ultrafast aktuell?

Nicht indexierte Elemente bleiben unerreichbar

Der DOM-Reader unterstützt gängige native HTML- und ARIA-Controls, aber keine vollständige Accessibility-Namensauflösung. Shadow Roots, Frames, Canvas, Uploads, neue Tabs, verschachteltes Scrollen und beliebige Keyboard-Widgets sind laut Projektgrenzen nicht abgedeckt.

Ein externer Autor berichtet in Issue 23, dass nicht native Vorschlagszeilen ohne ARIA-Rolle vollständig in der Elementtabelle fehlten. Sein dokumentierter Lauf tippte 60-mal in dasselbe Feld, verbrauchte 120 Entscheidungen und endete nach 77 Sekunden am Aktionsbudget. Das ist ein reproduktionsnaher Issue-Bericht, keine unabhängige Benchmarkmessung.

Ein kleiner Action Space kann falsche Alternativen begünstigen

Fehlt das richtige Ziel, kann der Agent nicht nur `BLOCKED` melden. Er kann auch ein benachbartes, aber falsches indexiertes Element wählen. Der enge Action Space reduziert technisch mögliche Aktionen, garantiert jedoch nicht, dass die verbleibende Auswahl semantisch korrekt ist.

Das ist der zentrale Zielkonflikt der Architektur: Je kleiner die Aktionsfläche, desto schneller und kontrollierbarer wird die Entscheidung. Gleichzeitig steigt das Risiko, dass moderne Component Libraries, Icon-Buttons oder Spezial-Widgets für den Agenten unsichtbar bleiben.

Reale Zuverlässigkeit ist nicht belegt

In einem Maintainer-Kommentar zu Issue 67 werden für 20 BU-Bench-Aufgaben 0 von 20 verifizierte Erfolge sowohl für Main als auch für einen Retry-Fork sowie ungefähr 5,7-fache Inferenzkosten des Forks gemeldet. CAPTCHA- und Browserprobleme erschweren die Interpretation; ohne veröffentlichtes Harness-Artefakt ist das ein wichtiger Gegenbefund, aber kein vollständiger Benchmark.

Die Demo war zeitlich fragil

Ein externer Autor dokumentiert in Issue 93, dass der hart codierte 20. September 2026 ab dem 21. September vergangen und in der beobachteten Google-Flights-Oberfläche nicht mehr als auswählbares Ziel indexiert war. Damit war der ausgelieferte Demo-Task nach diesem Bericht unlösbar.

Das ist kein Beleg gegen Jevs Modellqualität. Es zeigt aber, warum Live-Web-Demos mit hart codierten Daten keine dauerhafte Evaluation ersetzen. Außerdem sucht und prüft die Demo nur Flugergebnisse; sie wählt oder bucht keinen Flug.

Wie sicher ist der begrenzte Action Space?

Die Architektur schränkt auf der Ausführungsebene ein, welche technischen Aktionen das Modell auslösen kann: Es kann keine beliebigen Selektoren, freien Koordinaten oder ausführbaren Code an den Browser übergeben. Frische-, Geometrie- und Occlusion-Prüfungen begrenzen zusätzlich technisch ungültige Aktionen. Wie stark das reale Sicherheitsrisiko dadurch sinkt, wurde für Jev Ultrafast nicht unabhängig gemessen.

Dieser Schutz wirkt auf der Ausführungsebene. Er löst nicht das semantische Problem, dass untrusted Seitentext Teil des Modellzustands wird.

Prompt Injection bleibt möglich

TypeSafe dokumentiert für Jev 1.13, dass das Modell unter anderem mit adversarial Content, großen irrelevanten States, Zahlen sowie Datumsvergleichen Schwierigkeiten haben kann. Sichtbarer Seitentext wird nicht automatisch als feindliche Eingabe isoliert. Eine manipulierte Seite kann daher beeinflussen, welche erlaubte Aktion Jev auswählt.

Der geschlossene Action Space begrenzt den möglichen Schaden, verhindert aber nicht den falschen Klick innerhalb dieses Raums. Wenn ein Agent beispielsweise Zugriff auf ein eingeloggtes Konto hat, kann bereits eine erlaubte Schaltfläche eine irreversible Wirkung auslösen.

Die BrowseSafe-Studie stellt mit BrowseSafe-Bench einen konstruierten Datensatz aus 14.719 bösartigen und benignen Samples über elf Angriffstypen vor. Die Autoren schlagen Defense in Depth mit Trust Boundaries für Tool-Ausgaben, Vorverarbeitung von Webinhalten, paralleler Angriffserkennung und konservativer Aggregation vor. Ein kleiner Action Space wäre dabei nur eine Schicht.

Persönliche Browserprofile sind ungeeignet

Browser Harness kann an ein bestehendes Chrome-Profil mit Cookies, Tabs und aktiven Logins anbinden. Für einen Agenten mit Klick- und Texteingaberechten ist das kein akzeptabler Standard. Nutze ein separates Wegwerfprofil oder einen isolierten Browser ohne produktive Konten, Zahlungsdaten und private Sitzungen.

Zwei Provider erhalten Seitendaten

Jev verarbeitet Ziel, URL, Seitentitel, sichtbaren Text, Elemente und Aktionshistorie. Bei `TYPE_TEXT` erhält ein zweiter Modellprovider zusätzlichen Kontext zur Texteingabe. TypeSafe erklärt zwar, Kundenanfragen und Antworten nicht zum Training zu verwenden; Zero Data Retention wird dort jedoch ausdrücklich für Enterprise-Kunden genannt. Die konkrete Datenverarbeitung des zweiten Providers muss separat geprüft werden.

Wie solltest du Jev Ultrafast testen?

Für einen isolierten Architekturtest sind folgende Mindestmaßnahmen sinnvoll:

1. Verwende ein separates, kurzlebiges Browserprofil ohne produktive Logins.
2. Pinne `TYPESAFE_MODEL` auf eine feste Modellversion wie `jev-1.13.0`, statt einen beweglichen Alias zu verwenden.
3. Setze `TEXT_MODEL_BASE_URL`, `TEXT_MODEL` und beide API-Schlüssel explizit.
4. Begrenze erlaubte Domains und Aktionen außerhalb des Modells deterministisch.
5. Verlange vor irreversiblen Aktionen immer eine manuelle Bestätigung.
6. Prüfe `DONE` mit task-spezifischen Assertions unabhängig nach.
7. Protokolliere State, Modellversion, Confidence, Aktionen, Kosten und Abbruchgründe.
8. Teste gezielt Prompt Injection, fehlende Controls, langsame Requests und veraltete Snapshots.

Die Installation selbst ist kurz, setzt aber Python 3.12 oder neuer und zwei API-Zugänge voraus:

git clone https://github.com/browser-use/jev-ultrafast.git
cd jev-ultrafast
uv sync
cp .env.example .env
uv run jev

Wie unterscheidet sich Jev Ultrafast von Alternativen?

Die Projekte erfüllen unterschiedliche Rollen. Ein direkter Siegervergleich wäre deshalb irreführend.

Kriterium	Jev Ultrafast	Browser Use	Playwright MCP	BrowserGym
Kategorie	Spezialisierter Browser-Agent	Allgemeiner Agent und Cloud-Plattform	Browser-Toolserver für vorhandene Agenten	Evaluationsumgebung
Beobachtung	Atomarer DOM-Snapshot	Modell- und konfigurationsabhängig	Accessibility Snapshot, optional Vision	HTML, AXTree und Pixel
Eigene Policy	Jev	Frei wählbare Agentenmodelle	Nein, Client-Agent plant	Nein, Framework
Stärke	Niedrige Latenz, enger Action Space	Breiter Funktionsumfang	Deterministische Browsertools auf Playwright	Reproduzierbare Aufgaben und Messung
Grenze	Schmale Evaluation und DOM-Lücken	Höhere Komplexität	Kein autonomer Agent	Kein Endnutzer-Agent

Jev Ultrafast ist vor allem eine Fallstudie dafür, wie weit sich Browser-Interaktion durch strukturierte Beobachtung und typisierte Entscheidungen beschleunigen lässt. Playwright MCP beantwortet eine andere Frage: Es stellt einem bereits vorhandenen Agenten robuste Browserwerkzeuge bereit. BrowserGym wiederum wäre die geeignete Umgebung, um Jev Ultrafast reproduzierbar gegen andere Agenten zu evaluieren.

Für wen lohnt sich das Projekt?

Zielgruppe	Empfehlung
Agenten-Entwickler	Code und Architektur lesen, Guards und fan-out als Muster prüfen
Forschung und Evaluation	In standardisierte Benchmarks integrieren, nicht die Demo als Ergebnis übernehmen
Interne Prototypen	Nur für eng begrenzte, reversible Abläufe in isolierter Umgebung
Produktive Konten	Aktuell nicht ohne zusätzliche Policy-, Sicherheits- und Bestätigungsschicht
Buchungen, Käufe, Veröffentlichungen	Keine autonome Ausführung; irreversible Schritte manuell bestätigen

Wer nur Webseiten lesen oder Informationen sammeln will, braucht nicht zwingend einen Agenten mit Schreib- und Klickrechten. Für diesen Anwendungsfall sind spezialisierte Recherchewerkzeuge wie Agent Reach oft einfacher und risikoärmer.

Quellen

• Jev Ultrafast: Repository und README
• Jev Ultrafast: Performance-Report
• Issue 23: Nicht indexierte, nicht native Click-Ziele
• Issue 67: Fehler bei längeren realen Aufgaben und Retry-Ansatz
• Issue 93: Abgelaufenes Datum im Flights-Demo-Task
• TypeSafe: Jev-Modelle, Preise und Datenverarbeitung
• TypeSafe: Dokumentierte Grenzen von Jev 1.13
• BrowseSafe: Prompt Injection in Browser-Agenten
• WorkArena und BrowserGym

FAQ: Häufig gestellte Fragen zu Jev Ultrafast

Was ist Jev Ultrafast?

Jev Ultrafast ist ein quelloffener Browser-Agent von Browser Use. Er wandelt sichtbare DOM-Bedienelemente in eine indexierte Tabelle um und lässt TypeSafe Jev aus einer begrenzten Menge von Operationen und Zielen wählen.

Ist Jev Ultrafast wirklich sieben Sekunden schnell?

Für einen aufgezeichneten Google-Flights-Task wurden 7,073 Sekunden gemessen. Daraus folgt keine allgemeine Laufzeit, weil nur ein Task mit einem Browserprofil und drei Vergleichspaaren untersucht wurde.

Ist der Agent 91 Prozent schneller?

Nein. Die 90,75 Prozent beziehen sich auf Browser-Protokollaufrufe. Die mediane End-to-End-Laufzeit sank um 24,95 Prozent.

Ist Jev Ultrafast kostenlos?

Der Code steht unter MIT-Lizenz. Live-Läufe verursachen Modell- und gegebenenfalls Browser-Infrastrukturkosten. Für die aufgezeichneten Tokenmengen ergibt sich mit dem am 22. September 2026 gelisteten Jev-Preis plus den ausgewiesenen Helper-Kosten eine Schätzung von rund 0,0039 US-Dollar; das ist keine bestätigte Gesamtrechnung.

Welche API-Keys werden benötigt?

Du brauchst einen TypeSafe-API-Key für Jev und einen separaten Key für den OpenAI-kompatiblen Text-Helper. Endpunkt und Modell solltest du ausdrücklich konfigurieren, damit Schlüssel und Seitenkontext nicht versehentlich an den falschen Provider gehen.

Nutzt Jev Ultrafast Screenshots oder ein Vision-Modell?

Im Standardloop nicht. Laut Projektbeschreibung arbeitet Jev mit strukturiertem Textzustand aus dem DOM; Screenshots dienen dem Inspector und der Demo-Darstellung.

Kann Jev Ultrafast Flüge buchen?

Die dokumentierte Demo sucht eine Verbindung und prüft, ob passende Ergebnisse sichtbar sind. Sie wählt keinen Flug aus und führt keine Buchung durch.

Ist Jev Ultrafast gegen Prompt Injection geschützt?

Nicht vollständig. Der enge Action Space und die Ausführungs-Guards begrenzen die technisch ausführbaren Aktionen, sind aber kein belegter Prompt-Injection-Schutz. Sichtbarer Seitentext kann weiterhin die Wahl einer erlaubten Aktion beeinflussen; reale Nutzung braucht zusätzliche Trust Boundaries, Filter, Bestätigungen und unabhängige Prüfungen.

Fazit

Jev Ultrafast ist eine lesenswerte Architekturstudie, aber noch kein belastbar evaluierter Universalagent. Der relevante Befund ist eine gemessene Laufzeitverbesserung von rund 25 Prozent auf einem eng definierten Task, nicht ein allgemeiner 7-Sekunden- oder 91-Prozent-Anspruch. Beobachte das Projekt und teste es isoliert; für produktive Logins und irreversible Aktionen fehlen derzeit breite Benchmarks, vollständige UI-Abdeckung und ausreichende Sicherheitsbarrieren.

Weiterführend: Playwright als Grundlage deterministischer Browserautomatisierung und Agent Reach für lesenden Webzugriff.