OpenClaw, le transfert de notifications Android a brûlé 127,8 millions de jetons en une journée

Un utilisateur de r/openclaw (/u/ultraneutral72) a attribué une facture de tokens anormalement élevée à la redirection de notifications Android. Le 1^er octobre 2026, son instance OpenClaw a enregistré 127 825 724 tokens au total sur une seule journée — alors qu'il n'interagissait pas activement avec l'agent.

La configuration

• OpenClaw 2026.9.7 sur CachyOS/Linux
• Agent principal : openai/gpt-6-astra sur le runtime Codex natif
• Samsung Galaxy S25 avec redirection de notifications activée
• Heartbeat toutes les 30 minutes
• Historique volumineux accumulé dans la session principale

Ce que les logs ont montré

La notification de charge d'Android (com.android.systemui, clé charging_state) était redirigée sous forme de réveils notifications-event. Durant certaines fenêtres, ces réveils se déclenchaient environ toutes les 30 secondes — chacun déclenchant un appel au modèle. L'agent répondait souvent no_change ou NO_REPLY, mais ces réponses coûtaient quand même des tokens. De nombreux tours incluaient un appel d'outil heartbeat_respond suivi d'une autre réponse du modèle.

Une fenêtre de 28 minutes contenait 56 tours, 112 réponses du modèle avec enregistrements d'usage, et environ 14,9 M de tokens. Les événements transportaient toujours le même indicateur de charge avec des pourcentages de batterie ou des temps de charge restants mis à jour.

La répartition pour le 1^er octobre 2026

• 127 825 724 tokens au total
• 125 030 400 tokens d'entrée mis en cache
• 2 734 313 tokens d'entrée non mis en cache
• 61 011 tokens de sortie
• ~87 % des tokens enregistrés liés aux tours déclenchés par les notifications
• ~12 % liés aux heartbeats planifiés

L'utilisateur a recoupé les totaux avec les transcriptions OpenClaw et les enregistrements d'usage natifs, en dédupliquant les IDs de réponse et en additionnant l'usage par réponse plutôt qu'en se fiant aux compteurs cumulés du fil.

Mise au point importante

Environ 98 % du total était de l'entrée mise en cache. Il s'agit d'une mesure de volume de tokens, pas d'une affirmation que 127,8 M de tokens ont été facturés au tarif plein non mis en cache. L'utilisateur a arrêté la passerelle pour l'instant et a déplacé une tâche Python existante d'affichage énergétique vers un minuteur système indépendant. Aucun test contrôlé avant/après n'a encore été réalisé.

Questions ouvertes

• S'agit-il d'un problème de configuration ou d'un bug ?
• Existe-t-il une méthode recommandée pour filtrer ou temporiser les mises à jour continues des notifications système avant qu'elles ne réveillent l'agent ?
• Les événements en arrière-plan devraient-ils s'exécuter dans un contexte isolé plus restreint plutôt que dans la session principale accumulée ?

Si vous redirigez des notifications Android vers OpenClaw, vérifiez si des clés système à forte rotation comme charging_state atteignent votre boucle d'agent avant de consulter votre prochain tableau de bord d'usage.