Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

When a cron job specifies a model override (e.g. "model": "ollama/nemotron-3-super"), the gateway returns modelApplied: true but silently runs the session on the default cloud model instead.

Steps to reproduce

1. Configure Ollama provider in openclaw.json with baseUrl, api key, model definition
2. Create an isolated cron job with "model": "ollama/nemotron-3-super" in payload
3. Let the cron fire
4. Check the actual model used in session logs

Expected behavior

• If the requested model cannot be used, modelApplied should be false
• Gateway should log a warning when falling back from a requested model
• Ideally: fail the session rather than silently billing a different provider

Actual behavior

• Cron fires, isolated session starts
• API response includes modelApplied: true
• Actual inference runs on the default cloud model (claude-sonnet-4-6), NOT the requested local model
• Verified across 19 consecutive cron runs dating back to March 20 — every single one ran on Sonnet despite requesting Nemotron
• No error, no warning, no log entry indicating the fallback

OpenClaw version

• OpenClaw 2026.3.13

Operating system

• macOS (arm64)

Install method

npm global

Model

• Ollama provider configured with local Nemotron 3 Super (120B MoE) - Ollama running and responsive (ollama run nemotron-3-super works in terminal)

Provider / routing chain

openclaw

Additional provider/model setup details

• Ollama (and other local models): streaming breaks tool calling — need stream:false fallback #5769 (Ollama streaming drops tool calls)
• Model override ignored in isolated sessions and sessions_spawn #13159 (model override in isolated sessions)
• [Bug]: exec-approvals.json not honored after gateway restart — isolated cron sessions still prompt #59224 (exec-approvals not honored in isolated cron sessions)

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

Update: Gateway ignores empty fallbacks array — falls back to Haiku even when removed from config

Additional reproduction (April 1, 2026)

To isolate whether the local model was actually running or silently falling back, I performed a controlled test:

1. Set ollama/nemotron-3-super as the only model in Nate's dedicated gateway config (~/Nate/configs/nate.json)
2. Set "fallbacks": [] — empty array, no fallback models
3. Removed anthropic/claude-haiku-4-5 from the models block entirely
4. Restarted the gateway via launchctl kickstart -k
5. Verified gateway was up (HTTP 200 on port 19450)
6. Sent a simple tool-calling task: "List the files in ~/Projects/mission-control/app/"

Result

The gateway ignored the empty fallbacks array and fell back to anthropic/claude-haiku-4-5 anyway. The UI displayed an orange banner: "Fallback active: anthropic/claude-haiku-4-5"

The task executed successfully on Haiku (tool calls worked, exec returned real output). This confirms:

• The gateway has a hardcoded fallback behavior that overrides the config
• Setting "fallbacks": [] does not prevent cloud model fallback
• Removing the fallback model from the models block does not prevent it either
• There is no config combination that forces the gateway to use only the specified local model
• modelApplied: true continues to be unreliable — the user has no way to verify which model actually ran without checking the UI fallback banner (which isn't available in cron/isolated sessions)

Impact (compounded)

This means every isolated cron session specifying a local model has been silently billed to Anthropic since setup. The user cannot prevent this through configuration alone. The gateway will always find a cloud model to fall back to, even when explicitly told not to.

[Screenshot of orange "Fallback active: anthropic/claude-haiku-4-5" banner attached]