Gemini Computer Use API: GA-Leitfaden zu Preisen und Sicherheit

Google hat Gemini Computer Use am 30. Oktober 2026 allgemein verfügbar gemacht. Die Ankündigung selbst bestand allerdings nur aus einem zweizeiligen Changelog-Eintrag: GA für die Interactions- und GenerateContent-APIs, kein neues Modell, keine Preisänderung. Für Teams im Produktionseinsatz ist die entscheidende Frage daher eine andere: Bleibt es beim gleichen Screenshot-Loop und der kostenpflichtigen Token-Abrechnung – und kann man jetzt guten Gewissens darauf aufbauen?

Der GA-Status beseitigt den Einwand der Preview-Stabilität. Die Kosten für Screenshots und den Umgang mit sicherheitskritischen Aktionen bleiben jedoch eure Verantwortung.

Was sich mit dem GA-Start am 30. Oktober tatsächlich ändert

Der GA-Eintrag vom 30. Oktober 2026 sagt im Kern nur eines: Das Computer-Use-Tool ist jetzt sowohl über die Interactions API als auch über die GenerateContent API allgemein verfügbar. Der Changelog nennt in diesem Eintrag keine neuen Modell-IDs, kein neues Action-Schema, keine Rate Limits und keine Preise.

Geändert hat sich also vor allem der Status, nicht die Funktionsweise. Preview-Integrationen, die computer_use zusammen mit einem Screenshot-Loop verwenden, laufen weiter. Die Einschränkung durch den Preview-Status entfällt, für Zuverlässigkeit und Sicherheit müsst ihr aber weiterhin selbst sorgen. Unverändert bleiben auch die wichtigsten Rahmenbedingungen: Die Abrechnung ist weiterhin ausschließlich im Paid-Tier möglich und erfolgt als reguläre Token-Nutzung, jeden Klick führt eure Anwendung selbst aus und bei jeder folgenreichen Aktion braucht ihr eine Bestätigung.

