Token-Kosten eines KI-Agenten pro Aufgabe berechnen

Kosten pro abgeschlossener Aufgabe messen

Die wichtigste Kennzahl lautet: Token-Kosten eines KI-Agenten pro Aufgabe ergeben sich aus allen gemessenen Kosten geteilt durch verifizierte erfolgreiche Abschlüsse. Nicht jeder Versuch zählt als erledigte Aufgabe. Ein Entwurf, der im falschen Chat landet, eine abgebrochene Route oder ein nicht geprüfter Text ist ein Kostenposten, aber kein Erfolg.

Darum beginnt die Rechnung mit einer Erfolgsdefinition. Beispiel: „Die Aufgabe ist abgeschlossen, wenn ein geprüfter Entwurf im richtigen sichtbaren Eingabefeld steht und noch nicht gesendet wurde.“ Oder: „Die Aufgabe ist abgeschlossen, wenn eine Route mit Ziel und Verkehrsmittel sichtbar geöffnet ist.“ Für mehrstufige Telefonaufgaben hilft Mehrstufige Aufgaben auf Android automatisieren: prüfen, bestätigen, ausführen, den Abschluss sauber zu definieren.

Rechne getrennt: Modellnutzung, enthaltene Abo- oder Credit-Kontingente, externe Tool- oder Dienstgebühren, menschliche Prüfzeit und optional zusätzliche Energie. Was bereits im Abo enthalten ist, wird nicht ein zweites Mal als variable API-Kosten gezählt. Was ein Provider separat abrechnet, gehört dagegen in das Kostenbuch.

Aus Provider-Nutzung ein Kostenbuch bauen

Für ein Modellkostenbuch brauchst du getrennte Summen. Zähle nicht gecachte Eingabetoken, aus dem Cache gelesene Eingabetoken und abrechenbare Ausgabetoken disjunkt, also ohne dieselben Token doppelt zu erfassen. Die Gemini-Dokumentation zu Tokens beschreibt, dass Text und andere Modalitäten wie Bilder tokenisiert werden und dass Nutzungsdaten unter anderem Eingabe, Ausgabe, Denken und gecachten Kontext ausweisen können. Die Gemini-Preisdokumentation macht außerdem klar, dass Preise nach Modell, Modalität und Dienstebene variieren und dass Thinking, Cache oder Grounding je nach Kategorie anders zählen können.

Eine neutrale Formel sieht so aus: Modellkosten = nicht gecachte Eingabetoken / eine Million x Eingabepreis pro Million Token + aus dem Cache gelesene Eingabetoken / eine Million x Cache-Lesepreis pro Million Token + abrechenbare Ausgabetoken / eine Million x Ausgabepreis pro Million Token. Danach kommen nur die Positionen hinzu, die dein Provider wirklich separat abrechnet: Cache-Erstellung, Cache-Speicherung, externe Werkzeuge, Such- oder Grounding-Dienste, Bildverarbeitung, Abos oder Credits außerhalb des Verbrauchs.

Bei Cache-Rechnung ist wichtig, nicht zu raten. Die Claude-Dokumentation zu Prompt Caching trennt Cache Writes, Cache Reads und normale nicht gecachte Eingabe. Cache-Treffer hängen von wiederholbarem Inhalt und passenden Bedingungen ab; geänderte Präfixe können den Treffer verhindern. Nutze deshalb die Provider-Nutzungsfelder, statt pauschal Ersparnis anzunehmen.

Screenshots, sichtbarer App-Kontext, UI-Informationen und Thinking zählen nach dem jeweiligen Provider. Bildtoken, die bereits als Eingabe berechnet sind, bekommen nicht noch einmal einen „Bildaufschlag“ in deiner eigenen Tabelle. Fehlversuche werden mitgezählt, aber nicht nochmals als Extra-Retry-Pauschale addiert, wenn ihre Token bereits in den Summen stecken.

Einen hypothetischen Aufgabenstapel nachrechnen

Dieses Beispiel ist eine Rechenvorlage mit erfundenen Lehrpreisen in US-Dollar, keine aktuelle Anbieterpreisliste und kein FoneClaw-Benchmark. Angenommen, ein Aufgabenstapel enthält 100 Versuche. Alle Modellaufrufe, Wiederholungen und fehlgeschlagenen Versuche sind bereits in den folgenden Nutzungssummen enthalten.

Von 100 versuchten Aufgaben sind 90 verifiziert abgeschlossen. Die Kosten pro abgeschlossenem Ergebnis sind also 3,34 USD / 90 = rund 0,0371 USD. Wenn es null verifizierte Abschlüsse gibt, ist die Kennzahl nicht null, sondern nicht sinnvoll definiert; dann misst du Fehlerursachen, nicht Kosten pro Erfolg.

