Heartbeat Economics: Why Your Recurring Agent's Bill Is Set by the Schedule, Not the Work

A heartbeat agent is any agent that wakes on a timer, checks whether anything needs doing, and usually finds that nothing does. OpenClaw calls it a heartbeat; Claude Code Routines and GitHub Actions crons are the same shape at a slower cadence. The economics are identical across all of them, and counterintuitive enough to be worth stating as a law.

This is the generalized version of the cost mental model: the pillar maps the whole bill; this post isolates the one property that makes recurring agents expensive.

011. The heartbeat cost law

The monthly bill of a recurring agent is arithmetic:

calls/month × tokens/call × price/token.

The trap is in which factors you actually control. On a one-shot task, all three track the work: a harder question means more tokens and maybe a pricier model. On a schedule, that link breaks. Calls/month is your cron expression — you picked every 15 minutes because you wanted freshness, not because the underlying check got 96× harder per day. Tokens/call is mostly the context the session drags along, not the check's difficulty. Only price/token is honestly tied to anything.

So two of the three multipliers are set by the timer and the transcript, not the task — the whole reason heartbeats surprise people on the invoice.

022. Frequency is a config value, not a workload

Calls/month is pure schedule. Nothing about the work appears in this column:

Now multiply that column by whatever one run costs — two real anchors, from measured or documented inputs:

• Small context — the published Reelier benchmark measured a live agent on a trivial two-step npm-metadata lookup at $0.019068 per run (18,390 input tokens) — a tiny task carrying a small session.
• Heartbeat context — OpenClaw heartbeats are documented at ~120,000 tokens of context per request. On Claude Opus 4.8 at $5.00 per million input tokens (Anthropic pricing, retrieved 2026-07-21), that's 120,000 × $5.00 / 1,000,000 = $0.60 per call on the input side alone.

Read a row across: the check is the same check. Read a column down: the bill quadruples between cadences you'd change with one line of YAML. The Level-0 replay column is $0 for the deterministic core only — judgment still needs a model, so it's not a universal zero (§4).

033. Tokens per call is context, not difficulty

The middle factor is the one people misread. On a recurring job, tokens/call barely reflects the check — it reflects everything the session hauls with it: instructions, tool definitions, history, prior tool outputs. Anthropic's own engineering post Code execution with MCP walks through one tool-heavy workflow that moved ~150,000 tokens through context, restructured to ~2,000 — a 98.7% cut that was almost entirely plumbing, not judgment. The trivial benchmark task above carried 18,390 tokens for the same reason.

This is why you can't out-optimize the schedule from inside the model. Trimming prompts, warming the cache, or dropping to a cheaper tier (Sonnet 5 is $2.00/MTok introductory through 2026-08-31, then $3.00 — same pricing page) shrinks a bill that is the wrong shape: you're paying, every tick, to regenerate a plan you already got right — and swapping models to dodge it invites its own regressions. The only lever that removes those tokens is to stop generating that part.

044. When to replay vs. re-reason

Split the job before you optimize it. Every recurring agent is a thin layer of judgment on a thick layer of re-derivation:

• Judgment — triage an anomaly, write prose for a human, decide what a genuinely new input means. The right answer changes run to run — keep paying the model.
• Re-derivation — the same sequence of tool calls, the same shapes, the same kind of answer, every tick. Status checks, metrics pulls, feed diffs, report scaffolding. Your agent worked these out correctly once; every later run pays to re-derive them, with some chance of doing it slightly differently — the drift problem wearing the cost problem's clothes.

Record the re-derivation once and replay it. Level-0 replay constructs no LLM client at all — 0 tokens by construction, for the deterministic core, not the judgment. The compiler is conservative: only steps with a clean recorded result get an assertion; steps that failed or returned nothing stay assertion-less and replay as unchecked, surfaced as open questions rather than silently marked passed. Replay is read-only by default — an idempotent-write step re-fires only with --allow-writes, and a destructive step never re-fires without an explicit --yes. That gate is most of the safety story: in Reelier's scanned corpus only ~1.1% of sessions were read-only end to end, so nearly every real job writes somewhere.

The decision rule: open-ended inputs with a genuinely changing response, re-reason; the same tool sequence producing the same shape, replay it and wake the model only when a reelier diff exits 1 — the boundary a behavior cache blurs and a replay keeps sharp. The heartbeat and scheduled-agent posts are the priced-out instances of exactly this split.

055. A real receipt

Reelier's install demo closes with this — verbatim from the project README:

Your receipt:
  skill:        reelier-init-demo
  steps:        2 total, 2 passed, 0 unchecked, 0 failed
  replay time:  44ms  [measured]
  LLM tokens:   0     [measured]

  An agent doing a comparable task re-reasons every run (~2.8s, ~18k tokens on
  our benchmark). Your replay: 44ms, 0 tokens.

Zero times any call count is still zero: that's what removes the schedule multiplier from the deterministic core. Plug your own cadence, context size, and model into the agent cost calculator — or read the calculator walkthrough — and put your heartbeat's bill next to the replay column.

Record the check once. Replay it on the timer. Pay for judgment, not re-derivation.