OpenClaw Android-Benachrichtigungsweiterleitung verbrauchte an einem Tag 127,8 Mio. Token

Ein r/openclaw-Nutzer (/u/ultraneutral72) führte eine unerwartet hohe Token-Rechnung auf die Weiterleitung von Android-Benachrichtigungen zurück. Am 1. Oktober 2026 verzeichnete seine OpenClaw-Instanz 127.825.724 Token an einem einzigen Tag – obwohl er nicht aktiv mit dem Agenten interagierte.

Das Setup

• OpenClaw 2026.9.7 auf CachyOS/Linux
• Hauptagent: openai/gpt-6-astra auf der nativen Codex-Runtime
• Samsung Galaxy S25 mit aktivierter Benachrichtigungsweiterleitung
• Heartbeat alle 30 Minuten
• Umfangreiche akkumulierte Historie der Hauptsession

Was die Logs zeigten

Androids Ladebenachrichtigung (com.android.systemui, Schlüssel charging_state) wurde als notifications-event-Weckrufe weitergeleitet. In manchen Zeitfenstern feuerten diese etwa alle 30 Sekunden – jeder löste einen Modellaufruf aus. Der Agent antwortete oft mit no_change oder NO_REPLY, aber auch diese Antworten kosteten Token. Viele Turns enthielten einen heartbeat_respond-Tool-Aufruf, gefolgt von einer weiteren Modellantwort.

Ein 28-Minuten-Fenster enthielt 56 Turns, 112 Modellantworten mit Usage-Einträgen und etwa 14,9 Mio. Token. Die Events trugen weiterhin denselben Ladeindikator mit aktualisierten Akku-Prozentwerten oder Restladezeit.

Die Aufschlüsselung für den 1. Oktober 2026

• 127.825.724 Token gesamt
• 125.030.400 gecachte Input-Token
• 2.734.313 nicht gecachte Input-Token
• 61.011 Output-Token
• ~87 % der erfassten Token gehen auf benachrichtigungsausgelöste Turns zurück
• ~12 % auf geplante Heartbeats

Der Nutzer glich die Summen mit OpenClaw-Transcript-Aufzeichnungen und nativen Usage-Daten ab, deduplizierte Response-IDs und summierte die Usage pro Antwort, statt sich auf kumulative Thread-Zähler zu verlassen.

Wichtige Einschränkung

Rund 98 % der Gesamtsumme waren gecachter Input. Dies ist eine Token-Volumen-Messung, keine Aussage darüber, dass 127,8 Mio. Token zum vollen, nicht gecachten Tarif abgerechnet wurden. Der Nutzer hat das Gateway vorerst gestoppt und einen bestehenden Python-Energieanzeige-Job auf einen unabhängigen System-Timer verlegt. Ein kontrollierter Vorher/Nachher-Test wurde noch nicht durchgeführt.

Offene Fragen

• Handelt es sich um ein Konfigurationsproblem oder einen Bug?
• Gibt es eine empfohlene Möglichkeit, laufende Systembenachrichtigungs-Updates zu filtern oder zu entprellen, bevor sie den Agenten wecken?
• Sollten Hintergrund-Events in einem isolierten, kleineren Kontext statt in der akkumulierten Hauptsession laufen?

Wenn du Android-Benachrichtigungen in OpenClaw weiterleitest, prüfe, ob stark wechselnde System-Schlüssel wie charging_state deine Agenten-Schleife treffen, bevor du das nächste Mal auf ein Usage-Dashboard schaust.