- Bei derselben Aufgabe im Admin-Panel bediente der Vision-Agent die UI per Screenshot und Klicks, während der API-Agent dieselben Anwendungs-Handler über strukturierte Antworten aufrief, sodass nur die Schnittstelle als Kostenvariable übrig blieb
- Mit dem Standard-Prompt schloss der API-Agent die Aufgabe in 8 Aufrufen ab, der Vision-Agent übersah jedoch 3 ausstehenden Reviews unterhalb des sichtbaren Bereichs und genehmigte nur 1 von 4
- Nach Hinzufügen einer 14-stufigen UI walkthrough schloss auch der Vision-Agent die Aufgabe ab, benötigte dafür aber rund 14 Minuten und etwa 500.000 Input-Token, und diese konkrete Anleitung selbst verursacht zusätzliche Engineering-Kosten
- Im Gesamtergebnis verbrauchte der Vision-Pfad auf Sonnet-Basis im Mittel 53 Schritte, 1003 Sekunden und 550.976 Input-Token, während der API-Pfad mit 8 Aufrufen, 19,7 Sekunden und 12.151 Input-Token auskam; auch Kosten- und Zeitstreuung waren deutlich geringer
- Der Kostenabstand entstand eher aus der Struktur der Schnittstelle als aus der Modellleistung; wenn wie in Reflex 0.9 HTTP-Endpunkte automatisch aus Event-Handlern erzeugt werden, fällt die Kostenrechnung bei selbst entwickelten internen Tools zugunsten des strukturierten API-Pfads aus
Ziel des Benchmarks und Versuchsaufbau
- Gemessen wurden die Kosten, indem dasselbe Admin-Panel einmal per Vision-Agent und einmal über einen strukturierten API-Ansatz bedient wurde
- Wenn KI-Agenten Web-Apps ohne bereitgestellte API bedienen sollen, wird der Vision-Agent leicht zur Standardwahl
- In Situationen, in denen Teams mehr als 20 interne Tools haben, wird das Schreiben einer MCP- oder REST-Oberfläche pro App zu einem eigenen Engineering-Projekt, weshalb sich viele Teams für Vision-Agenten entscheiden
- Die Test-App ist ein Admin-Panel zur Verwaltung von Kunden, Bestellungen und Reviews und orientiert sich am react-admin Posters Galore demo
- Beide Agenten nutzten dieselbe laufende App, dasselbe Claude Sonnet, denselben festen Datensatz und dieselbe Aufgabe; nur die Schnittstelle war die Variable
- Die Aufgabe lautete: den Kunden namens „Smith“ mit den meisten Bestellungen finden, dessen neueste ausstehende Bestellung finden, anschließend alle ausstehenden Reviews genehmigen und die Bestellung als versandt markieren
- Die Aufgabe berührt drei Ressourcen und umfasst Filtern, Paginierung, Nachschlagen zwischen Entitäten sowie Lesen und Schreiben und ähnelt damit typischen Arbeitsabläufen in internen Tools
Die zwei Ausführungspfade
-
Pfad A: Vision agent
- Claude Sonnet verwendete browser-use 0.12 im Vision-Modus und bediente die UI per Screenshot und Klicks
-
Pfad B: API agent
- Claude Sonnet rief im Tool-Use-Modus direkt die HTTP-Endpunkte der App auf
- Jedes Tool ist einem oder mehreren Event-Handlern des App-Status zugeordnet; verwendet wird dieselbe Funktion, die auch durch Button-Klicks ausgelöst wird
- Der Agent erhält strukturierte Antworten statt gerenderter Seiten
Warum der Vision-Agent mit dem Standard-Prompt scheiterte
- Beide Agenten bekamen dieselbe sechssätzige Aufgabenbeschreibung und wurden ausgeführt
- Der API-Agent erledigte die Aufgabe in 8 Aufrufen
- Er listete nach Status „ausstehend“ gefilterte Kunden-Reviews auf
- Er genehmigte jedes Review
- Er markierte die Bestellung als versandt
- Beide Agenten rufen dieselbe Anwendungslogik auf, aber der API-Agent liest direkt strukturierte Antworten, statt gerenderte Seiten anzusehen
- Der Vision-Agent fand mit demselben Prompt nur 1 von 4 ausstehenden Reviews, genehmigte dieses und ging dann zum nächsten Schritt über
- Die übrigen 3 Reviews befanden sich unterhalb des sichtbaren Bereichs der Review-Seite, und es gab für den Agenten kein Signal, dass gescrollt werden musste
- Dieses Scheitern war kein Problem des Modell-Reasonings, sondern entstand daraus, dass die gerenderte Seite kein Signal gab, dass nicht alles sichtbar war
- Der API-Agent ruft zwar dieselben Handler auf wie die UI, aber die Antwort enthält nicht nur die aktuell gerenderten Zeilen, sondern die gesamte vom Handler zurückgegebene Ergebnismenge
- Der API-Agent interpretiert keine Paginierungssteuerung aus Pixeln, sondern liest Informationen wie „Seite 1 von 4 mit jeweils 50 Einträgen“ direkt aus
Ergebnis nach Hinzufügen einer 14-stufigen UI-Anleitung
- Für einen fairen Vergleich wurde der Vision-Prompt als explizite UI walkthrough neu geschrieben
- UI-Elemente, mit denen der Agent in jedem Schritt interagieren sollte, etwa Sidebar-Einträge, Tabs und Formularfelder, wurden namentlich angegeben
- Der Navigationsprozess, den der Agent zuvor nicht selbst finden konnte, wurde als 14 nummerierte Anweisungen formuliert
- Mit dieser Anleitung schloss der Vision-Agent die Aufgabe ab
- Die Ausführung dauerte jedoch 14 Minuten und verbrauchte rund 500.000 Input-Token
- Jede nummerierte Anweisung erscheint nicht direkt in der Tokenzahl, steht aber für reale Engineering-Kosten
- Wer Vision-Agenten in internen Tools einsetzen will, muss entweder Prompts mit diesem Detailgrad schreiben oder akzeptieren, dass Agenten Aufgaben stillschweigend übersehen können
Ausführungsweise und Streuung
- Der API-Pfad wurde 5-mal, der Vision-Pfad 3-mal ausgeführt
- Der Vision-Pfad dauerte pro Lauf 14 bis 22 Minuten und verbrauchte 400.000 bis 750.000 Token, daher wurde er auf 3 Läufe begrenzt
- Der Vision-Pfad zeigte eine große Streuung zwischen den Läufen
- In 3 Läufen lag die verstrichene Zeit zwischen 749 und 1257 Sekunden
- Die Input-Token lagen zwischen 407.000 und 751.000
- Der kürzeste Lauf benötigte 43 Zyklen, der längste 68 Zyklen
- Die Wiederholung aus Screenshot, Reasoning und Klick enthält genug Nichtdeterminismus, sodass sich aus nur einem einzelnen Lauf die typischen Kosten schwer abschätzen lassen
- Beim API-Pfad gab es diese Streuung nicht
- Sonnet verwendete in allen 5 Läufen identisch 8 Tool-Aufrufe
- Die Zahl der Input-Token variierte über alle 5 Läufe nur um ±27
- Strukturierte Antworten geben dem Agenten keinen Anlass zum Abschweifen, daher ruft er dieselben Handler in derselben Reihenfolge auf
Gesamtergebnisse
| Kennzahl | Vision agent (Sonnet) | API (Sonnet) | API (Haiku) |
|---|---|---|---|
| Schritte / Aufrufe | 53 ± 13 | 8 ± 0 | 8 ± 0 |
| Verstrichene Zeit | 1003 s ± 254 s, etwa 17 Minuten | 19,7 s ± 2,8 s | 7,7 s ± 0,5 s |
| Input-Token | 550.976 ± 178.849 | 12.151 ± 27 | 9.478 ± 809 |
| Output-Token | 37.962 ± 10.850 | 934 ± 41 | 819 ± 52 |
- Die Zahlen sind Mittelwert ± Stichproben-Standardabweichung (n−1); für den API-Pfad gilt n=5, für den Vision-Pfad n=3
- Details zu allen Läufen sind im Repository einsehbar
- Haiku konnte den Vision-Pfad nicht abschließen
- Das Scheitern ist auf das Schema strukturierter Ausgaben in browser-use 0.12 begrenzt; Haiku konnte dieses weder im Vision-Modus noch im reinen Textmodus stabil erzeugen
- Im API-Pfad schloss Haiku in unter 8 Sekunden und mit weniger als 10.000 Input-Token ab und war damit die günstigste getestete Konfiguration
Strukturelle Kostenlücke
- Der Kostenunterschied ergibt sich direkt aus der Architektur
- Ein Agent, der sehen muss, um handeln zu können, muss selbst bei besseren Modellen immer die Kosten des Sehens tragen
- Ein besseres Vision-Modell kann die Fehlerrate pro Screenshot senken, aber nicht die Zahl der Screenshots reduzieren, die nötig sind, um an relevante Daten zu gelangen
- Jedes Rendering ist ein Screenshot, und ein Screenshot entspricht Tausenden von Input-Token
- Beide Agenten durchlaufen dieselbe Anwendungslogik
- Beide führen Filterung, Paginierung und Updates auf dieselbe Weise wie die UI aus
- Der Unterschied liegt darin, was sie in jedem Schritt lesen
- Der Vision-Agent liest Pixel und muss alle Zwischenzustände rendern und interpretieren
- Der API-Agent liest strukturierte Antworten aus denselben Handlern, und diese Antworten enthalten bereits die Daten, die die UI anzeigen wollte
- Bessere Modelle können die Kosten pro Schritt senken, aber die Anzahl der Schritte wird von der Schnittstelle bestimmt und sinkt daher nicht
Wenn die Engineering-Kosten für APIs sinken, ändert sich die Abwägung
- Der Benchmark ließ sich dank Reflex 0.9 kostengünstig durchführen
- Reflex 0.9 enthält ein Plugin, das HTTP-Endpunkte automatisch aus Event-Handlern von Reflex-Anwendungen erzeugt
- Das strukturelle Argument hängt nicht von Reflex ab, aber Reflex macht den API-Pfad ohne separate Codebasis ausführbar
- Entscheidend ist, was möglich wird, wenn die Engineering-Kosten einer API-Oberfläche nahe null sinken
- Vision-Agenten bleiben weiterhin passend für Anwendungen, die man nicht direkt kontrolliert
- SaaS-Produkte von Drittanbietern
- Legacy-Systeme
- Anwendungen, die nicht verändert werden können
- Bei intern entwickelten Tools kippt die Kostenrechnung in die andere Richtung
Umfang des Experiments und Hinweise
- Die Vision-Ergebnisse sind auf den Vision-Modus von browser-use 0.12 beschränkt; andere Vision-Agenten können sich anders verhalten
- Der Runner für Pfad B formte die automatisch erzeugten Endpunkte zu einer kleinen REST-Tool-Oberfläche von etwa 30 Zeilen um
- Der Agent sieht diese als Tools wie
list_customersoderupdate_order - Der Datensatz ist fest und klein
- 900 Kunden
- 600 Bestellungen
- 324 Reviews
- Das Verhalten bei Daten in Produktionsgröße wurde nicht gemessen
- Der Vision-Agent wurde über
ChatAnthropicvon LangChain ausgeführt - Der API-Agent wurde direkt mit dem Anthropic SDK ausgeführt
- Die berichteten Tokenzahlen sind nicht gecachte Input-Token
Materialien zur Reproduktion
- Das Repository enthält die Erzeugung der Seed-Daten, die gepatchte react-admin-Demo, beide Agenten-Skripte und die Rohresultate
1 Kommentare
Hacker-News-Kommentare
Hier versteckt sich eine Möglichkeit, Agenten teuer durch Websites navigieren zu lassen: Elemente auf dem Bildschirm verschieben, wenn sich die Maus bewegt; die UI nur dann funktionieren lassen, wenn natürliche Mausbewegungen erzwungen werden; bei jedem Besuch in JS die Button-Beschriftungen zufällig umbenennen; und bis ganz nach unten scrollen lassen, um versteckte Zusatzaufgaben zu sehen
Moment mal, das klingt wie eine typische Enterprise-SaaS-App
Interessant und auch etwas deprimierend ist, dass man dazu für Menschen nicht bereit war, aber sofort losrennt, wenn AI es braucht. Offenbar tut man es nur für AI, weil es sich für einen selbst lohnender anfühlt als für irgendeine abstrakte Person in der Zukunft
[0] https://www.cs.unm.edu/~dlchao/papers/p152-chao.pdf
Das war noch vor der Zeit generativer AI, aber um die App zu bedienen und Daten zu exportieren, mussten wir OCR, simulierte Benutzereingaben und Print-Captures kombinieren. Ich will gar nicht wissen, was die Entwickler getan hätten, wenn sie von der Windows-DRM-API zum Blockieren von Screenshots oder davon gewusst hätten, dass sich Text aus PostScript-Dateien mit minimaler Formatierung leicht wiederherstellen lässt
Ironischerweise bestand der Prozess davor darin, billigen Offshore-Arbeitskräften schreibgeschützten Remote-Zugriff auf alle Daten des Systems zu geben, was ein deutlich größeres Sicherheitsrisiko war, als wenn autorisierte Mitarbeitende mit einem lokalen Tool eines vertrauenswürdigen Anbieters die Arbeit ohne Netzwerkzugriff automatisieren
Ich baue gerade etwas, das genau dieses Problem löst[1]
Auf der Landingpage steht das noch nicht im Vordergrund, aber im Kern stellt es Agenten ein kleines Set von Tools zur Verfügung, mit denen sie App-Oberflächen erkunden können, insbesondere allgemeine macOS Function APIs rund um Accessibility
Nachdem der Agent eine App erkundet hat, kann er wiederholbare Workflows schreiben und sie später aus der CLI ausführen, etwa mit
invoke chrome pinTabDer Grund für Accessibility ist letztlich, dass es ein gutes DOM für Apps ist. Nicht jede App implementiert es perfekt, aber genug tun es, sodass es sehr nützlich ist
[1] https://getinvoke.com - die aktuelle Landingpage richtet sich an Creators und behandelt diesen Use Case noch nicht
Man sieht, wie die grünen Zellen LLMs anleiten können, nur bestimmte Teile des Bildschirms zu lesen oder OCR zu verwenden, wie viel Text bereits standardmäßig in die Accessibility-Engine eingebaut ist und wie das nicht nur zu MCP, sondern auch zu Code-Generatoren führen kann, die selbst Skripte bauen und ausführen, welche die Accessibility-Schicht eines Workflows crawlen
Ich halte das für ein sehr fruchtbares Feld. Große Labs müssen Ansätze verwenden, die über viele Plattformen und beliebige Workflows hinweg funktionieren, und Full-Screen-Vision ist der kleinste gemeinsame Nenner. Plattformspezifische Ansätze sind ein wirklich spannender offener Raum
Man muss dann aber unbedingt sicherstellen, dass keine Workflows geteilt werden, die Benutzerdaten wie Passwörter auslesen
Das große Problem ist, dass viel zu viele Apps diese Elemente miserabel exponieren. Mein Ansatz war, mit UIAccess oder einem einmaligen Durchlauf eines Vision-Modells UI-Templates zu erzeugen: https://github.com/willwade/app-automate?tab=readme-ov-file#...
Das Gegenargument dazu auf reddit ist, dass die praktische Erfahrung eher das Gegenteil zeigt. UIA wirkt in der Dokumentation einheitlich, aber WPF, WinForms und Win32 exponieren alle unterschiedliche Control-Patterns, sodass man am Ende Toolkit-spezifische Handler schreiben muss. Qt exponiert nur dann überhaupt etwas, wenn QAccessible einkompiliert und das Accessibility-Plugin zur Laufzeit geladen wird, was bei ausgelieferten Binärdateien fast nie passiert. Electron ist unter Windows genauso undurchsichtig wie unter macOS, weil am Ende dasselbe Chromium auf ein Canvas zeichnet. Der eigentliche Unterschied ist nicht Betriebssystem gegen Betriebssystem, sondern natives Toolkit gegen alles andere
Die Aussage, dass das Schreiben einer MCP- oder REST-Oberfläche für jede App ein separates Engineering-Projekt sei, stimmt nicht unbedingt, wenn Backend und Frontend ausreichend entkoppelt sind und die serverseitigen Aufgaben sorgfältig und allgemein entworfen wurden
Ich frage mich, ob man einen Vision-Agenten die UI „kartieren“ lassen und sie dann einem anderen Agenten als Satz von Interfaces zugänglich machen könnte, die eher wie APIs aussehen
So wie ich es verstehe, muss ein Vision-Agent aktuell sowohl wissen, dass „nächste Seite“ mehr Ergebnisse anzeigt, als auch, dass überhaupt mehr Ergebnisse geholt werden müssen
Wenn ein Agent in so etwas wie einer Testumgebung nur die UI erkundet und daraus eine einigermaßen strukturierte Beschreibung der verschiedenen UI-Elemente und Aktionen erstellt, und ein anderer Agent diese Beschreibung bekommt, würde er dann vielleicht besser abschneiden als ein Agent, der gleichzeitig die UI erkundet und die Aufgabe erledigt?
Zum Beispiel könnte „alle Reviews holen“ so definiert sein, dass man auf jeder Seite bei jeder Review-Zusammenfassung auf „ganze Review anzeigen“ klicken muss, und „auf jede Seite gehen“ könnte so definiert sein, dass man auf Seite 1 beginnt, dem Standard im Review-Tab, und dann so lange auf „Weiter“ klickt, bis der Button verschwindet
Dann müsste der zweite Agent weniger über die Erkundung nachdenken, weil er diese Technik schon hat, und der erste Agent müsste die UI in einer Testumgebung nur einmal ohne Angst vor Fehlern erkunden. Vielleicht habe ich den Beitrag komplett missverstanden, aber interessant ist es trotzdem
Am Ende muss man sich durch komplexes HTML/CSS/JavaScript arbeiten. Ob gut oder schlecht: Web-Apps mit 5–10 MiB sind nicht ungewöhnlich
Statt quasi rückwärts nachzuahmen, was die Browser-Engine tut, also „von unten nach oben“, scheint es einfacher zu sein, wie ein Mensch die visuelle Darstellung anzusehen und „von oben nach unten“ vorzugehen
Für die Erkundung bliebe zwar noch etwas Vision-Arbeit übrig, aber das wäre dann eher einfache Vision-Arbeit ohne Denkaufwand
Bild→Bild verwendet das gesamte Bild
Ich verstehe die Grundannahme nicht ganz. Wenn es um eine interne App geht, warum überhaupt Computer Use einsetzen und nicht den Agenten CLI oder MCP bauen lassen?
Natürlich ist Computer Use schlechter. Das ist ein Mittel der letzten Wahl. Wenn ich mit Zustand arbeite, der in einer DB liegt, die mir gehört, sollte ich das nicht verwenden
Dass es nur 50-mal schlechter ist, finde ich eher beeindruckend
Stimme voll zu. Beim Bau eines AI-Vision-Tools habe ich kürzlich beide Ansätze ausprobiert, und die Latenz und Kosten allgemeiner „agentischer“ Browser-Nutzung sind für Echtzeit-Consumer-Apps derzeit tödlich
Strukturierte APIs oder sogar nur Ketten von LLM-Aufrufen mit strengen JSON-Schemata sind nicht nur 40-mal günstiger, sondern auch entscheidend dafür, überhaupt ein stabiles Produkt ausliefern zu können. Computer Use ist eine coole Demo, aber die Serverrechnung bezahlt die strukturierte API
Wenn du glaubst, dass LLMs für etwas gut sind, baue dafür wohldefinierte und hochgradig deterministische Middleware auf Openrouter
Strukturierte APIs erfordern tatsächliches Denken, und heutzutage gilt Denken offenbar nicht als etwas Gutes
Vor ein paar Monaten habe ich, inspiriert von
kubectl, eine desktopctl-CLI zum Steuern von GUI-Apps gebautAuf dem Mac kombiniert sie OCR und die Accessibility API, um die UI als Markdown darzustellen und Maus- sowie Tastaturaktionen zu exponieren
Die Kernidee ist, die „schnelle“ Wahrnehmungsschleife vollständig lokal für UI-Tokenisierung und Change Detection GPU-optimiert laufen zu lassen, während die „langsame“ Steuerungsschleife LLM-Roundtrips braucht und für die CLI-Ausgabe eine tokeneffiziente Markdown-Schnittstelle nutzt
Für Controls werden relativ stabile Identifikatoren verwendet, sodass Agenten allgemeine Aktionen wie
desktopctl pointer click --id btn_saveskripten können und die UI-Tokenisierungsschleife nicht brauchenhttps://github.com/yaroshevych/desktopctl/tree/main
Gute Apps legen Informationen gut offen und sind für Klicken, Tippen usw. optimiert
Die besten GUIs nutzen Muscle Memory gut aus und sind deshalb perfekte Kandidaten, um per CLI skriptbar zu werden. Eine einfache Sequenz wie „Notes-App öffnen, Cmd+F drücken, Suchbegriff eingeben, Ergebnisliste lesen“ kann dann zu einem einzelnen Bash-Befehl werden, den ein AI-Agent aufruft
Dem ganzen Konzept von „Computer Use“ gegenüber bin ich schon immer skeptisch gewesen. Es ist, als würde man jemanden einstellen, ihn ins Haus lassen und sagen, er dürfe im Bett schlafen, die Toilette benutzen, Essen aus dem Kühlschrank nehmen, fernsehen, und ach ja, die Kombination für den Safe liegt übrigens auch hier
Nur dass die Person, die man eingestellt hat, ein Affe ist
Websites, die derzeit Claude Code oder andere AI-Agenten blockieren, führen einen Kampf, den sie verlieren werden
Computer Use steckt noch in den Anfängen, und was die breite Nutzung derzeit verhindert, scheint die Zahl der benötigten Token zu sein. Wenn ein Agent zehn CLI-Befehle ins Leere ausprobiert, bevor er den richtigen findet, ist uns das fast egal
Aber bei Vision-Agenten wie Browser- oder Computer-Use fehlt uns die Geduld, 20 Minuten darauf zu warten, dass am Ende vielleicht ein einziger Button geklickt wird. Wenn Token billiger und schneller werden, ist es gut möglich, dass Modelle UI-Interfaces irgendwann so natürlich nutzen wie CLI