OpenClaw Heartbeat Optimization: How I Cut Costs 50% by Rethinking the Default Interval

---

If you’re running OpenClaw with the default 30-minute heartbeat and wondering why your bill keeps climbing, you’re not alone. I ran the same setup for weeks before realizing most of those heartbeat turns were doing absolutely nothing. The fix took 20 minutes and cut my costs in half.

The core insight: OpenClaw’s default heartbeat interval assumes you have no other scheduling infrastructure. The moment you set up crons for your recurring tasks, the heartbeat becomes redundant for most of what it does. By extending the interval to 60 minutes and gutting the bloated HEARTBEAT.md file, I went from 32 wasted turns per day to 16 focused ones, with 75% less context per turn.

Here’s the full breakdown of how I did it, why it works, and when you should not do this.

What Does the OpenClaw Heartbeat Actually Do?

The heartbeat is OpenClaw’s background pulse. Every interval (default: 30 minutes), the system wakes your agent, feeds it the contents of HEARTBEAT.md, and asks: “Anything need attention?”

If nothing does, the agent returns HEARTBEAT_OK and goes back to sleep. That turn still costs tokens. The HEARTBEAT.md file still gets loaded into context. The model still processes it.

In a mature setup, most heartbeat turns return HEARTBEAT_OK. I tracked mine over a week: 80%+ of heartbeat turns had nothing to do. Each one burned tokens loading a 2.9KB HEARTBEAT.md file and running through a checklist of items that crons were already handling.

The Trap: HEARTBEAT.md Becomes a Junk Drawer

Here’s what happens naturally. You start with a clean heartbeat file. Then you add a check: “Make sure the daily report cron ran.” Then another: “Verify the inbox scan happened.” Then: “Absorb any new knowledge from today’s notes.”

Before long, HEARTBEAT.md is a 2.9KB monster full of backstop checks, ops accountability routines, and knowledge absorption tasks. Each one made sense when you added it. Together, they’re an expensive mess.

The problem is duplication. If you have a cron that sends a daily report at 9 AM, you don’t also need the heartbeat to verify it ran. The cron either fires or it doesn’t. Adding a heartbeat backstop just means you’re paying for a second check that almost never catches anything.

OpenClaw Heartbeat vs Cron: A Decision Framework

This is the mental model that changed everything for me:

Crons are clocks. They fire at exact times, run in isolation, can use a different (cheaper) model, and produce standalone output. Use them when timing matters.

Heartbeats are pulses. They batch multiple small checks together, have access to conversational context from recent messages, and drift is acceptable. Use them when you need ambient awareness, not precision.

When to Use Crons

• Exact timing matters (“post at 9 AM, not 9:17 AM”)
• The task needs isolation from the main session
• You want to use a cheaper model for mechanical work
• One-shot reminders (“remind me in 20 minutes”)
• Output should deliver directly to a channel

When to Use Heartbeats

• Multiple lightweight checks can batch into one turn
• You need recent conversational context
• Timing can drift by 15–30 minutes and nobody cares
• The check is qualitative, not mechanical

Once I mapped every item in my HEARTBEAT.md against this framework, the answer was obvious. Most of it belonged in crons. The heartbeat was doing cron work at heartbeat prices.

How I Slimmed HEARTBEAT.md from 2.9KB to 700 Bytes

I gutted everything that duplicated cron functionality:

Removed:

• Cron backstop checks (verifying other scheduled tasks ran)
• Ops accountability routines (daily summaries, status reports)
• Knowledge absorption tasks (reading and processing notes)

Kept:

• Browser tab cleanup (close stale tabs that pile up)
• Email check with 3-hour dedup (glance at inbox, but not if checked recently)
• “One real thought” prompt (force the agent to surface one genuine insight)

That last one is worth explaining. The “one real thought” prompt is what makes the heartbeat more than a mechanical checklist. It asks the agent to look at recent context and produce a single useful observation. Sometimes it’s nothing. Sometimes it catches something valuable that a cron never would, because crons don’t have conversational context.

The final HEARTBEAT.md is roughly 700 bytes. It loads fast, costs little, and does only what heartbeats are uniquely good at.

The Results: 50% Cost Reduction

The numbers after one week of running the optimized setup:

Metric	Before	After
Heartbeat interval	30 min	60 min
Turns per day	~32	~16
HEARTBEAT.md size	2.9 KB	~700 bytes
Context per turn	Baseline	-75%
Estimated cost reduction	—	50%+

The cost savings compound. Fewer turns means fewer API calls. Smaller context means fewer tokens per call. Together, you’re looking at well over 50% reduction in heartbeat-related spend.

The Model Selection Tradeoff

There’s a tension here worth acknowledging. If your heartbeat is purely mechanical (check inbox, close tabs), you should run it on the cheapest model available. But the “one real thought” prompt needs a capable model to produce anything useful.

I keep the capable model. The cost of 16 turns per day on a good model is still less than 32 turns on the same model with a bloated prompt. And the occasional real insight from the “one real thought” check has paid for itself multiple times over.

If cost is your primary constraint, you could split this further: run a cheap model for the mechanical checks and reserve the capable model for deeper analysis on a separate, less frequent schedule. The playbook covers this exact pattern.

When NOT to Extend Your Heartbeat Interval

This optimization assumes a specific setup. Don’t blindly copy it if:

You don’t have cron infrastructure yet. If the heartbeat is your only scheduling mechanism, extending the interval means things get checked less often with no fallback. Set up crons first, then optimize the heartbeat.

You handle time-sensitive messages. If your agent needs to respond to incoming messages within minutes, a 60-minute heartbeat creates unacceptable latency. Keep the interval short or use event-driven triggers instead.

You’re still in the early setup phase. During the first few weeks, a frequent heartbeat helps you catch configuration issues and understand your agent’s behavior patterns. Optimize after the system stabilizes.

Quick-Start Checklist

1. Audit your current HEARTBEAT.md. Flag every item that a cron could handle instead.
2. Move cron-suitable items to actual cron jobs.
3. Strip HEARTBEAT.md down to heartbeat-only tasks (ambient checks, context-dependent observations).
4. Extend the interval from 30m to 60m.
5. Monitor for one week. Track HEARTBEAT_OK percentage and catch rate.

The Bigger Picture

Heartbeat optimization is one piece of a larger cost-efficiency puzzle. The real wins come from understanding how all the moving parts interact: heartbeats, crons, model selection, context management, and prompt engineering working together as a system.

I’ve documented the complete framework, including exact configurations, templates, and the decision trees I use daily, in the OpenClaw Playbook. If this post saved you from burning tokens on redundant heartbeat turns, the playbook covers the other 90% of optimizations I’ve found running this system in production.

Want the full system? The OpenClaw Playbook includes ready-to-use HEARTBEAT.md templates, cron configurations, model selection guides, and the complete cost optimization framework. Everything in this post, plus the configs you can copy-paste into your own setup.