Allow heartbeats to use a dedicated model and thinking level

[alfredomtx]

Problem

Heartbeats currently run in their owning agent session and therefore use that session’s model and reasoning level. A long-running Sol task may only need a cheap, bounded status check every five minutes, but each unchanged heartbeat still invokes Sol and grows the main session context.

The current rlm_heartbeat.create() API accepts only instruction, interval, label, and delivery_mode; /heartbeat likewise has no model override. This makes cost-efficient monitoring require a separate child agent plus custom parent/child notification plumbing.

Proposed solution

Support per-heartbeat model and thinking selection:

await rlm_heartbeat.create(
    instruction="Check the external job and notify the parent only on change",
    interval="5m",
    delivery_mode="follow_up",
    model="openai-codex/gpt-5.6-luna",
    thinking="xhigh",
)

Also support user-level heartbeats and global defaults:

/heartbeat --every 5m --model openai-codex/gpt-5.6-luna --thinking xhigh Check the job

[heartbeat]
model = "openai-codex/gpt-5.6-luna"
thinking = "xhigh"

The selected model and thinking level should be validated when the heartbeat is created, persisted with the scheduled job, shown by heartbeat status/list commands, and restored after daemon or session restart. Per-heartbeat values should override the global defaults.

Ideally, alternate-model heartbeat turns would avoid changing the owning session’s active model and would make their token usage separately visible.

Alternatives considered

Spawn a dedicated Luna child, create the recurring heartbeat in that child, keep it silent on unchanged checks, and message the Sol parent only when action is required. This works, but every workflow must implement lifecycle management, timeout handling, parent notification, and cleanup itself.

Running the heartbeat directly in Sol is simpler but repeatedly spends the premium model and expands the main context for deterministic “no change” checks.

Additional context

• Current API: packages/coding-agent/skills/rlm-heartbeat/src/rlm_heartbeat/__init__.py
• Related heartbeat reliability work: #820
• This request is about model routing and cost isolation, not heartbeat delivery reliability.

[gangula-karthik]

Yes this would be very useful. For me, I am running the harness on a shared cluster which has slurm job scheduler, and its currently wasting a lot of tokens just on polling, as a result it requires frequent compaction. The LLM im running is deepseek v4 pro.