OpenClaw merged PR #143499, a P2 Gateway change that defers heartbeat execution loading until a scheduled wake actually needs to run.
The user-facing promise is modest but useful: scheduling can initialize without pulling in heartbeat execution, model, channel, and reply dependencies up front. When the first wake arrives, OpenClaw still loads and runs the execution path.
In other words, this is not a new heartbeat feature. It is a cleaner runtime boundary for an existing one.
What Changed
The PR moves heartbeat scheduling toward lazy loading. The scheduler and Gateway wake callbacks now use an existing lazy-runtime helper, and wake options are captured before the awaited load.
That last part matters. Any time a system defers work across an await, it has to prove the work is still current afterward. The PR says OpenClaw now rechecks ownership and cancellation after loading so stopped, replaced, or canceled wakes cannot dispatch late.
The change also moves pure wake configuration and timeout resolution into a lightweight heartbeat configuration owner. Cron, dispatch, prompt, and session callers can use those configuration leaves without importing the heavier execution path.
The public contract stays the same:
- Heartbeat cadence is unchanged.
- Timeout sentinels are unchanged.
- Configuration and schema behavior are unchanged.
- Loader failures remain visible.
- The first actual wake still runs through heartbeat execution.
Why It Matters
OpenClaw's Gateway does a lot during startup and scheduled-service setup. Pulling execution code into scheduling paths before a wake needs it can make dependency boundaries harder to reason about, especially when cron, channels, models, and reply delivery all have their own ownership rules.
Lazy loading is useful only if it preserves lifecycle correctness. PR #143499 is careful on that point: it keeps synchronous lifecycle methods, captures wake options before load, and checks current ownership after load.
That makes the change less flashy than a feature launch, but more important for long-term maintainability. Heartbeats should be cheap to schedule, explicit to run, and unable to leak stale work after cancellation.
The Proof
The PR reports exact-head Linux qualification across 150 cases in four files, including production spawn, model reset, server cron, and lost-queued admission tests. Hosted CI also passed on the exact head with 122 successful jobs and 17 skipped.
Earlier retained proof covered 178 selected cases across 10 files, including Gateway and infrastructure scenarios for lazy loading, update and stop ordering, scheduler ownership, broadcast outcomes, cron, model overrides, and tool responses.
The PR is careful about failed or partial evidence, too. A local cron integration attempt hit disk exhaustion and is explicitly retained as failed rather than relabeled as passing. That kind of bookkeeping matters because lazy execution changes are all about trust in lifecycle proof.
What To Watch
The maintainers do not claim a measured startup, latency, or memory improvement. This is a boundary and correctness change first.
The practical win should be easier Gateway initialization and cleaner scheduling ownership. If future heartbeat or cron fixes build on this, PR #143499 is likely to be one of the foundations that made the runtime easier to divide without changing what users configure.