Symptom: Ihr Gemini-Computer-Use-Prototyp funktioniert, aber im Budget stehen bislang nur Modellaufrufe.
Schnellste Lösung: Kalkulieren Sie zusätzlich Ausführungsumgebung, Bildschirm- und Aktionsschleifen, Wiederholungen, menschliche Freigaben und Isolation. Für reine Browseraufgaben prüfen Sie zuerst eine schlanke, isolierte Umgebung; für macOS-native Apps oder Systeminteraktionen bewerten Sie einen Cloud-Mac.
Dieser Leitfaden richtet sich an Entwickler, die Gemini 3.5 Flash Computer Use vom Prototyp in den laufenden Betrieb bringen wollen.
QA- und Plattformteams erhalten ein Raster, um Fehlerbehandlung, Freigaben und Wartung in ihr Budget aufzunehmen.
Wenn Ihre Tests macOS-Anwendungen betreffen, lesen Sie weiter, um zu entscheiden, wann eine Mac-Ausführungsumgebung gerechtfertigt ist.
Gemini 3.5 Flash Computer Use: Kostenmodell
Computer Use ist kein fertig gehosteter Desktop, den Sie mit einem Modellaufruf einschalten. Die Anwendung Ihres Agenten muss Aktionen entgegennehmen und in einer geeigneten Zielumgebung ausführen; anschließend übergibt sie den neuen Zustand wieder an den Modellablauf. Google beschreibt dieses Werkzeug und die erforderliche Implementierung im offiziellen Leitfaden zu Computer Use. Die offizielle Ankündigung zu Gemini 3.5 Flash Computer Use belegt die Unterstützung der Funktion, aber nicht, dass damit Browser, Desktop oder Mobilgerät als verwaltete Laufzeit bereitgestellt würden.
Für ein belastbares Budget trennen Sie daher diese Kostenblöcke:
- Modellverarbeitung: abgerechnete Eingaben und Ausgaben nach den jeweils geltenden Regeln.
- Agentenlauf: Rechenzeit, Browser- oder Desktop-Instanz, Speicherung und Netzwerkbetrieb.
- Beobachtungs-Aktions-Schleife: Bildschirmzustand an das Modell, empfangene Aktion, Ausführung und erneute Zustandsaufnahme.
- Fehlerbehandlung: erneute Aufrufe, zusätzliche Laufzeit und Wiederherstellung nach unterbrochenen Sitzungen.
- Menschliche Prüfung und Betrieb: Freigaben für riskante Aktionen, Protokollierung, Wartung und Isolation.
Der häufigste Kalkulationsfehler ist, diese Positionen in einen vermeintlichen „Preis pro Aufgabe“ zu drücken, bevor feststeht, was eine Aufgabe tatsächlich umfasst. Legen Sie stattdessen je Szenario fest, welche Eingaben, Rückgaben, Umgebungen und Prüfungen anfallen. Nutzen Sie für Preise ausschließlich die aktuelle offizielle Preisseite der Gemini API. Übertragen Sie keine Preise aus älteren Beiträgen oder von anderen Modellen.
Modellaufrufe und Bildschirmdaten
Eine einzelne Aufgabe kann aus mehreren Modellanfragen bestehen. Der Agent erhält zunächst einen Zustand, gibt eine Aktion zurück, die Anwendung führt sie aus und liefert danach den geänderten Zustand zurück. Wenn weitere Schritte nötig sind, wiederholt sich der Ablauf. Für Ihre Kalkulation ist somit nicht nur die Zahl der Aufgaben entscheidend, sondern auch die Zahl der tatsächlich ausgeführten Runden und die Größe der jeweiligen Anfragen und Antworten.
Screenshots sind nicht einfach mit einem Textbefehl gleichzusetzen. Welche Bilddaten das Modell erhält und wie sie in die Verarbeitung eingehen, hängt von der Implementierung und den aktuellen Regeln ab. Prüfen Sie dazu die Dokumentation zur Bildverarbeitung sowie Googles Hinweise zum Zählen und Auswerten von Tokens. Ermitteln Sie Werte mit Ihren eigenen repräsentativen Anfragen. Schätzen Sie nicht aus der Bildauflösung allein ab, was abgerechnet wird.
Bilden Sie für jede Aufgabe eine nachvollziehbare Rechenzeile:
Aufgabenmenge × tatsächlich gemessene Modellnutzung je Aufgabe × geltende Preise
+ Laufzeit der Ausführungsumgebung + Wiederherstellung und Prüfung + Wartungsaufwand
Der Ausdruck ist bewusst kein Pauschalpreis: Die Nutzung pro Aufgabe kann sich ändern, wenn die Oberfläche einen anderen Zustand zeigt, eine Anmeldung abläuft oder der Agent zusätzliche Schritte ausführen muss. Notieren Sie neben jeder eingesetzten Preis- oder Verbrauchsangabe, aus welcher offiziellen Dokumentation oder Messung sie stammt und wann Sie sie zuletzt geprüft haben. Bei Preis- oder Modelländerungen beginnen Sie nicht mit einer alten Beispielrechnung, sondern laden aktuelle Werte aus den Modellinformationen und der Preisseite nach.
Auch Limits sind für die Planung relevant, selbst wenn sie nicht als einzelner Kostenposten erscheinen. Überschreitet eine Anwendung verfügbare Raten oder Kontingente, können Warteschlangen, verzögerte Tests oder fehlgeschlagene Aufgaben entstehen. Prüfen Sie die jeweils geltenden Ratenbegrenzungen und unterscheiden Sie in Ihrem Budget zwischen Modellverbrauch, nutzungsabhängigen Gebühren und den Auswirkungen einer begrenzten Verarbeitungskapazität. Für die Zuordnung der API-Kosten zur Abrechnung ist außerdem die offizielle Abrechnungsdokumentation maßgeblich.
Ausführungsumgebung nach Zieloberfläche
Die Umgebung ist eine eigene Kostenposition, weil das Modell Aktionen nicht in einem beliebigen virtuellen Gerät ausführt. Ihre Software muss den Empfang, die Ausführung und die Rückmeldung der Aktionen zuverlässig verbinden. Wählen Sie die Umgebung nach dem tatsächlichen Testziel, nicht danach, welche Infrastruktur gerade bereits verfügbar ist.
| Ziel und Umgebung | Laufende Verantwortung | Wann diese Wahl passt | Typische Grenze |
|---|---|---|---|
| Isolierter Browser | Browserstart, Sitzungen, Testdaten, Netzwerkzugriff und Bereinigung | Webanwendungen, wenn keine macOS-spezifische Interaktion geprüft werden muss | Erfasst keine nativen Anwendungen und nicht automatisch das Verhalten eines vollständigen Desktops |
| Container oder virtuelle Maschine | Imagepflege, Rechte, Patches, Isolation, Ressourcen und Wiederherstellung | Wiederholbare Tests, wenn die Zielsoftware in dieser Umgebung läuft | Zusätzliche Wartung; die Umgebung bildet ein anderes Betriebssystem nicht zuverlässig nach |
| Cloud-Mac | macOS-Umgebung, Zugriffsschutz, Sitzungen, Anwendungszustand und Diagnose | Safari, macOS-native Anwendungen oder systemnahe Abläufe als tatsächliches Testziel | Laufzeit und Betrieb sind zusätzliche Kosten; für reine Browseraufgaben kann die Umgebung unnötig sein |
Der Unterschied zwischen Browser- und Desktop-Automatisierung ist nicht bloß eine Frage der Benutzeroberfläche. Bei einem Browserlauf können Sie möglicherweise eng auf eine Webanwendung begrenzen, welche Daten und Zugänge der Agent erhält. Ein Desktoplauf kann zusätzlich Dateisystem, Zwischenablage, Anwendungsfenster oder Systemdialoge berühren. Das erweitert die Anforderungen an Rechte, Protokollierung und Testdaten. Prüfen Sie daher vorab, welche Berechtigungen Ihr Ausführungsprozess wirklich benötigt und wie Sie Zugangsdaten von Testdaten trennen.
Für Browseraufgaben beginnen Sie mit einer kontrollierten Umgebung, wenn diese das Ziel realistisch abbildet. Ein vollständiger Desktop bringt keinen automatischen Vorteil, wenn die getesteten Interaktionen ausschließlich im Browser stattfinden. Umgekehrt ist ein Browsercontainer kein geeigneter Ersatz, sobald Sie das Verhalten einer nativen macOS-Anwendung oder eines Systemdialogs nachweisen müssen. Wenn Sie bei der Ausführungsarchitektur Unterstützung benötigen, nutzen Sie das Macstripe-Hilfezentrum als Anlaufstelle für Fragen zur Umgebung.
Wiederholungen, menschliche Freigaben und Betrieb
Ein erfolgreicher Lauf ist nicht zwangsläufig repräsentativ für den Betrieb. Webseiten ändern sich, Elemente werden anders angeordnet, Sitzungen laufen ab und Aktionen können einen unerwarteten Zustand erzeugen. Für jede dieser Abweichungen müssen Sie festlegen, ob der Agent erneut beobachtet, einen Schritt wiederholt, den Lauf abbricht oder eine Person einschaltet. Jede Entscheidung beeinflusst Modellnutzung und Umgebungsdauer, aber auch die Qualität der Ergebnisse.
Planen Sie Wiederholungen nicht mit einer erfundenen durchschnittlichen Quote. Erfassen Sie sie während eines realen Testlaufs und unterscheiden Sie mindestens:
- Behebbare Abweichungen: erneute Beobachtung oder begrenzte Wiederholung kann den Lauf fortsetzen.
- Unterbrochene Sitzungen: Anmeldung oder Sitzungszustand muss wiederhergestellt werden; hierfür können zusätzliche Schritte und ein menschlicher Eingriff nötig sein.
- Unsichere oder folgenreiche Aktionen: vor dem Ausführen ist eine menschliche Freigabe erforderlich oder die Aufgabe wird abgebrochen.
- Nicht reproduzierbare Fehler: der Lauf wird mit Zustandsdaten protokolliert, statt durch unbegrenzte Wiederholungen weitere Kosten zu erzeugen.
Sicherheitsprüfungen sind kein optionaler Zuschlag, den Sie erst nach dem Prototyp einführen sollten. Legen Sie fest, welche Aktionen der Agent ohne Freigabe ausführen darf, welche Sie ausdrücklich bestätigen lassen und welche Sie vollständig blockieren. Eine Bestätigung durch eine Person kostet Arbeitszeit; ein unkontrollierter Schritt kann jedoch Daten, Konten oder Testsysteme gefährden. Insbesondere sollten reale Zugangsdaten und produktive Konten nicht als bequemes Testmaterial behandelt werden. Halten Sie Berechtigungen so eng, dass ein Fehler nicht automatisch Zugriff auf nicht benötigte Ressourcen eröffnet.
Rechnen Sie außerdem mit dem Aufwand, nach einem Fehler herauszufinden, was tatsächlich passiert ist. Ohne ausreichend aussagekräftige Protokolle lässt sich oft nicht unterscheiden, ob das Modell eine ungeeignete Aktion vorgeschlagen hat, die Oberfläche nicht reagierte oder die Ausführungsumgebung einen anderen Zustand zurückgab. Protokollieren Sie deshalb pro Aufgabe die Modellanfragen, zurückgegebenen Aktionen, ausgeführten Schritte, relevanten Zustandswechsel, Wiederholungen und menschlichen Eingriffe. Entfernen oder schützen Sie sensible Inhalte in Screenshots und Protokollen. Für DSGVO-konforme Verarbeitung sind insbesondere Zugriff, Aufbewahrung, Löschung und möglicher Personenbezug zu klären; ein Bildschirmbild kann mehr offenlegen als der eigentliche Testschritt.
Budget nach Szenario aufsetzen
Eine brauchbare Kostenschätzung beginnt mit Ihren eigenen Aufgaben, nicht mit einer allgemeinen Zahl aus einem Blogbeitrag. Trennen Sie die Anzahl geplanter Aufgaben von der gemessenen Nutzung pro Aufgabe und führen Sie variable Werte als offene Eingaben. Das folgende Raster zeigt, welche Daten Sie je Betriebsform sammeln sollten; konkrete Preise sind absichtlich nicht vorgegeben.
| Szenario | Eingaben für Ihre Schätzung | Ausführungsumgebung | Zusätzliche Kostenvariablen |
|---|---|---|---|
| Gelegentliche Erprobung | tatsächlich geplante Aufgaben, gemessene Modellnutzung und Zahl der Beobachtungs-Aktions-Runden | einzelne kontrollierte Browser- oder Desktop-Testläufe | Einrichtungszeit, manuelle Diagnose und Wiederholung fehlgeschlagener Läufe |
| Laufende Regressionstests | Testumfang je Durchlauf, Häufigkeit der Läufe und gemessene Nutzung je Testfall | reproduzierbare, isolierte Umgebung | Wartung von Testdaten, Änderungen an Oberflächen, Fehleranalyse und Freigaben |
| Mehrere parallele Aufgaben | erwartete Aufgabenlast, parallel benötigte Instanzen und beobachtete Nutzung pro Aufgabe | skalierbare, getrennte Browser-, VM- oder Mac-Instanzen | Ressourcenspitzen, Warteschlangen, Zugriffsschutz, Überwachung und Betrieb |
Führen Sie für jede Spalte eine Quelle mit: API-Werte stammen aus der aktuellen offiziellen Preisdokumentation, Verbrauchswerte aus Ihren eigenen Messungen, Umgebungsaufwände aus Ihrem Betriebsmodell und Prüfzeiten aus beobachteten Arbeitsabläufen. Halten Sie das Datum der letzten Prüfung intern fest. Wenn Sie mit einer Annahme starten müssen, kennzeichnen Sie sie ausdrücklich als Annahme und ersetzen Sie sie nach dem Pilotlauf durch Messwerte. So bleibt sichtbar, ob eine Abweichung durch geänderte Preise, mehr Modellrunden oder höheren Betriebsaufwand entstanden ist.
Ein nützlicher Pilot umfasst nicht nur einen glatten Standardfall. Wählen Sie repräsentative Aufgaben mit unterschiedlichen Seitenzuständen, Anmeldeanforderungen und möglichen Unterbrechungen. Messen Sie pro Lauf die verbrauchten Eingaben und Ausgaben, die tatsächlich eingesetzten Bildschirmzustände, die Dauer der Ausführungsumgebung, fehlgeschlagene Aktionen sowie die Zeit für menschliche Prüfung. Verwenden Sie dann die Verteilung Ihrer eigenen Beobachtungen für die Budgetplanung, statt einen angeblich allgemeingültigen Durchschnitt zu behaupten.
Mac-Ausbau anhand von Prüfkriterien entscheiden
Ein Cloud-Mac ist dann eine begründbare Budgetposition, wenn er eine konkrete Lücke Ihrer bisherigen Testumgebung schließt. Prüfen Sie die Entscheidung anhand dieser Kriterien:
- Zielabdeckung: Müssen Sie Safari, eine macOS-native Anwendung oder Systeminteraktionen testen, die Ihre vorhandene Browserumgebung nicht abbildet?
- Stabilität: Lassen sich Aufgaben in der aktuellen Umgebung reproduzierbar ausführen, oder führen Unterschiede zwischen Testumgebungen zu schwer diagnostizierbaren Fehlern?
- Isolation: Benötigen Sie getrennte Sitzungen, kontrollierte Berechtigungen und einen definierten Umgang mit Zugangsdaten und Bildschirmdaten?
- Betrieb: Kann Ihr Team Bereitstellung, Zustand, Protokollierung und Wiederherstellung der nötigen Mac-Umgebung selbst pflegen, oder soll dieser Aufwand reduziert werden?
- Kostenwirkung: Zeigt der Pilot, dass die zusätzliche Umgebung ein relevantes Testziel ermöglicht oder bisherige Fehler zuverlässig sichtbar macht?
Als Arbeitsreihenfolge gilt: Bleibt Ihr Ziel vollständig im Browser und bildet die vorhandene Umgebung die relevanten Oberflächen ab, erweitern Sie nicht allein wegen des Begriffs Computer Use auf einen Mac. Wenn Tests native macOS-Interaktionen voraussetzen, führen Sie einen begrenzten Vergleichslauf durch und erfassen Sie dabei Kosten, Fehlerrückläufe und manuelle Eingriffe. Entscheiden Sie danach, ob Sie den Mac dauerhaft benötigen oder nur für zeitlich begrenzte Testphasen.
Nutzen Sie vor einer Erweiterung diese direkt ausführbare Prüfung:
- [ ] Zielanwendungen und erforderliche Interaktionen für jeden Testfall dokumentiert.
- [ ] Browser-, Container- oder VM-Umgebung gegen die tatsächliche Zieloberfläche geprüft.
- [ ] API-Preise und Abrechnungsregeln aus der aktuellen offiziellen Dokumentation übernommen.
- [ ] Modellnutzung und Zahl der Beobachtungs-Aktions-Runden in repräsentativen Läufen erfasst.
- [ ] Fehlversuche, Sitzungsabbrüche und Wiederholungen getrennt protokolliert.
- [ ] Menschliche Freigaben und Diagnosezeit als eigene Aufwandsposition erfasst.
- [ ] Rechte, Testkonten, Protokollzugriff und Löschregeln festgelegt.
- [ ] Mac-Bedarf mit einem konkreten nativen oder systemnahen Testziel begründet.
Falls Ihre Planung auch die Organisation einer Mac-Umgebung umfasst, finden Sie Informationen zum Konfigurieren einer Macstripe-Bestellung. Prüfen Sie dabei separat, welche Testziele Ihre vorhandene Infrastruktur abdeckt und für welche Phasen eine gemietete Mac-Umgebung tatsächlich benötigt wird.
Häufig gestellte Fragen
Welche Kosten gehören bei Gemini 3.5 Flash Computer Use ins Budget?
Erfassen Sie nicht nur die Modellaufrufe. In die Kalkulation gehören auch Bildschirmdaten und zurückgesendete Ergebnisse, die Laufzeit der Ausführungsumgebung, fehlgeschlagene Aktionen, Wiederholungen, menschliche Freigaben sowie Wartung und Isolation. Trennen Sie einmalige Entwicklungsarbeit von laufenden Kosten. Die aktuellen Preise und Abrechnungsregeln entnehmen Sie der offiziellen Gemini-API-Preisseite.
Wie verändern Screenshots und fehlgeschlagene Aktionen die laufenden Kosten?
Bildschirmzustände werden Teil der Anfrage, und jede weitere Beobachtung-Aktion-Rückmeldung-Runde kann zusätzliche Modellverarbeitung auslösen. Bei einem Fehler kommen möglicherweise weitere Screenshots, Modellaufrufe und Laufzeit hinzu. Wie stark das Budget steigt, hängt von Ihrem Ablauf und den tatsächlich abgerechneten Eingaben ab. Messen Sie daher Token- und Nutzungsdaten je Aufgabe, statt eine pauschale Wiederholungsquote anzunehmen.
Brauche ich für reine Browser-Automatisierung eine vollständige Desktop-Umgebung?
Nicht zwingend. Wenn Ihr Agent ausschließlich Weboberflächen in einem kontrollierten Browser bedienen soll, können Sie zunächst eine isolierte Browser-Automatisierungsumgebung prüfen. Gemini Computer Use stellt keinen fertig bereitgestellten Desktop bereit: Ihre Anwendung muss Aktionen empfangen und in der Zielumgebung ausführen. Eine Desktop- oder Mac-Umgebung wird relevant, wenn die tatsächliche Zielanwendung oder Systemintegration sie erfordert.
Wann ist ein Cloud-Mac für Tests mit einem Computer-Use-Agenten sinnvoll?
Prüfen Sie einen Cloud-Mac, wenn Ihre Tests macOS-native Anwendungen, Safari oder systemnahe Interaktionen zuverlässig abdecken müssen. Er ist kein Standardbedarf für jeden Browser-Agenten. Entscheidend sind die benötigte Zielabdeckung, reproduzierbare Isolation und der Aufwand, den Ihr Team für Betrieb und Fehlerdiagnose tragen kann. Erfassen Sie diese Punkte mit echten Aufgaben, bevor Sie eine Mac-Umgebung dauerhaft einplanen.
