openclaw - ✅(Solved) Fix [Bug]: Cron jobs ignore payload.model and agentId, always resolving to the default/main agent model [1 pull requests, 5 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#58927Fetched 2026-04-08 02:31:07
View on GitHub
Comments
5
Participants
3
Timeline
12
Reactions
0
Author
Timeline (top)
commented ×5labeled ×2subscribed ×2cross-referenced ×1

Cron-executed jobs do not honor explicit model selection via either payload.model or agentId.

Despite correct configuration, all cron jobs resolve to the default/main agent model at runtime.

This prevents assigning different models per job and breaks mixed-model workflows (e.g., running most jobs on Haiku while reserving GPT-5.4 for higher-quality tasks).

Root Cause

Cron-executed jobs do not honor explicit model selection via either payload.model or agentId.

Despite correct configuration, all cron jobs resolve to the default/main agent model at runtime.

This prevents assigning different models per job and breaks mixed-model workflows (e.g., running most jobs on Haiku while reserving GPT-5.4 for higher-quality tasks).

Fix Action

Fix / Workaround

Issue occurs consistently in Docker deployment • Direct sessions_spawn with explicit model works outside cron • Cron-dispatched sessions appear to ignore both payload.model and agentId • All cron jobs resolve to the main/default agent model at runtime

• Affected systems: OpenClaw cron execution (all cron jobs) • Severity: High (breaks model routing and mixed-model workflows) • Frequency: Always (100% reproducible across all tested jobs) • Consequence: • payload.model is ignored • agentId is ignored • All cron jobs execute using the default/main agent model • Cannot assign different models per job • Prevents using higher-capability models (e.g. GPT-5.4) for specific tasks • Previously caused unintended high-cost usage (before mitigation)

PR fix notes

PR #59000: fix(cron): clear stale model/provider overrides on new isolated sessions

Description (problem / solution / changelog)

Summary

  • When an isolated cron session rolls to a new sessionId (forceNew=true), the session entry preserves all fields from the previous entry via object spread (...entry)
  • This causes modelOverride and providerOverride from prior sessions to leak into the new session
  • These stale overrides can interfere with model resolution in resolveCronModelSelection, which checks sessionEntry.modelOverride as a fallback when no payload model is specified
  • Fix: clear modelOverride and providerOverride alongside the existing delivery routing state cleanup when starting a fresh session

Fixes #58927 Related: #58575, #58065

Test plan

  • Create a cron job with --session isolated and a specific --model
  • Run the job, verify the model is used correctly
  • Set a model override via /model on the cron session, then run the job again
  • Verify the new isolated session does NOT inherit the manual model override
  • Verify non-isolated sessions still preserve model overrides as expected

🤖 Generated with Claude Code

Changed files

  • src/cron/isolated-agent/session.ts (modified, +6/-0)

Code Example

Cron job configuration:

{
  "name": "weekly-intelligence-operation",
  "agentId": "gpt5-operations",
  "payload": {
    "model": "openai/gpt-5.4"
  }
}

Session log (actual execution):

{
  "provider": "anthropic",
  "model": "claude-haiku-4-5"
}

This behavior is consistent across multiple cron jobs.
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Cron-executed jobs do not honor explicit model selection via either payload.model or agentId.

Despite correct configuration, all cron jobs resolve to the default/main agent model at runtime.

This prevents assigning different models per job and breaks mixed-model workflows (e.g., running most jobs on Haiku while reserving GPT-5.4 for higher-quality tasks).

Steps to reproduce

1.	Configure an agent with a specific model in openclaw.json:

{ "id": "gpt5-operations", "model": "openai/gpt-5.4" }

  1. Configure a cron job in cron/jobs.json:

{ "name": "weekly-intelligence-operation", "agentId": "gpt5-operations", "payload": { "model": "openai/gpt-5.4" } }

  1. Run the cron job. 4. Inspect the resulting session log:

grep "model" /data/.openclaw/agents/main/sessions/<session-id>.jsonl

Observed result

The session executes as:

{ "provider": "anthropic", "model": "claude-haiku-4-5" }

Expected behavior

The session should execute as:

{ "provider": "openai", "model": "gpt-5.4" }

Actual behavior

cron-executed jobs ignore both payload.model and agentId.

All cron jobs execute using the default/main agent model, regardless of explicit configuration.

In this case, the job configured with: • agentId: gpt5-operations • payload.model: openai/gpt-5.4

still executed as:

{ "provider": "anthropic", "model": "claude-haiku-4-5" }

OpenClaw version

OpenClaw 2026.3.28 (f9b1079)

Operating system

Ubuntu 24.04.4 LTS (VPS)

Install method

Docker (VPS deployment)

Model

claude-haiku-4-5 (actual execution) openai/gpt-5.4 (expected but not honored)

Provider / routing chain

openclaw → cloudflare-ai-gateway → minimax

Additional provider/model setup details

Issue occurs consistently in Docker deployment
•	Direct sessions_spawn with explicit model works outside cron
•	Cron-dispatched sessions appear to ignore both payload.model and agentId
•	All cron jobs resolve to the main/default agent model at runtime

Logs, screenshots, and evidence

Cron job configuration:

{
  "name": "weekly-intelligence-operation",
  "agentId": "gpt5-operations",
  "payload": {
    "model": "openai/gpt-5.4"
  }
}

Session log (actual execution):

{
  "provider": "anthropic",
  "model": "claude-haiku-4-5"
}

This behavior is consistent across multiple cron jobs.

Impact and severity

•	Affected systems: OpenClaw cron execution (all cron jobs)
•	Severity: High (breaks model routing and mixed-model workflows)
•	Frequency: Always (100% reproducible across all tested jobs)
•	Consequence:
•	payload.model is ignored
•	agentId is ignored
•	All cron jobs execute using the default/main agent model
•	Cannot assign different models per job
•	Prevents using higher-capability models (e.g. GPT-5.4) for specific tasks
•	Previously caused unintended high-cost usage (before mitigation)

Additional information

No response

extent analysis

TL;DR

The issue can be resolved by ensuring that the cron job execution properly honors the agentId and payload.model configurations, potentially by reviewing and adjusting the OpenClaw cron job dispatcher logic.

Guidance

  • Review the OpenClaw cron job dispatcher logic to ensure it correctly handles agentId and payload.model configurations.
  • Verify that the openclaw.json and cron/jobs.json files are correctly formatted and loaded during cron job execution.
  • Check for any overrides or defaults in the OpenClaw configuration that might cause the cron jobs to ignore the specified models.
  • Test direct session spawning with explicit models outside of cron to isolate if the issue is specific to cron job execution.

Example

No specific code example can be provided without modifying the existing OpenClaw codebase, but ensuring that the agentId and payload.model are correctly passed to the session spawning logic is crucial.

Notes

The issue seems to be related to how OpenClaw handles cron job configurations, specifically the agentId and payload.model fields. The fact that direct sessions work as expected outside of cron suggests a potential issue with the cron job dispatcher.

Recommendation

Apply a workaround by manually adjusting the cron job execution logic to correctly honor the agentId and payload.model configurations until a proper fix can be implemented in the OpenClaw codebase. This is necessary because the current behavior breaks model routing and mixed-model workflows, which is a high-severity issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The session should execute as:

{ "provider": "openai", "model": "gpt-5.4" }

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Cron jobs ignore payload.model and agentId, always resolving to the default/main agent model [1 pull requests, 5 comments, 3 participants]