Spotting the Idle Token Costs
I logged into my dashboard one morning and saw a $35 charge for the previous day with no activity. This surprised me because my OpenClaw agents had been sitting idle. Similar patterns appeared in community reports.
A Reddit user posted about $35 in daily token spend despite no interactions. Community comments confirmed it stemmed from default 30-minute heartbeats. They recommended cron job switches instead of polling.
Default Heartbeats Driving the Spend
The 30-minute default heartbeat interval generates approximately 48 no-op LLM calls per day per agent. Each check costs $0.02-0.05 in tokens. This accumulates to $30-70 monthly idle spend even with zero user interaction.
One user described their OpenClaw agent randomly switching to an expensive Opus model for heartbeat requests every 30 minutes after weeks of idle operation. Attached logs showed repeated no-op completions. These checks ran in the background without any prompts.
Background Processes Adding Unexpected Overhead
Background exec and process tools maintain long-running shell sessions in memory. They trigger unexpected completions and token usage from monitoring tasks. These persist independently of active user prompts.
High idle CPU usage reached up to 145% frequently. This correlated with the background monitoring loops. It compounded both token and infrastructure costs in persistent deployments.
Optimization reports detail agents burning tokens through background monitoring even when idle. One case reduced costs from $150 to $6 overnight by targeting these defaults. Common fixes involved config changes disabling heartbeats.
Heartbeat Polling vs Cron Job Scheduling
Here is a comparison of the two main approaches based on key criteria.
| Criteria | Default Heartbeat Polling | Cron Job Scheduling |
|---|---|---|
| Cost predictability (variable high vs fixed low) | Variable high | Fixed low |
| Response latency (near real-time vs scheduled) | Near real-time | Scheduled |
| Setup complexity (minimal config vs cron setup required) | Minimal config | Cron setup required |
This shows how default polling leads to unpredictable costs while cron offers better control.
Practical Steps to Cut the Costs
Here is exactly what to do to address this. Start by reviewing your agent configuration.
- Locate the openclaw.json file for your agent.
- Modify the heartbeat section to disable it by setting the interval to 0 or removing the entry.
- Implement cron jobs for necessary scheduled tasks such as email polling every 5 minutes.
- Use the exec tool for shell commands and the process tool to manage long-running sessions as documented.
Here is the default heartbeat config example:
"heartbeat": {"every": "30m", "target": "discord", "prompt": "# Heartbeat Checks..."}
To disable via: Turn off heartbeats in agent config or set interval to 0; replace with cron jobs for tasks like email polling every 5 minutes.
Balancing Real-Time Needs and Cost Control
Heartbeats provide continuous responsiveness for incoming messages or events. Cron jobs cannot match this in real-time without additional scheduling overhead. For time-sensitive automations like monitoring inboxes or sensors, the reliability of persistent background checks may justify the token cost over purely scheduled alternatives.
In my case the costs became too high to ignore. We ended up using Standard Compute at https://standardcompute.com which provides unlimited LLM usage for OpenClaw. This removed the variable token spend from idle processes entirely.
The practical takeaway is to audit default heartbeat settings in your persistent agents and switch to isolated cron jobs for non-time-critical tasks to eliminate silent token drain.