Cron Model Migration

Cron Model Migration

Overview

Use this skill when a cron job needs a model change or when cron runs fail after a model change. The goal is simple: avoid reusing a session that is already bound to a different model.

Core rule

Prefer sessionTarget: "isolated" for cron jobs that set payload.model.

Why:

• isolated jobs run dedicated agent turns instead of sharing the main session
• isolated runs are the safest place to override model/thinking
• persistent/shared sessions are where model-switch residue shows up most often

If a cron does not need shared conversation history, keep it isolated.

Decision tree

Case 1 — New cron job with a specific model

Create it as:

• payload.kind = "agentTurn"
• sessionTarget = "isolated"
• payload.model = <target-model>

Do not bind it to current or session:xxx unless you explicitly need persistent context across runs.

Case 2 — Existing isolated cron, same session pattern, just changing model

Safe workflow:

1. Confirm the job is not actively running.
2. Disable the job.
3. Update payload.model.
4. Restart Gateway if the job has recently been running or already failed with a model-switch error.
5. Re-enable the job.
6. Force-run once and inspect the result.

If it still throws LiveSessionModelSwitchError, stop trying to patch it in place. Rebuild the job fresh.

Case 3 — Existing cron bound to current or session:xxx

Treat this as high risk for model residue.

Best practice:

• create a new job instead of editing the old one in place
• move it to sessionTarget: "isolated" unless persistent context is truly required
• if persistent context is required, use a new custom session id instead of reusing the old one

Do not reuse a persistent session and expect model changes to be clean.

Case 4 — Main-session cron

Avoid model overrides on main-session jobs unless there is a strong reason.

Why:

• main-session jobs share context with the main agent session
• changing model there can shift the shared session unexpectedly
• OpenClaw docs recommend model overrides primarily for isolated jobs

If the task needs a different model, split it into an isolated cron instead.

Recommended migration workflow

Use this sequence for production changes:

1. Inspect

   • confirm sessionTarget
   • confirm payload.kind
   • confirm current payload.model
   • check recent run failures

2. Classify

   • isolated + stateless → update in place is usually fine
   • current/custom/main → prefer rebuild

3. Apply

   • small change: disable → update → restart → enable → force-run
   • risky change or prior switch error: create a new isolated job with the new model

4. Verify

   • run exactly once with cron.run
   • verify the run completed, not merely enqueued
   • verify delivery/output still works

5. Cut over

   • only remove the old job after the replacement job succeeds

Anti-patterns

Avoid these:

• changing payload.model and immediately force-running repeatedly
• reusing sessionTarget: "current" for jobs that need model churn
• editing a persistent session:xxx job without changing the backing session id
• assuming cron.run enqueue success means the agent turn succeeded
• debugging only the prompt while ignoring session binding

Troubleshooting LiveSessionModelSwitchError

When you see:

• LiveSessionModelSwitchError: Live session model switch requested: ...

Assume one of these first:

1. the job is reusing a live or persistent session already bound to another model
2. the job was edited in place after prior runs left session state behind
3. the job is using current, main, or a custom persistent session where override behavior is unsafe

Response order:

1. inspect job config
2. confirm sessionTarget
3. confirm whether the run is isolated or persistent
4. restart Gateway if stale execution state is plausible
5. if still failing, replace the job with a fresh isolated one

Minimal safe templates

Stateless background analysis

Use:

• sessionTarget: "isolated"
• payload.kind: "agentTurn"
• explicit payload.model
• optional delivery.mode: "announce" or "none"

Persistent weekly summary that truly needs memory

Use:

• sessionTarget: "session:<new-id>"
• payload.kind: "agentTurn"
• explicit payload.model
• accept that model changes later should usually mean creating a new session id/job

Practical rule of thumb

If you need to ask “can I safely switch this cron’s model in place?”, the default answer is:

• yes for isolated/stateless jobs, with one controlled validation run
• no for shared or persistent jobs; rebuild instead