Summary

Unify model routing, provider preflight, and fallback behavior across OpenClaw execution paths so configured models behave consistently whether they are used by cron, memory dreaming, subagents, or direct/interactive agent runs.

Motivation

While investigating local/LAN Ollama use with managed Memory Dreaming Promotion, we found that different execution paths can treat the same configured model differently:

• A subagent/direct agent path may attempt ollama/<model>, observe a provider failure, and then continue through configured fallback models.
• An isolated cron path can run local-provider preflight before the agent turn starts and mark the run skipped immediately if that preflight fails.
• Because the cron run is skipped before normal execution starts, the configured fallback chain may never get a chance to recover.

This makes model assignment feel non-deterministic from the operator perspective. If a model is configured as ollama/qwen3:14b or ollama/qwen2.5-coder:32b, the expected behavior is that all OpenClaw paths resolve the same provider config, base URL, fallback policy, and diagnostics.

Desired behavior

When a task selects or resolves a model, OpenClaw should use one consistent model-routing contract across:

• interactive/direct agent runs
• subagents
• isolated cron agentTurn jobs
• managed memory dreaming jobs
• other plugin/maintenance jobs that dispatch agent turns

Specifically:

1. Deterministic model resolution

   • The same configured model ID should resolve to the same provider config, base URL, auth, fallback chain, and capability metadata regardless of caller.

2. Preflight should not bypass fallback policy

   • If cron preflight is retained, it should either validate the full resolved fallback chain or degrade into the normal fallback path instead of marking the whole run skipped solely because the primary local provider is unavailable.

3. Unified provider transport assumptions

   • Provider health checks/preflight should use the same provider configuration and transport assumptions as real model execution.
   • Local/LAN providers should not behave differently purely because the caller is cron vs subagent vs memory-core.

4. Clear diagnostics

   • Error output should distinguish:
     • model cold-start / slow wake
     • provider endpoint unreachable
     • provider reachable but model missing
     • fallback unavailable or skipped
     • auth/config failure

Example scenario

A system has Ollama configured at a LAN URL such as http://192.168.1.x:11434 and has fallbacks configured to a cloud model.

• A subagent run using ollama/qwen2.5-coder:32b can fail on the Ollama attempt and then continue using openai-codex/gpt-5.5 via fallback.
• A managed Memory Dreaming Promotion cron job resolving to the same Ollama model can be marked skipped during model preflight before the fallback path is reached.

From the operator perspective, both jobs selected the same configured model. The difference in behavior comes from execution-path-specific preflight/fallback handling, not from the model configuration itself.

Why this matters

Reliable model assignment is important for operators who use a mix of local, LAN, and cloud models for cost, privacy, or performance reasons. If local-provider availability varies, OpenClaw should apply the same fallback and diagnostic policy consistently across all task types.

Related context

This is broader than adding retries to local-provider preflight. Retries help when a local provider is reachable but slow/cold. This request is about the higher-level contract: model routing, preflight, and fallback should be coherent and consistent across framework paths.