In diesem Beispiel gibt es keine Cache-Erstellungsgebühr, keine Cache-Speicherung, keine Abozuordnung, keine Währungsumrechnung und keine separate Energie- oder Arbeitszeitbewertung. In einer echten Rechnung ergänzt du genau die Kategorien, die dein Provider und dein Prozess tatsächlich ausweisen.

Was telefonseitige Ausführung ändern kann

Telefonseitige Ausführung ist nicht dasselbe wie lokale Inferenz. FoneClaw führt unterstützte Android-Aktionen aus, während das konfigurierte Modell beim Verstehen und Planen hilft. Ein Online-Modell kann bereitgestellten Kontext verarbeiten. Daraus folgt: unterstützte Gerätewerkzeuge oder gespeicherte Abläufe können Modellnutzung, Kontextumfang oder Wiederholungen verändern, garantieren aber keine Nullkosten und keine feste Ersparnis.

Ein Beispiel: FoneClaw kann den sichtbaren Zustand einer unterstützten App auslesen, nach einer Änderung den aktuellen Bildschirm erneut prüfen und Text in ein erkanntes editierbares Feld setzen. Dieser Texteingabeschritt sendet nicht, übermittelt kein Formular und drückt nicht Enter. Für solche Android-Schritte ist Android-Handy mit KI-Agent steuern: von Absicht zu bestätigter Aktion der passende Hintergrund.

Ob UI-Informationen günstiger sind als ein Screenshot, hängt von Aufgabe, Provider und Abrechnung ab. Screenshots und UI-Auslesen sind unterschiedliche Werkzeuge; ein Screenshot ist kein pauschaler Ersatz, um fehlende Zugänglichkeit oder ein nicht gefundenes Steuerelement zu umgehen. Die aktuelle Übersicht zu unterstützten Android-Funktionen steht auf der FoneClaw-Funktionsseite.

Eine kleine wiederholbare Aufgabe messen

Miss eine kleine Aufgabe zehnmal mit derselben Eingabe, demselben Gerät, derselben App und derselben Erfolgsdefinition. Eine gute Testaufgabe ist risikoarm: einen Entwurf in einem sichtbaren Feld vorbereiten, nicht senden. Notiere pro Versuch: Provider-Nutzung, nicht gecachte Eingabetoken, aus dem Cache gelesene Eingabetoken, Ausgabetoken, gesonderte Toolgebühren, ob ein Cache-Treffer bestätigt wurde, wie viele Wiederholungen nötig waren, ob das Ergebnis verifiziert abgeschlossen wurde und wie lange menschliche Prüfung dauerte.

Erfasse außerdem, welche Freigaben sichtbar waren. Empfängerprüfung, Berechtigung und Bestätigung sind keine Sparposten, die man streichen sollte. Wenn eine Aufgabe scheitert, wird sie in den Kosten gezählt; sie erhöht aber nicht den Nenner der abgeschlossenen Aufgaben. Vergleiche am Ende Gesamtkosten / verifizierte Abschlüsse, nicht Gesamtkosten / Versuche.

Wenn du Energie erfassen möchtest, halte sie getrennt oder bewerte sie konsistent. Eine einfache Zusatzformel lautet: zusätzliche Wattstunden / 1000 x lokaler Preis pro kWh. Das ist eine optionale Energieposition und kein Ersatz für Tokenkosten oder Nutzerzeit. Für Fehlerdiagnose vor weiteren Wiederholungen hilft Fehleranalyse und Wiederherstellung für Phone-KI-Agenten: Android-Aufgaben sicher reparieren.

Verschwendung reduzieren, ohne Prüfungen zu streichen

Kosten sinken am saubersten durch klare Eingaben, begrenzte Verlaufslänge, bestätigte Cache-Treffer und gezielte Fehlerdiagnose vor einem neuen Versuch. Gib nur den Kontext mit, der für diese Aufgabe nötig ist. Prüfe nach App-Änderungen den aktuellen sichtbaren Zustand, statt mit veraltetem Kontext weiterzurechnen.

Gespeicherte Workflows können wiederverwendbare unterstützte Werkzeugschritte ablegen. Sie garantieren aber nicht, dass künftig keine Modellaufrufe oder keine Abrechnung entstehen. Behalte Freigaben für folgenreiche Aktionen bei: Empfänger, Inhalt, Senden, Zahlung, Kontoänderung und Berechtigung dürfen nicht zur Kostenreduktion übersprungen werden.

Die wichtigste Kostenregel bleibt: weniger unnötiges Neuplanen, nicht weniger Kontrolle. Wer lokale Ausführung, Cloud-Modelle und Datenschutzgrenzen grundsätzlich einordnen möchte, findet in AI Agent Trust: Lokale Telefonsteuerung oder Cloud-KI? den breiteren Rahmen.