Browser-Agent-Architektur: Grounding vom Reasoning trennen
Jeder Browser-Agent in Produktion ruft ein Vision-Modell mit Screenshots auf. Dieser Aufruf erledigt zwei Dinge gleichzeitig. Er entscheidet, was der Agent als Nächstes tun soll, und er liest aus dem Screenshot heraus, wo genau geklickt werden muss.
Sie bezahlen Frontier-Tarife für beides. €0,01 bis €0,05 pro Call, 20 bis 50 Calls pro Agentenlauf. Bei 1.000 Läufen pro Tag landet die Vision-Rechnung schnell bei €6.000 bis €75.000 im Monat.
Die zweite Aufgabe ist kein Reasoning-Problem. Sie ist ein Parsing-Problem mit einem klaren Schema: anklickbare Elemente, Bounding Boxes, Beschriftungen. Strukturierte Ausgabe, deterministisch lösbar.
Der versteckte Kostenposten
Vision-Calls in einem Browser-Agent erledigen zwei getrennte Jobs: Sie entscheiden über die nächste Agenten-Aktion und sie parsen Pixel-Koordinaten für den Klick. Frontier-VLMs werden für beides zu Frontier-Tarifen abgerechnet. Den Parsing-Job kann ein lokales 2-Milliarden-Modell für null Cent pro Call übernehmen, mit höherer Klick-Genauigkeit als GPT-4o.
In den meisten Browser-Agent-Stacks fließen mehr als die Hälfte der Vision-Token in den Grounding-Schritt, also in den Teil, der ein Parser-Job ist. Diese Position explodiert bei Skalierung.
Das ist nicht der Preis, der in der API-Tabelle steht. Das ist der Posten, der am Monatsende auf der Cloud-Rechnung auftaucht, sobald der Agent in Produktion läuft.
Zum Vergleich: Ein eigenes spezialisiertes 2-Milliarden-Parameter-Modell für Browser-Grounding kostet €4 an Compute für ein Drei-Stunden-Training auf einer gemieteten L40S-GPU. Einmal. Danach läuft es lokal, kostet null pro Call und kommt in 2 GB RAM auf einem MacBook Air auf 1,8 Sekunden Inferenzzeit.
Vendor-Lock-in läuft nicht da, wo Sie denken
Auf der Reasoning-Schicht ist Anbieterwechsel Standard. Jedes Engineering-Team hat den Switch zwischen Anthropic, OpenAI und Google in der Tasche. Diese Schicht ist liquide.
Lock-in läuft über den Grounding-Schritt. Dieser Teil wird pro Schritt für jeden Lauf abgerechnet, und er taucht in keiner Build-versus-Buy-Diskussion auf, weil er als Teil des Modells wahrgenommen wird. Genau dort sitzt der Posten, der das Wechseln teuer macht, und zwar nicht weil das Reasoning-Modell schwer zu ersetzen wäre, sondern weil das Grounding-Verhalten nach einer Migration neu validiert werden müsste.
Die Architekturentscheidung
Frontier-Vision-Modelle sind Generalisten. Sie können OCR, Diagrammlesen, Dokumentenlayout, Produktfotos. UI-Grounding bekommt einen Bruchteil der Trainingsverteilung.
Ein 2-Milliarden-Parameter-Spezialist, ausschließlich auf UI-Screenshots trainiert, schlägt einen 200-Milliarden-Generalisten bei genau diesem einen Job. Die Zahlen: GPT-4o erreicht 18,3% auf ScreenSpot-v2, dem Standard-Benchmark für Klick-Grounding. Ein offenes 2-Milliarden-Modell namens browserground erreicht 45,3% auf demselben Benchmark. Also 2,5-mal mehr Genauigkeit bei einer hundertfach kleineren Modellgröße.
Wenn Sie den Vision-Call aufteilen, ändern sich drei Dinge auf einmal:
- Die Per-Schritt-Token-Kosten für Vision fallen auf null. Der Grounding-Schritt läuft lokal auf einem MacBook Air.
- Die JSON-Validitätsrate erreicht 100%. Der Spezialist ist auf das Schema trainiert.
- Agent-Traces werden auditierbar. Die strukturierte Grounding-Ausgabe ist lesbar, bevor das Reasoning-Modell sie verarbeitet.
Drei Fragen an Ihr Team
- Wie viel Token-Spend fließt in unseren Agenten-Workflows auf Vision-Calls? Welcher Anteil davon ist Grounding (Parsing), welcher ist Reasoning?
- Welcher Anteil der Agentenausfälle geht auf falsche Klick-Koordinaten zurück, also auf das Parsing-Problem, nicht auf falsche Entscheidungen?
- Was würde es kosten, den Grounding-Schritt durch ein lokales 2-Milliarden-Modell auf einem MacBook Air zu ersetzen?
Wenn die Antwort auf Frage 1 zeigt, dass mehr als die Hälfte des Vision-Spends Grounding ist (in den meisten Stacks ist das so), dann ist die Architekturentscheidung diese Woche fällig, nicht nächstes Quartal.
Der Markt zieht nach
Die Frontier-Anbieter werden eigene kleine Grounding-Modelle innerhalb der nächsten sechs bis zwölf Monate ausliefern. Das ist absehbar. Sie müssen nicht warten. Ein Open-Source-Modell, das den Job heute erledigt, existiert bereits: browserground läuft Apache-2.0-lizenziert auf Hugging Face, ist per npm install -g browserground installierbar und drop-in für browser-use, Skyvern und Claude Computer Use.
Der Kostenposten verschwindet nicht durch Verhandlung mit dem Anbieter. Er verschwindet durch das Aufteilen des Aufrufs.
Ich baue die Split-Layer. browserground ist die Open-Source-Referenz. Modell: huggingface.co/renezander030/browserground. Code: github.com/renezander030/browserground. npm: browserground (npm install -g browserground). Apache-2.0. Plugin-Integration für Claude Code und Codex CLI. PRs willkommen, vor allem für Eval-Cases, in denen es daneben liegt.