Summary

Allow the memory-core plugin to scope dreaming context loading via a lightContext config option, so plugin-managed dreaming work can run with a lean bootstrap without affecting global heartbeat behaviour.

Problem to solve

The memory-core plugin’s Memory Dreaming Promotion job uses a systemEvent payload, which means the actual agent turn is processed by the main heartbeat runner. There is currently no per-plugin way to apply lightContext (or other turn-bootstrap controls) to dreaming work specifically.
The cron CLI correctly rejects lightContext on systemEvent payloads (cron.update payload.kind="agentTurn" requires message) — this is by design, since lightContext controls how an agent turn bootstraps and systemEvent payloads don’t run their own agent turn at the cron level. So the rejection isn’t the issue.
The issue is that the only available lever for scoping dreaming context is lightContext at the heartbeat level globally — which affects all heartbeat behaviour, not just dreaming. For deployments that want lean dreaming context loading without globally limiting heartbeat behaviour, this forces a tradeoff: either accept full-bootstrap context on every dreaming cycle, or apply lightContext globally and lose richer context for non-dreaming heartbeat work.

Proposed solution

Expose lightContext (and ideally a small set of related turn-bootstrap controls) under the existing memory-core config.

The example below is JSON5 (matching OpenClaw's own config format):

{
  plugins: {
    entries: {
      "memory-core": {
        config: {
          dreaming: {
            enabled: true,
            frequency: "nightly",
            lightContext: true,
            // optional related controls:
            // bootstrapFiles: ["DREAMING.md"]
          }
        }
      }
    }
  }
}

When set, memory-core would propagate this through to the heartbeat runner specifically for dreaming-triggered turns, leaving non-dreaming heartbeat behaviour unchanged.
The change is additive to an existing config block (plugins.entries.memory-core.config.dreaming), so no new config tree is required and existing deployments are unaffected unless they opt in.

Alternatives considered

1. Apply lightContext: true at the heartbeat level globally. Works mechanically, but affects all heartbeat work — not just dreaming. Suboptimal for any deployment where heartbeat does meaningful contextual work outside dreaming.

2. Apply lightContext directly to the cron job via CLI. Not viable — the CLI correctly rejects lightContext on systemEvent payloads, since the agent turn happens downstream in heartbeat, not at the cron level. This is by design and the right design.

3. Modify the workspace bootstrap to be lean by default. Would affect all agent turns including interactive sessions, which need full bootstrap. Not a viable workaround for this specific gap.

4. Disable dreaming entirely. Avoids the cost but loses the capability. Counterproductive.

Impact

Affected users/systems/channels:

• Any OpenClaw deployment using the memory-core plugin with dreaming enabled.

• Particularly impactful for always-on personal assistant deployments running multiple agents with distinct workspaces, where dreaming runs nightly per agent and bootstrap context loading compounds across phases (light/deep/REM) and across agents.

Severity:

• Annoying for single-agent, low-frequency dreaming setups.

• Materially impacts cost and context hygiene for multi-agent, frequent-dreaming deployments. Scheduled jobs that load full bootstrap context were a recurring pattern behind unbounded context growth in our deployment, contributing to a cost incident in the four-figure range across a single month.

Frequency:

• Always — every dreaming cycle loads full bootstrap context. The pain is continuous, not intermittent.

Consequence:

• Higher token spend per dreaming cycle than necessary.

• Forces an undesirable tradeoff between lean dreaming and rich heartbeat context.

• One of the last remaining classes of “scheduled job loads more context than it needs” without a per-plugin scoping mechanism.

Evidence/examples

No response

Additional information

OpenClaw version: 4.15

Related architectural context: per the cron docs, systemEvent payloads correctly hand off to heartbeat for processing. This feature request is not asking that to change. It’s asking for memory-core to expose its own knob for scoping the downstream context loading, since memory-core owns the scheduled job that triggers the downstream work.

If a similar pattern exists for other plugin-managed scheduled work (i.e. plugins that own systemEvent cron jobs without exposing context-loading controls), this could generalise into a broader plugin-level convention. Happy to discuss scope if the maintainers see value in that direction.