Wer auf der Gemini-2.5-Computer-Use-Preview aufgebaut hat, die am 7. Oktober 2025 angekündigt wurde, muss also nicht alles neu schreiben. Richtet die Anfragen auf das GA-Tool in der Interactions API (https://generativelanguage.googleapis.com/v1/interactions im REST-Beispiel) oder in GenerateContent, verwendet euren bisherigen Playwright- oder Browserbase-Executor weiter und testet die Sicherheitsentscheidungen erneut. Die Referenzimplementierung nutzt im README-Beispiel weiterhin standardmäßig gemini-3.6-flash. Für den Produktionseinsatz solltet ihr deshalb eine ausdrücklich unterstützte GA-Modell-ID festlegen, statt euch auf diesen Default zu verlassen.

So funktioniert der Agenten-Loop

Die Gemini Computer Use API bedient euren Rechner nicht direkt. Eure Anwendung übergibt einen Screenshot und einen Prompt. Das Modell liefert daraufhin eine vorgeschlagene UI-Aktion als function_call. Euer Code führt sie aus, erstellt einen neuen Screenshot und schickt ihn zurück. Dieser Ablauf wiederholt sich, bis die Aufgabe erledigt ist, ein Fehler auftritt, eine Sicherheitsprüfung stoppt oder der Nutzer abbricht.

Der minimale Python-Weg benötigt laut Computer-Use-Dokumentation mindestens google-genai in Version 2.7.0 sowie Playwright für die Browsersteuerung:

pip install google-genai playwright
playwright install chromium

Das Dokumentationsbeispiel startet Chromium mit headless=False, einem Viewport von 1440 x 900 und der Startseite https://www.google.com. Die Anfrage setzt "environment": "browser", das Modell gemini-3.8-flash und den Tool-Typ computer_use. Die vollständigen Agent-Loop-Beispiele für Python, JavaScript, Java und Go verwenden als Beispiel eine Begrenzung auf 5 Durchläufe – das ist kein API-weites Kontingent.

Bei den Koordinaten passieren in der Praxis die meisten Fehler. Das Modell liefert x und y normalisiert auf einen Bereich von 1000 x 1000, normalerweise als Ganzzahlen zwischen 0 und 999. Die Umrechnung in echte Pixel müsst ihr selbst übernehmen:

actual_x = int(x / 1000 * screen_width)
actual_y = int(y / 1000 * screen_height)

Die Display-Abmessungen werden nicht mit der Anfrage übermittelt. Bei Antworten von Gemini 4 und Gemini 3.x enthält jede Aktion außerdem einen intent-String, der die Auswahl des Modells erklärt, sowie optional eine safety_decision.

Unterstützte Modelle und Umgebungen

Die aktuelle Computer-Use-Dokumentation nennt vier Modelle mit Unterstützung für Computer Use. Google empfiehlt Gemini 3.8 Flash als Standard für UI-Interaktionen und zuverlässige Tool-Aufrufe. Gemini 4 Argon ist für besonders anspruchsvolle agentische Workflows ausgelegt.

Die GitHub-Referenz (google-gemini/computer-use-preview, Apache-2.0) führt dieselbe Aufgabe auf zwei Arten aus: lokal mit Playwright Chrome oder in einem Browserbase-Cloud-Browser. Der CLI-Aufruf lautet python main.py --query "Go to Google and type 'Hello World' into the search bar" --env="playwright". --initial_url zeigt standardmäßig auf https://www.google.com, während --highlight_mouse bei der visuellen Fehlersuche hilft. Ein bekanntes Problem solltet ihr kennen, bevor ihr eine Stunde vergeblich sucht: Playwright kann native HTML-<select>-Dropdowns unter Umständen nicht erfassen, weil das Betriebssystem sie außerhalb der Seite rendert. Das README empfiehlt dafür Browserbase statt einer CSS-/JS-Injektion.

Über die Thinking Levels könnt ihr Aktionsqualität und Geschwindigkeit gegeneinander abwägen. Niedrigere Stufen reichen meist für standardisierte Formular- und Testabläufe, während sich ein höherer Aufwand bei mehrdeutigen UI-Zuständen lohnt. Die Dokumentation nennt weder Stufennamen noch Latenzwerte. Behandelt die Einstellung deshalb als Stellschraube, die ihr mit euren eigenen Workflows per A/B-Test prüfen müsst.

Was Gemini Computer Use kostet

Für Computer Use gibt es keinen kostenlosen Tarif. Auf der Preisseite steht unter „Pricing for tools“ ausdrücklich: Computer Use ist im Free-Tier nicht verfügbar und wird im Paid-Tier als reguläre Token-Nutzung abgerechnet, beispielsweise zu den Preisen von Gemini 3.8 Flash. Einen separaten Computer-Use-Aufschlag gibt es nicht; die Nutzung wird als reguläre Input- und Output-Tokens zu den Tarifen des jeweiligen Basismodells berechnet.

Genau diese unscheinbare Regel sorgt häufig für Kostenüberraschungen. Jeder Durchlauf berechnet den Screenshot-Input, den mitgeschickten Verlauf und die Ausgabe der Aktion. Ein Formular mit 20 Schritten bedeutet also 20 Vision-Aufrufe – plus eventuelle Wiederholungen. Eine grobe Schätzung lautet turns x (screenshot + history input tokens + action output tokens) x base-model rate. Die Preisseite nennt für Flash Standard bis zum 31. Dezember 2026 $0.75 pro 1M Input-Tokens und $3.75 pro 1M Output-Tokens. Batch und Flex haben niedrigere Tokenpreise, Computer Use bleibt aber auch dort Paid-only.

Jede Runde schickt einen Screenshot zurück, der als Token abgerechnet wird – zufällige Klicks treiben also nicht nur die Seite ins Chaos, sondern auch die Rechnung hoch. — @vastplan, AI deployment account, Beitrag

Plant das Budget entlang des Loops: Begrenzt die Zahl der Durchläufe, die Screenshot-Auflösung und die Wiederholungen direkt im Code.

Die Sicherheitslogik müsst ihr selbst integrieren

Sicherheit ist bei Computer Use ein Dienst rund um das Modell, keine Funktion, die euch die API vollständig abnimmt. Gemini 4 und Gemini 3.x bewerten jede vorgeschlagene Aktion anhand von sieben integrierten Richtlinienkategorien und können statt einer ausführbaren Aktion require_confirmation oder „blocked“ zurückgeben. Eure Anwendung muss diese Antwort jedes Mal korrekt verarbeiten.

Liefert das Modell eine safety_decision mit decision: require_confirmation und einer Erklärung wie „must check check-box“, ist der Ablauf in der Dokumentation eindeutig: Fragt den Menschen, lasst ihn fortfahren oder abbrechen und fügt bei einer Freigabe im nächsten function_result ein safety_acknowledgement mit dem Ergebnis CONTINUE oder TERMINATE ein. disabled_safety_policies drückt dabei lediglich eine Präferenz aus – im Beispiel wird data_modification deaktiviert –, eine Bestätigung kann trotzdem erforderlich bleiben.

Die Erkennung von Prompt Injection ist optional und standardmäßig deaktiviert. Aktiviert wird sie mit enable_prompt_injection_detection: true; verfügbar ist sie ab Gemini 3.5 Flash-Lite. Die Funktion durchsucht Screenshots nach versteckten Anweisungen wie „ignore previous commands“ und blockiert die Ausführung, wenn sie solche Inhalte findet. Google empfiehlt außerdem eine Sandbox in einer VM, einem Docker-Container oder einem dedizierten Browserprofil mit eingeschränkten Berechtigungen. Hinzu kommen Allow- oder Blocklists für die Navigation, Eingabevalidierung, Content-Guardrails, ein stabiler GUI-Zustand aus einem sauberen Start und eine Protokollierung von Prompts, Screenshots, vorgeschlagenen function_call-Aktionen, Sicherheitsantworten und tatsächlich ausgeführten Aktionen.

Die Sicherheitsanweisungen im Beispiel nennen zahlreiche Aktionen, die niemals autonom ausgeführt werden dürfen: Nutzungsbedingungen oder Cookie-Banner akzeptieren, CAPTCHAs lösen, Käufe abschließen oder Geld bewegen, E-Mails oder Beiträge versenden, Gesundheits- oder Finanzdaten sowie SSNs und Kartennummern verarbeiten, Dateien herunterladen, Daten teilen, Verlauf oder Passwörter lesen, sich anmelden, eine Identität vortäuschen oder bei einem festgefahrenen Ablauf endlos weitermachen. Das Produktionsmuster lautet daher: Der Agent darf vorbereiten, muss aber vor dem finalen „Send“, „Submit“, „Confirm purchase“ oder „Share“ anhalten.

Jetzt produktiv einsetzen? Checkliste und Vergleich

Mit dem GA-Status ist Computer Use eine realistische Option für Browser-Automatisierung, Formularausfüllung, automatisierte UI-Tests und Recherche auf Produktseiten. Es bleibt aber ein screenshotbasierter Agent, der Benutzeroberflächen falsch interpretieren, bei langen Abläufen den Kontext verlieren und durch Wiederholungen viele Tokens verbrauchen kann.

Bevor ihr das Tool für echte Nutzer freischaltet:

• Explizite GA-Modell-ID festlegen
• Durchläufe begrenzen und eine Erkennung von Leerlaufschleifen ergänzen
• Ein sandboxed Browserprofil oder einen Container mit Allowlist verwenden
• Vor jeder irreversiblen Aktion eine menschliche Bestätigung verlangen
• Prompt-Injection-Erkennung aktivieren
• Screenshots und Sicherheitsentscheidungen protokollieren
• Jede Aufgabe in einem bekannten, sauberen Zustand starten
• Checkout- und Login-Abläufe mit aktivierten Bestätigungen testen

Googles Model Card nennt Benchmark-Ergebnisse für die Computer-Use-Linie 2.5, nicht für die aktuellen GA-Modelle. Betrachtet sie deshalb als Kontext zur Modellfamilie für Browser-Aufgaben:

OSWorld für die Desktop-Steuerung wurde in dieser Model Card noch nicht unterstützt; für Claude werden dagegen 61.4% als selbst gemeldeter Wert genannt. Die aktuelle Dokumentation führt Desktop inzwischen als unterstützt auf. Steuerung auf Betriebssystemebene ist jedoch neuer und weniger erprobt als Browser-Workflows.

Ein Browserbase-Template mit Stagehand (npx create-browser-app --template gemini-cua) ist ein möglicher gehosteter Einstieg, wenn die lokale Playwright-Darstellung Probleme macht. Die Rechnung und die Vertrauensgrenze bleiben in beiden Fällen eure Verantwortung.

FAQ

Hat Gemini Computer Use mit dem GA-Start neue Endpunkte bekommen?

Im GA-Eintrag wurde kein neuer Endpunkt angekündigt. Google führt dasselbe Tool sowohl für die Interactions API als auch für die GenerateContent API auf. Verwendet denselben Executor mit dem GA-Tool und einer expliziten Modell-ID.

Ist Gemini Computer Use kostenlos oder kostenpflichtig?

Nur im Paid-Tier. Laut offizieller Preisseite ist Computer Use im Free-Tier nicht verfügbar und wird zu den regulären Tarifen des zugrunde liegenden Modells abgerechnet. Jeder Screenshot und jede Aktion erzeugt im Loop abrechenbare Tokens.

Welches Gemini-Modell sollte ich für Computer Use verwenden?

Google empfiehlt gemini-3.8-flash für präzise UI-Interaktionen und zuverlässige Tool-Aufrufe. Für latenzarme Aufgaben mit hohem Volumen eignet sich gemini-3.5-flash-lite, für komplexe agentische Workflows gemini-4-argon. Preview-IDs solltet ihr im Produktionseinsatz vermeiden.

Steuert Gemini einen kompletten Desktop oder nur den Browser?

Die GA-Dokumentation nennt Unterstützung für Browser, mobile Android-Apps und Cursor-Steuerung auf Desktop-Betriebssystemen. Browser-Workflows sind ausgereifter und besser durch Benchmarks belegt. Desktop-Steuerung sollte als neuer betrachtet und besonders strikt sandboxed werden.

Muss ich die Klicks selbst ausführen?

Ja. Das Modell schlägt lediglich einen function_call mit normalisierten Koordinaten von 0 bis 999 und einer Intent-Angabe vor. Euer Playwright-, Browserbase- oder nativer Executor bewegt die Maus, tippt, erstellt Screenshots und liefert das Ergebnis zurück.

Wie funktionieren Sicherheitsbestätigungen im Code?

Prüft jede Antwort auf safety_decision. Bei require_confirmation fragt ihr den Nutzer und sendet anschließend im nächsten function_result ein safety_acknowledgement mit CONTINUE oder TERMINATE. Diese Prüfung bleibt notwendig, auch wenn ihr eine Richtlinie deaktiviert habt.

Weiterführend: Preise von Gemini 3.8 Flash und Kosten erfolgreicher Agent-Aufgaben, Gemini 4 Argon: API-Preise und Verfügbarkeit, CUA-Lite-Test für Computer-Use-Agenten.