Google hat Gemini Computer Use am 30. Oktober 2026 in die allgemeine Verfügbarkeit (GA) überführt. Das Werkzeug, mit dem Gemini-Modelle Bildschirme per Screenshot „sehen“ und daraus Mausklicks, Tastatureingaben oder Navigationsschritte ableiten, ist damit nicht mehr als Vorschau gekennzeichnet. Es steht laut Changelog der Gemini API sowohl in der Interactions API als auch in der GenerateContent API zur Verfügung. Für Entwickler, die Browser-, Android- oder Desktop-Agenten bauen wollen, ändert sich damit vor allem der Status – die eigentliche Arbeit bleibt auf ihrer Seite.
Denn Computer Use führt selbst nichts aus. Das Modell schlägt Aktionen vor, die eigene Anwendung setzt sie um. Wer das Werkzeug produktiv nutzen will, muss deshalb die Ausführungsumgebung, die Sicherheitsabfragen und das Logging selbst bauen.
Was Gemini Computer Use ist und wie es funktioniert
Die offizielle Dokumentation beschreibt eine Schleife aus vier Schritten:
- Anfrage senden: Die Anwendung schickt den Auftrag des Nutzers, die Konfiguration des Werkzeugs (etwa die Zielumgebung) und einen Screenshot des aktuellen Bildschirms an das Modell.
- Antwort auswerten: Das Modell liefert einen
function_callmit einer UI-Aktion, etwa einem Klick, Scrollen oder einer Tastatureingabe. Bei Gemini-4- und Gemini-3.x-Modellen enthält die Antwort zusätzlich ein Feldintent, das die Absicht hinter dem Schritt erklärt. Optional kommt einesafety_decisionhinzu. - Aktion ausführen: Der eigene Code rechnet die Koordinaten um und führt die Aktion aus, in den Beispielen von Google mit Playwright im Browser. Die Koordinaten liegen auf einem normierten Raster von 0 bis 999 und müssen auf die tatsächliche Bildschirmgröße skaliert werden.
- Neuen Zustand zurückgeben: Nach der Aktion schickt die Anwendung einen neuen Screenshot samt aktueller URL als
function_resultzurück, und das Modell entscheidet über den nächsten Schritt.
Das wiederholt sich, bis die Aufgabe erledigt ist oder abgebrochen wird. Eine Bildschirmgröße muss man in der Anfrage nicht angeben. Für Python setzt Google das SDK google-genai ab Version 2.7.0 voraus.
Drei Umgebungen, unterschiedliche Aktionen
Gemini 4 und die Gemini-3.x-Modelle unterstützen drei Umgebungen, die im Werkzeug über den Parameter environment gewählt werden:
- Browser: 20 vordefinierte Aktionen, darunter verschiedene Klickarten, Tippen, Drag-and-drop, Tastenkombinationen, Scrollen sowie
navigate,go_backundgo_forward. - Mobil (Android-optimiert): zehn Aktionen, unter anderem
open_app,list_appsundlong_press. - Desktop: Cursor-Befehle auf Betriebssystemebene, im Wesentlichen die Browser-Aktionen ohne die Navigationsbefehle.
Vordefinierte Aktionen lassen sich mit excluded_predefined_functions abschalten und durch eigene Funktionen ersetzen. Google zeigt als Beispiel eine Funktion yield_to_user, mit der der Agent die Kontrolle an den Menschen zurückgibt, etwa wenn ein Zwei-Faktor-Code nötig ist.
Welche Modelle Computer Use unterstützen
Laut Dokumentation funktioniert das Werkzeug mit vier Modellen:
- Gemini 4 Argon (
gemini-4-argon) – laut Google das leistungsfähigste Modell, für komplexe Abläufe. - Gemini 3.8 Flash (
gemini-3.8-flash) – von Google ausdrücklich als empfohlenes Modell für Computer Use genannt. - Gemini 3.5 Flash-Lite (
gemini-3.5-flash-lite) – die günstigere Variante mit geringer Latenz. - Gemini 3 Flash Preview (
gemini-3-flash-preview) – weiterhin als Vorschaumodell geführt.
Zur Abrechnung sagt die Preisseite der Gemini API: Im kostenlosen Kontingent ist Computer Use nicht verfügbar, im bezahlten wird es wie normale Token zum jeweiligen Modellpreis berechnet. Einen eigenen Aufpreis für das Werkzeug gibt es demnach nicht. Weil jede Runde einen Screenshot enthält, können lange Abläufe trotzdem viele Eingabe-Token erzeugen – das sollte man vor dem Produktivbetrieb mit echten Aufgaben messen.
Sicherheitsmechanismen: Richtlinien, Bestätigungen, Prompt-Injection-Erkennung
Den größten Teil der Dokumentation nimmt die Sicherheit ein, und das zu Recht. Google schreibt selbst, Computer Use könne „Fehler und Sicherheitslücken enthalten“, und rät, das Werkzeug bei wichtigen Aufgaben eng zu beaufsichtigen und nicht für kritische Entscheidungen, sensible Daten oder nicht korrigierbare Aktionen einzusetzen.
Eingebaut sind drei Ebenen:
- Sicherheitsentscheidungen: Ein internes System stuft vorgeschlagene Aktionen als normal, als bestätigungspflichtig (
require_confirmation) oder als blockiert ein. Bei einer Bestätigungspflicht muss die Anwendung den Nutzer fragen und dessen Zustimmung mitsafety_acknowledgementzurückmelden. - Richtlinienkategorien: Sieben Kategorien steuern, wann eine Bestätigung nötig ist – Finanztransaktionen, Änderungen sensibler Daten, Kommunikation wie E-Mails oder Chatnachrichten, das Anlegen von Konten, allgemeine Datenänderungen, Cookie- und Einwilligungsdialoge sowie das Akzeptieren von Nutzungsbedingungen. Einzelne Kategorien lassen sich über
disabled_safety_policieslockern. Google weist aber darauf hin, dass das Modell trotzdem eine Bestätigung verlangen kann und die Anwendung das immer behandeln muss. - Prompt-Injection-Erkennung: Ab Gemini 3.5 Flash-Lite kann das Werkzeug Screenshots auf versteckte Anweisungen wie „Ignoriere alle vorherigen Befehle“ prüfen und die Ausführung dann blockieren. Diese Funktion ist allerdings opt-in und standardmäßig ausgeschaltet; aktiviert wird sie mit
enable_prompt_injection_detection.
Gerade der letzte Punkt ist für die Praxis wichtig. Ein Agent, der fremde Webseiten liest, sieht zwangsläufig Inhalte, die Angreifer kontrollieren können. Dass die Erkennung nicht standardmäßig aktiv ist, bedeutet: Wer sie nicht ausdrücklich einschaltet, verzichtet auf diese Schutzschicht.
Was Entwickler vor dem Einsatz beachten sollten
Googles eigene Best Practices lesen sich wie eine Checkliste für jeden Computer-Use-Agenten, unabhängig vom Anbieter:
- Sandbox: Den Agenten in einer isolierten VM, einem Container oder zumindest einem eingeschränkten Browserprofil laufen lassen. Google verweist auf eine Docker-basierte Referenzimplementierung.
- Mensch in der Schleife: Bestätigungsanfragen nicht automatisch durchwinken und eigene Regeln per Systemanweisung festlegen, etwa vor dem Absenden von Formularen oder Nachrichten.
- Allowlists: Erlaubte Ziele begrenzen; eine Allowlist ist laut Google sicherer als eine Blocklist.
- Logging: Prompts, Screenshots, vorgeschlagene Aktionen, Sicherheitsentscheidungen und tatsächlich ausgeführte Aktionen protokollieren.
- Saubere Umgebung: Jede Aufgabe möglichst aus einem bekannten Ausgangszustand starten, weil unerwartete Pop-ups das Modell verwirren können.
Die Liste macht deutlich, wo die Verantwortung liegt. Das Modell liefert Vorschläge und Risikohinweise; ob ein Klick auf „Kaufen“ oder „Senden“ tatsächlich passiert, entscheidet der Code des Entwicklers.
Einordnung
Computer Use hat bei Google einen längeren Weg hinter sich. Laut Changelog startete eine Vorschau mit Gemini 2.5 im Oktober 2025, im Januar 2026 folgten Gemini-3-Vorschaumodelle und im Juni 2026 die Vorschau für Gemini 3.5 Flash mit den heute dokumentierten Funktionen wie Intents, drei Umgebungen, Richtlinien und Prompt-Injection-Erkennung. Die GA-Freigabe ist damit eher ein Abschluss als ein großer Funktionssprung.
Der Markt für solche Agenten ist inzwischen dicht besetzt. OpenAI bietet mit GPT-6.1 Terra ein eigenes Modell für Computer-Aufgaben an, und auch GitHub Copilot steuert inzwischen den Desktop. Belastbare Vergleiche zwischen den Anbietern liefert Googles Ankündigung nicht; eigene Benchmarks oder Erfolgsquoten nennt die Dokumentation nicht.
Für Teams, die bisher wegen des Vorschau-Status gezögert haben, ist die GA-Freigabe ein Signal, dass Google die Schnittstelle als stabil betrachtet. An den grundsätzlichen Risiken ändert sie nichts: Ein Agent, der Bildschirme liest und Klicks auslöst, bleibt anfällig für manipulierte Inhalte und Fehlinterpretationen. Wer Gemini Computer Use einsetzt, sollte die Prompt-Injection-Erkennung einschalten, Bestätigungen ernst nehmen und den Agenten klein anfangen lassen – in einer Sandbox, mit klar begrenzten Aufgaben.



