OpenClaw Android Notification Forwarding Burned 127.8M Tokens in One Day

An r/openclaw user (/u/ultraneutral72) traced an unexpectedly large token bill to Android notification forwarding. On October 1, 2026, their OpenClaw instance recorded 127,825,724 total tokens in a single day — while they weren't actively interacting with the agent.

The setup

• OpenClaw 2026.9.7 on CachyOS/Linux
• Main agent: openai/gpt-6-astra on the native Codex runtime
• Samsung Galaxy S25 with notification forwarding enabled
• Heartbeat every 30 minutes
• Large accumulated main-session history

What the logs showed

Android's charging notification (com.android.systemui, key charging_state) was being forwarded as notifications-event wakes. During some windows these fired roughly every 30 seconds — each one triggering a model call. The agent often answered no_change or NO_REPLY, but those replies still cost tokens. Many turns included a heartbeat_respond tool call followed by another model response.

One 28-minute window contained 56 turns, 112 model responses with usage records, and approximately 14.9M tokens. The events kept carrying the same charging indicator with updated battery percentages or remaining charge time.

The breakdown for October 1, 2026

• 127,825,724 total tokens
• 125,030,400 cached input tokens
• 2,734,313 non-cached input tokens
• 61,011 output tokens
• ~87% of recorded tokens tied to notification-triggered turns
• ~12% tied to scheduled heartbeats

The user cross-checked totals against OpenClaw transcript records and native usage records, deduplicating response IDs and summing per-response usage instead of relying on cumulative thread counters.

Important qualification

Roughly 98% of the total was cached input. This is a token-volume measurement, not a claim that 127.8M tokens were billed at the full uncached rate. The user has stopped the gateway for now and moved an existing Python energy-display job onto an independent system timer. No controlled before/after test has been run yet.

Open questions

• Is this a configuration issue or a bug?
• Is there a recommended way to filter or debounce ongoing system-notification updates before they wake the agent?
• Should background events run in an isolated, smaller context instead of the accumulated main session?

If you forward Android notifications into OpenClaw, check whether high-churn system keys like charging_state are hitting your agent loop before you next look at a usage dashboard.